A trip down (not much) memory lane

As regular readers of this blog (and thanks to all of you for reading by the way) will know, I debug code, review code and reverse engineer malware. Debugging and security for fun and profit. Well, I find it fun at any rate and it is my business so I take what profit I can in these difficult days. However, I have spent the last few days coding until the small hours which is something that that I don’t generally do that often.
 
As always, no names and no pack drill. My customer had bought in a solution that was a perfectly good solution except that it was designed to be single user with that one user having compplete control over all aspects of the data. There is nothing wrong with that except that it was needed to work with 70 users, of which 69 would have limited abilities to change the data. I was called in to see if I could make one thing into another.
 
It was clear from the start that the answer was “No, sorry, not happening”. However, that left my client in the lurch as they were hard up against a deadline. They need a solution and they needed it in a hurry. It had to run on low end XP equipped laptops with older versions of Office and couldn’t require any installation. Oh, and I got the specification (on the back of an envelope) on Friday night and it needed to be running for training on Monday and in production for Tuesday.  Clearly, that was going to be a challenge – and it had to match the look and feel of the previous solution.
 
Tricky, eh? .NET was out because the systems didn’t have the required runtime and installation was a problem. Pure C++? That would do the job but a fully functional system in less than 72 hours? Maybe there were people who could have pulled that off but not me. Java? JVM not installed. This wasn’t looking good. So, it would have to be something where all the required files were part of the OS.  Hmmm… MSVBVM60.DLL ships with the OS. ADO ships with the OS. I could write it in VB6, an old, old friend of mine. I wouldn’t have any OCX controls to use but I could write controls in the project if needed.  It is a RAD environment and that would help a lot. Yes, I could get the customer out of a bind here.
 
Ok, I haven’t had a lot of sleep over the weekend but I wouldn’t be writing this if there was still a problem. Yes, it is an old technology. It has its limitations. It got the job done nicely though.  I was a bit concerned that I would see repeated reloads across the network from the application EXE (it was a single file run from a share) because the memory would be considered discardable. However, I stopped worrying when I built for release. The executable was 60K long. No, that isn’t a typo. It was less than 64K on disk and even with the recordsets and ADO was still less than 5 MB in memory. 4 Polymorphic forms that pretend to be several more with some control hiding, some validation code, a lot of custom UI code and some fairly unremarkable ADO code and it had a tiny footprint. The customer wanted their logo added (another 6K) and an attractive high resolution icon (64K) bringing the total to just under 128K. I can live with that level of bloat.
 
There are a lot of cool things about the new languages and for serious development, you have to be impressed. That is not to say that old school doesn’t sometime get the job done just fine.
 
Signing off
 
Mark Long,  Digital Looking Glass Ltd