I've got a project that was written in BASIC. I'm not sure of the exact reason, but the app will not function except when being run from a FAT-16 file system.
I'd rather try to set up and environment that will support this app in a modern OS (Vista/XP) instead of rewriting it.
Does anyone know how to get an app like this running in XP/Vista through some kind of code change (to the BASIC code) or FAT-16 "emulator" (if such a thing exists)?
Run an older version of Windows in a VMWare virtual machine, itself running in a modern OS.
You may try running it via a DOSBOX:
DOSBox emulates an Intel x86 PC, complete with sound, graphics, mouse, joystick, modem, etc., necessary for running many old MS-DOS applications that simply cannot be run on modern PCs and operating systems, such as Microsoft Windows XP, Windows Vista, Linux and FreeBSD
(from their Wiki)
I use it for several years now. It is good, stable and quite robust. Has several third-party GUIs as well to make your live easier
Other than just keeping the app alive in a virtualized environment, as has already been suggested, the first thing to do would be to figure out why the code seems to require FAT-16.
If the app (or its runtime) is particularly evil, the FAT-16 requirement may stem from the fact that it's trying to do direct disk I/O, bypassing the operating system. If the BASIC code itself is trying to pull that particular stunt, you should see lots of CALLs, PEEKs, POKEs or even the occasional IN and OUT statement in I/O routines. Determining what the runtime is up to is more difficult: if it's from Microsoft, DOS-based and not too ancient (e.g. GWBASIC or QuickBASIC/PDS), or Windows-based it should be OK, though.
Anyway, if either the app or the runtime is attempting direct disk I/O, you lose: it will be pretty much impossible to get things to work on a modern OS without extensive, rewrite-like, code changes.
If the app is using the normal BASIC facilities for input and output (e.g. OPEN "file" FOR whatever AS #1), and the runtime is also using the normal OS interfaces, the most likely reason it only works on FAT-16 is that it gets thorougly confused by long filenames.
First thing to try would be to put the app in a directory with a short name (e.g. c:\myapp), and seeing what happens next. Possibly it just works: otherwise, you should be able to figure out what's going on by stepping through the BASIC code (charitably assuming a debugger is part of its runtime environment).
Without some more information about the exact interpreter/compiler your app runs in, it's impossible to answer your question in more detail. If answers so far haven't been helpful, you may want to edit your question to include this information.
Depending on the Environment: It should still be possible to create Fat-16 Filesystems on modern OS, you may just need additional Tools like Acronis DiskDirector of even some Linux' fdisk Variant.
Just keep in mind that FAT-16 is limited to a partition Size of 2 GB.
But as said before: Best to find out WHY. Sounds like some sort of WTF-Copy-Protection.
Run it from a flash, zip drive or whatever removable media you got.
Windows XP formatted a 1GB usb flash drive as FAT with no problems, no additional tools were nessesary.
Besides, if the application is really evil, you thus, hopefully, constrain its evilness by the boundaries of the drive.
I second @eugensk00's suggestion, we have some slightly wacky instrument software which won't save to a NTFS hard disk but will save to a small memory stick (1GB)...
You might be able to import the code directly into VB.NET (although it would almost certainly require some modifications). You could then replace the original app's file IO calls (which are almost certainly your problem) with VB.NET calls, getting you out of the FAT16 problem.
Also note that some old-school programs first check to see if there is enough disk space before writing files, resulting in wacky issues if the drive is so big that it overflows the 16-bit counter it is apparently using. (If that's the case, then it'll either work, or not work, depending on the nature of the overflow).