Tips'nTricks using FBScanner

Yes, sometimes I use FBScanner too. :-)
My system is complex, because I have huge number of Firebird, InterBase and Yaffil versions. While Yaffil does not interfere with Firebird and InterBase, I need to run periodically Firebird 1.0, 1.5, 2.0, 2.1, 2.5 and InterBase 6.x, 7.0, 7.1, 7.5, 2007 and 2009. I do this by removing services records with "instsvc remove" after installation, because I don't need FB or IB as a service and run them ony as application like

fbserver -a
or
ibserver -a

To simplify this task I've created several cmd files that looks like
fb2.cmd:
call remove_all.cmd
d:\firebird2\bin\instreg install
d:\firebird2\bin\fbserver -a

and remove_all.cmd is:
d:\ib71\bin\instreg remove
d:\ib75\bin\instreg remove
d:\ib2007\bin\instreg remove gds_db
d:\ib2009\bin\instreg remove gds_db
d:\ya\bin\instreg remove
d:\intrbase\bin\instreg remove
d:\firebird\bin\instreg remove
d:\firebird2\bin\instreg remove
d:\firebird25\bin\instreg remove
...

So, if I need to run Firebird 1.5, I simply call fb15.cmd and less than in a second I have Firebird 1.5 running. If I need to run InterBase 2007, I just stop Firebird 1.5 application (shutdown) and run ib8.cmd.

Well, returning back to the FBScanner. By default it tries to find Firebird or InterBase service installed and intercept it's configuration to work on different than 3050 port. Unfortunately for the FBScanner I have only InterBase 4.1 service installed. Anyway, I leave FBScanner configuration as is, to intercept 3050 port and to redirect it to port 3052.
Then, I'm editing firebird.conf for example for the Firebird 2.1, uncommenting and changing parameter RemoteServicePort:

RemoteServicePort = 3052

So, when I start fb2.cmd my Firebird 2.1 runs and listens to port 3052, not to 3050.

So, if I will connect from any application to the Firebird, FBScanner will intercept traffic to the 3050 and will log everything is happening between Firebird server and client.

But, sometimes I don't want to intercept or watch some specific connections, or to watch connections only for specified databases. That's simple!
You need to know, that if fbclient.dll finds in the path one level above the file firebird.conf, it will use port number specified in it.

For example, if I will connect to some database with IBExpert, specifying client libriary as ...firebird2\bin\fbclient.dll, it will use port 3052 from the firebird.conf and traffic will not be intercepted by FBScanner.
Instead, if I want traffic to be intercepted by FBScanner, I need to write server name not as localhost, as usual, but as localhost/3050. This time traffic will go through FBScanner, and every statement and transactions will be monitored.

I hope this example will help you to configure Firebird and FBScanner if you want to check what your application is doing with the server.

Nostalgia

Remember our IBDeveloper Magazine, no? It was (and is) at the website www.ibdeveloper.com, but some time ago it was hacked, so, your browser may tell you that you should not open this link.

Anyway, we started to place interesting presentations about Firebird and InterBase on Scribd, and now decided to put there our IBDeveloper Magazine, all 4 issues. And, we found old lovely InterCom magazine issues (one of us a bit thrifty, or provident, if you wish) and placed there too.

If you spent years with InterBase, don't be shy to drop a tear on a keyboard while re-reading InterCom issues from the past century.

64 bit Delphi. Who needs it?

I'm watching not only the InterBase and Firebird newsgrops and forums, but the Delphi also.
And I know that at least lot of russian Delphi programmers complaining about still non-existing support of 64 bit Windows in Delphi.

Today at DelphiFeeds.com I saw the post "64 bit tommorow – Wh/if you’ll have more than 4GB “today”?", and want to share my opinion on this. Also I wish you to vote at that post, as I did.
That post has a lot of technical replies, but I want to look at "business" point of supporting 64 bit Windows.

Yes, 64-bit operating systems are used now, but mostly for servers. But Delphi programmers write programs mostly not for the servers, but for the usual customers, working on desktop computers.

Let us look at very good Steam report:
http://store.steampowered.com/hwsurvey/

Right now ~18% of gaming computers uses 64-bit OS. But, gamers are not enterprise customers. 32-bit programs still works well at 64-bit operating systems, but 64-bit programs can't run on 32-bit OS.

Moreover, I'm sure that most of Delphi developers who wants 64-bit support really wants only to use things they have, without the details how it can be done. Maybe I will look a bit rude for someone, but I think the Joker quote can be used here:
"You know what I am? I'm a dog chasing cars. I wouldn't know what to do with one if I caught it."

Of course, some Delphi developers really needs 64-bit Delphi. But for what tasks?

• middleware application servers
• scientific software
• compatibility/dll software

And that's it. 95% of software written in Delphi, or even more, designed for the end-users, who doesn't care about 32 or 64bits, and by the specific of this applications 64bit support will give nothing to them. Currenly, the more fun stuff is with multi-core processors. What stock or accounting software can utilise more than 1 core of processor? And what for? And the main question - do you know how hard to upgrade operating system for the enterprise, where lot of compatibility things need to be in count?

Interesting, that using GPU for computation gave much more capabilities and performance for the scientific applications than 64-bit systems. You may, if any, have not more than 20-30% increase of the application performance if it goes from 32 to 64bits, and only if it is optimised for that, but using GPU allows to speedup computations up to 100 times.

But, don't consider me as an orthodox person, I'm just a bit sceptic, and trying to look at things realistic. I believe in mult-cores - games can utilize up to 3 cores now! -, and I believe in 64-bit.