I ran into an interesting bug in 1997. My employer was developing an IDE and close to the release time we got a report from a beta tester that creating a project failed on a Windows 95 test box, where it would create the directory but then report that it didn’t exist!
The debug log was mystifying: the app was successfully creating the project directory but then failing to open it because the Win32 API to enumerate `C:\.` was returning an empty list and it hit the error handler when the expected directory name wasn’t in the empty list.
Naturally, we couldn’t reproduce this on any system we had access to and the customer could only reproduce it on Win95, not NT. I remembered that the Win95 networking stack was a deeply-invasive kludge and on a hunch tried disabling network file sharing, which immediately made the problem reproducible even though the local C: drive hadn’t been shared.
The IDE developer was able to side-step the big by changing the existence check to use a different API and shipped on-time. Our theory was that Microsoft’s QA team had missed the bug for the same reason we had: everything in the test environment was networked to have access to the shared builds and testcases.
Windows 95 was a marvel of pragmatic engineering. While it won’t win any awards for purity, it did a great job of delivering real value to people while still allowing their old programs to run. FAT32 was a major part of that.
Except this wasn't the original Windows 95, this was OSR2:
"FAT32 was introduced with MS-DOS 7.1 / Windows 95 OSR2 in 1996" [1]
OSR2 fixed many nasty problems with the orig. Windows 95 which was released in the summer of 95. The next Windows 9x version was 98.
When I see people talk about Windows 9x I feel like they don't remember the negative. BSOD were common in Windows 9x. The first Windows version with which I've had a stable, satisfying experience was Windows 2000 (at work I did use some version of Windows NT 4; it could've been the network but it had quirks and was slow. Had to be early 10 min just to fire up computer).
Indeed. Windows NT (and OS/2) were better from a purity standpoint but they were too far ahead of their time due to their high ram requirements (a whopping 4 megabytes per 16-bit application run!). It took a half a decade for hardware to get sufficiently better and cheaper for the compromises of the Windows 95 era to no longer make sense. Also, it's funny how now with Docker we're going back to this multi-tenancy process isolation model (which was the major secret sauce of Windows 95) instead of running everything in full blown VMs.
That 4MiB per application assertion is not true of OS/2. 4MiB was minimal physical RAM requirements for 32-bit OS/2, which I myself ran on a 4MiB machine for a while, but it did not scale up from that by number of applications run, let alone by number of 16-bit applications.
It's a real shame there is no modern and open equivalent filesystem. Instead you get your choice between legally encumbered exFAT, legally encumbered NTFS, and a bunch of unix filesystems where permissions screw up the universal R/W.
You could chmod 777 the fs by default. That's not the problem. The problem are the proprietary os not recognizing the filesystem despite it being free to use and well documented. It's a commercial strategy, not a technical problem.
We could have way better than fat32 on cards. Ms and apple just don't want to make that any easier for you.
There's also the umask, which by default will create all new files without write permission for anyone but the original UID. So now you have to either change your umask or do a chmod after creating a new file.
With ZFS you can set the property to just inherit ACLs and ignore umask. What you’re describing is just a problem with a specific implementation (lack of feature).
In linux you can set the umask to a certain value for usb storage devices when automounting, so again, the other os could do it. Still not a technical problem.
I'm always mildly surprised that UDF, the filesystem for DVD discs, isn't used more on USB sticks. It's r/w on the major three operating systems. The only downside is that I think you need to create it in the first place on Linux. (Maybe macOS can format UDF too?)
The major OSs all behave differently depending on if the media with the UDF volume has a partition table or not, among other strange implementation quirks, because nobody expects it to be used outside of optical media.
But since UDF reserves the first 2 KB, you can put a partition table on your medium, and let the first partition start at sector 0. Usually partition programs complain about this, but the file system driver lets it pass.
There used to be a bug in the Linux version of the filesystem that prevented partitions of above 70MB or so to be created (shortints FTW!); however, that is fixed now.
Far worse is it that there is no good, unencumbered (looking at you CDDL license) version of UDF fsck.
this fat32 is still used a lot! One weekend I figured out how to copy an fat32 UUID from one sdcard to another when you "upgrade" your sdcard on Android and want to keep the same path names because Android is using UUID as part of external sdcard path names https://superuser.com/a/1294893/95714
After all the trouble I had with activating Windows and Office and whatnot, I have come to kind of appreciate dongles, actually. Migrating a license from one machine to another is as easy as unplugging the dongle and plugging it into the new machine.
OTOH, the company I work for has a customer that uses some ancient automation software to run an industrial plant, and that software uses dongles attached to the parallel port, and I mean the parallel port. Using USB-to-parallel-adapters does not work, and finding motherboards with parallel ports has become rather difficult. :-|
I've worked on several projects where we ended up having to crack that kind of protection - often, with the formal written blessing of the license owners, who were happy to continue to support our use but did not have the ability, resource, or sometimes, even the source code to the product anymore. This may be an option for your customer if they haven't tried it already. Sometimes a few hours of highly skilled RE work, even if you have to contract it out, can pay huge dividends in preventing downtime due to having to source antiquated hardware combinations or maintain broken software. We were even able to move some ancient, unreliable, insecure airgapped Windows 2000 server hardware into Windows Server on AWS where we could back it up, monitor it, and provide high availability and remote access. In my experience this can be the happy medium between "it's working, don't touch it" and "WTF this runs on DOS and the 30 year old machines break all the time"
Have you tried modifying the Device Manager configuration for the USB-to-parallel adapter to assign it the I/O port and IRQ traditionally associated with LPT1 (I/O port 0x3BC, IRQ 7)? Changing exactly those kinds of mappings are the whole (original) purpose of the Windows Device Manager :)
The other thing you could do, though, is just run the automation software in a VM, and map the USB parallel port to the VM's LPT1. It's the IBM z/OS philosophy :)
Thank you! I will pass the hint regarding the Device Manager on to our automation people!
But as far as I recall, the software runs on DOS (for real!), and attempts to run it inside a VM have not been very successful, because the link between the software and the PCL is very timing-sensitive or something like that. FreeDOS did not work, either; I got to install MS-DOS 6.22 on a few machines two or three years ago for that reason. It was fun actually, but finding three floppy disks for the installation media was ... challenging. ;-)
You can easily make a bootable CD-ROM for MS-DOS by using the boot emulation...
> mkisofs -b dos622_1.img . > \temp\dos6.iso
something like this, will get you a bootable CD that'll emulate a floppy and get you onto that first disk... It's probably easier to do a dump/restore set of whatever it is you need to install, or just make a boot floppy to load up MSCDEX & friends so you can xcopy as another solution.....
Parallel ports aren't too hard to find, there is PCI cards you can find with parallel ports.. Now ISA slots on the other hand....
I actually tried something along those lines, but I could not get it to work properly. The installation started normally, but when it was time to enter the second disk, the installer somehow did not accept the second disk.... :-|
On the upside, installing MS-DOS 6.22 from floppies took less than 15 minutes, and the freshly installed system booted withing 15 seconds. ;-)
Hmm, the software could be hardcoded to LPT1. Most mobos still have the port on the chipset, they just don't have the headers. Not sure if you can re-assign LPT3 to LPT1..
If it runs on MS-DOS, it most probably isn't hardcoded to use "LPT1" (the DOS device), but instead is hardcoded to use the exact I/O port and IRQ normally assigned to LPT1 (according to Wikipedia, I/O port 0x378 and IRQ 7). Other than filesystem and disk access, software running on MS-DOS nearly always accessed the hardware directly.
I just found out that the piece in software is being rewritten from scratch (since the original vendor has gone out of business long ago). And since the new version is written by a contractor on behalf of the customer, it will not require a dongle or anything like that.
Dongles are awesome!! I work at a biotech company and we purchase a lot of bioprocessing equipment at auctions. Typically the s/w is like $10,000+ so they just sell us the PC with the installed s/w for a couple of hundred. These PCs have like XP era hardware that instantly shits the bed after a few months. Having dongles means you can install the software again on a fresh PC and carry over the license without having to re-prove that you have purchased the software separately. Haven't run into parallel port dongles yet.. /shudder
The lovely thing about FAT32 was that you could mount it from Linux which was a big thing back then. So for example, I could use WINE to run Counter Strike on Linux, and actually have a more stable experience than Windows 9x.
The debug log was mystifying: the app was successfully creating the project directory but then failing to open it because the Win32 API to enumerate `C:\.` was returning an empty list and it hit the error handler when the expected directory name wasn’t in the empty list.
Naturally, we couldn’t reproduce this on any system we had access to and the customer could only reproduce it on Win95, not NT. I remembered that the Win95 networking stack was a deeply-invasive kludge and on a hunch tried disabling network file sharing, which immediately made the problem reproducible even though the local C: drive hadn’t been shared.
The IDE developer was able to side-step the big by changing the existence check to use a different API and shipped on-time. Our theory was that Microsoft’s QA team had missed the bug for the same reason we had: everything in the test environment was networked to have access to the shared builds and testcases.