Friday, July 15, 2005 11:30 AM
bart
Return to the stone ages of programming - QuickBasic 4.5
A couple of days ago I had an interesting discussion with a friend of mine on our oldest (and darkest?) experience with computer programming. In the end I came up with the statement that .NET isn't that new at all (oh no, I'm going to be shot by some people now) when it comes to language interoperability (okay, I did relax my statement now, did I?). What's now taken for granted in .NET, being language interoperability through MSIL-code, does exist for a long time in fact, so I decided to track back the very first place where I tried to perform this kind of "tricks". All of a sudden I realised I had to turn on my old Pentium 75 because that's the only machine that still has a (still-functioning) floppy drive in it, in order to take a look at my old (dirty) programs. Right, that was the plan but magnetic fields everywhere in the house and chemical reactions of O2 with the surface of the diskettes disturbed my big idea to take a look at this old stuff :'(. In the end, I found a couple of disks that were still readable with all my magic tricks from about 10 years ago :o. Prime calculations, fractal drawing, sort algorithms and all sorts of inusable applications. Finally I found what I was looking for: some references (to be honest, it surprised me I wrote some comment in some of these old QuickBasic applications of mine) to the Microsoft Mixed-Language Programming Guide that I used a couple of times to "interop" with an application I found on a diskette from the local book library in my town with Fortran-code for some math-related stuff and Pascal-code for other stuff too. I've never known what that Fortran stuff was doing actually (although I understood Pascal a little that time), but I remember a big battle that time to use the library (if you can call that piece of Fortran-code a library at all) from within QuickBasic 4.5. Here's a little piece of code:
DIM name%(2048)
COMMON SHARED /NMALLOC/name%()
A piece of code, grabbed directly from some guide that came with the computer (a 286 with 64K of RAM and 3.5" and 5.25" floppy drives with EGA video display and - woohoo - a 40MB harddisk, now somewhere on a belt I suppose :s) on BASIC programming. That time, I didn't really know the meaning of it but now it's much more clear (luckily :-)). As the matter in fact, Pascal (and Fortran) both needed a piece of memory to be allocated on the heap for usage during the execution of the code when called from within QuickBasic. Finally, last night, I logged on to the MSDN Subscribers website in order to find a copy of QuickBasic 4.5 to run and compile this stuff again. Luckily it's still out there on the net available for subscribers. There are a couple of things you should know when you want to try this at home: installing QuickBasic on a "modern operation system" and on "modern hardware" is not that easy at all ;-). There is a workaround actually: install a floppy disk drive and put the stuff on five 3.5" disks as outlined by the directory layout in the self-extracting zip file. Then, the next problem is to find a couple of empty diskettes that are still working fine :o. The easier way looks like this:
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.
C:\Documents and Settings\BartDS>subst a: C:\temp\quickbasic\DISK1
C:\Documents and Settings\BartDS>subst a: /d
C:\Documents and Settings\BartDS>subst a: C:\temp\quickbasic\DISK2
C:\Documents and Settings\BartDS>subst a: /d
C:\Documents and Settings\BartDS>subst a: C:\temp\quickbasic\DISK3
C:\Documents and Settings\BartDS>subst a: /d
C:\Documents and Settings\BartDS>subst a: C:\temp\quickbasic\DISK4
C:\Documents and Settings\BartDS>subst a: /d
C:\Documents and Settings\BartDS>subst a: C:\temp\quickbasic\DISK5
C:\Documents and Settings\BartDS>subst a: /d
Luckily the subst command still exists in Windows Server 2003 and it appears to fool QuickBasic to think a floppy disk drive is present in the system :d. After the setup that took about - well euhm - 30 seconds in total (compare with Visual Studio 2005 Team System complete setup right now :o) the old familiar qb.exe is back on my system in a folder called C:\QB45 with a size on disk of 1.60 MB. Although qb.exe works without any problem whatsoever, there's a pretty big caveat: ntvdm.exe takes 100% CPU :-). I just compiled a pretty big application, being:
10 print "Hello world"
And yes, it compiled completely right:
C:\QB45>qb
BC C:\TEMP\JUNK.BAS/D/O/T/C:512;
Microsoft (R) QuickBASIC Compiler Version 4.50
(C) Copyright Microsoft Corporation 1982-1988.
All rights reserved.
Simultaneously published in the U.S. and Canada.
40157 Bytes Available
40068 Bytes Free
0 Warning Error(s)
0 Severe Error(s)
LINK @~QBLNK.TMP
Microsoft (R) Overlay Linker Version 3.69
Copyright (C) Microsoft Corp 1983-1988. All rights reserved.
Object Modules [.OBJ]: /EX JUNK
Run File [JUNK.EXE]: C:\TEMP\JUNK.EXE
List File [NUL.MAP]:
Libraries [.LIB]: C:\QB45\BCOM45.LIB
Unbelievable, isn't it? The result: a file of 13,936 bytes in total (:o), that still runs fine on Windows Server 2003, Windows XP and even my Longhorn installation. Backward compatibility to the max, just great!
The moral of the story: I've the feeling of becoming old now, as I'm starting to look back at the "good old times" :-))). Okay, back to the new ages right now: I'm looking at CLR hosting in .NET Framework v2.0 for the moment, using the new (refreshed) hosting APIs in mscoree (read: "how does SQL Server 2005 accomplish to run managed code in a controlled way, using the thread management, lock management, memory management, etc of the SQL Server OS itself?"). I'll be posting on this topic later on.
Del.icio.us |
Digg It |
Technorati |
Blinklist |
Furl |
reddit |
DotNetKicks
Filed under: Personal, .NET Framework v2.0