Frequently Asked Questions  -  2. Miscellaneous
This was a kind of basic disk caching, it has no meaning anymore. Since vDos isn't the operating system (DOS once was) controlling the drive, any(!) caching would be a disaster for your data on the drive, waiting to happen.

DOS itself in vDos runs outside the virtual PC; it is no longer 16-bit code executed by the (emulated) CPU. So this directive is also meaningless in vDos; there is no DOS code in the virtual PC/memory.

The number of global DOS file handles in vDos is always 255. The maximum, since DOS file handle numbers are bytes.

DOS in vDos has no use for this directive.
To overcome Windows 64-bit not able to execute 16-bit programs, vDos emulates a 80386 CPU in software. A single hardcoded real CPU instruction will result in many instructions to emulate this. The CPU operating state, internal CPU registers are maintained in relatively slow memory, and more technical stuff...
In raw processing power the emulated CPU can
theoretically be as much as 70 times slower than the real thing!
DOS applications however don’t run that much slower. They frequently call BIOS and DOS functions, mostly executing faster than before (emulated in 32-bit mode). Reading from and writing data to disk is the real bottleneck for a program, that also is at least as fast. On average DOS programs will operate only a few times slower than on a real DOS PC or Windows 32-bit/NTVDM. Not that an issue; with user interaction, a program is still constantly waiting for user input. Whether she/he then has to wait 0.01 or 0.05 seconds before the program responds, isn’t noticeable.
But w/o user interaction, few BIOS/DOS calls, disk access, the program doing lengthy CPU intensive tasks, like sorting database records, the slowness of the emulated CPU will become more profound. You just have to life with that.
DOS was originally restricted to 8.3 filenames; 1-8 characters for the name, 1-3 characters for an optional extension. Windows came along with Long File Names (LFN’s), supporting up to 255 characters. Microsoft also came up with a scheme so DOS programs could access those LFN files: Short File Names (SFN’s).

When a LFN file like “Microsoft1.doc” is created, Windows also creates a SFN for that file: “MICROS~1.DOC”. The first 6 characters of the LFN, followed by a tilde, then a digit. When another LFN file is created with the same first 6 characters, for instance “Microsoft3.doc”, the digit is incremented: “MICROS~2.DOC”. That digit goes up to 4, a fifth LFN file, like “Microsoft2.doc” will become “MI1BC3~1.DOC”. The first two characters, a 4 digit hexadecimal CRC of the LFN, a tilde and a digit.

vDos doesn’t support LFN/SFN, moreover these files are hidden to DOS (applications).
  • Only a few vDos users ever requested such support. When asked why, none was actually able to come with a general, practical, non-fictional reason or case.
  • LFN’s are used/supported by only a few (mainly utility) DOS programs. One specific version of a Zip/Unzip program, ditto file manager, and some other examples, just silly to be started in vDos. You have 32/64-bit genuine Windows program for that.
  • The whole idea of LFN’s is to get more descriptive filenames. The concept of SFN’s however results in less descriptive, even confusing or cryptic filenames. DOS programs intended to run in vDos cannot create LFN’s, nor SFN’s (only Windows can do that). So why should they be able to open a LFN file by means of a SFN. That LFN file is obviously created by a non-DOS (Windows) program.
  • SFN’s are not ‘fool proof’. If “Microsoft1.doc” (SFN: “MICROS~1.DOC”) is copied to another folder, already containing that SFN (LFN: “Micros-whatever and case-.doc”), “Microsoft1.doc” will become SFN “MICROS~2.DOC”. Can it get more confusing or misleading, with SFN’s? Yes it sure can, just do some experimenting yourself.
  • SFN’s aren’t always created by Windows, some server editions don’t by default. External filesystems like on a NAS might suffer the same ‘problem’.
  • Microsoft already announced some time ago SFN’s were to be dropped in future Windows versions. It’s a mystery why for instance desktop Windows 64-bit still generates SFN’s, while it doesn’t support DOS programs at all.
  • Generating a SFN for a LFN is a burden for Windows. The SFN has to be unique within the containing folder. So Windows will start off with “MICROS~1.DOC”, then has to cycle through possible SFN’s, examining the complete folder listing over and over. Until it comes up with an new unique SFN. You should consider to turn off Windows generating SFN’s!
Note: There is a ‘backdoor’ in vDos to open a LFN/SFN file, while they are hidden in directory listings. Just supply the SFN, for instance “MICROS~2.DOC”. With SFN support, you also would have to know what that SFN actually refers to (“Microsoft1.doc”…?).
Once you could have had a DOS system, solely dedicated to run DOS programs, and store the data of those programs. That DOS PC got replaced by a Windows PC. For simplicity we forget about Windows 3.x – 98 (mainly DOS programs), and skip to Windows NT/XP (not DOS based anymore).

Microsoft had to make sure DOS programs would still run. Not to make the same mistake as OS/2. Its lack of adequate DOS support (besides of being ahead of affordable hardware) was a deal breaker for DOS users.

Microsoft came with NTVDM (New Technology Virtual DOS Machine), integrated in Windows (32-bit). DOS programs could be started, largely as before in DOS. But that integration came with a cost; the Windows PC is surely no longer dedicated to run DOS programs. The Internet is surfed, mail checked, video’s played, used for a lot more Windows specific stuff. Most folders and files (99%) have no meaning to DOS programs.

DOS programs got access to all Windows drives (letters) and directories, while there is no need for that. Certainly not the root of Windows boot drive C:. Windows even doesn’t like that. DOS programs need drive letters, these then have to be created in Windows, while Windows (programs) doesn’t need those.

Although you might be accustomed to DOS drive letters being those of Windows; forget about that. The vDos USE command allows to only make available those regions of Windows filesystem that your DOS program needs accessing. Even if you don’t want to forgo for instance a Windows F: drive being mapped to a network share; don’t do USE F: F:\ in vDos autoexec.txt. That is a (possibly confusing, even troublesome) roundabout. Instead do the direct USE F: server-name\share\.