What we call Win32 is not an operating system by itself. It is a set of functions – and a large one2 – that you can use to write programs for different operating systems of the Windows family.
Windows comes in different flavors :
Win9x are able to run 32 bits programs and 16 bits programs concurrently. But the operating system by itself is not entirely written in 32bits mode, and does not support memory protection: 16bits applications can overwrite parts of the operating system memory! Some parts of the system like the GDI (Graphical Device Interface) manage limited resources like bitmaps, fonts, pens and so on for the set of all programs that run concurrently. All the bitmaps headers available at the same time can't amount for more than 64kb. This explains the performance tool and the fact that you can put your system on his knees by making intensive use of graphic objects for example.
NT and Win2000 do not suffer from these limitations, and neither from other Win9x limitations. They are true multitasking environments, with protected memory. They are much more responsive than Win9x because of better memory management, better file system and so on.
You will wonder : “why would I need to use a command line prompt when I have Windows ?”.
Good question. The problem is of very general nature. Not all operations can be done easily using only a GUI. Command line gives you programming power – assuming a clever command interpretor.
But the problem here is more fundamental : TeX is a batch tool. Not an interactive one. TeX needs to calculate the best layout for each page, resolve cross-references and so on. This can be done only by a global processing of the document. It is not (yet) a task that can be done interactively.
This means that you should use TeX from a command line. In fact the situation is not so bad. There is an advantage to write command line tools for complex processing: they are better debugged, because not tight to GUI problems, and GUI tools can be designed to interface the command line tools. This is the case for TeX where you will interact with it most of the time through a GUI text editor – see section 3.4.1.
However, you may need to use the command line prompt in a number of situations, by example in case of problems and you want to debug your setup – see section 3.5.
The Win32 API understands both / and \\ characters et PATH separators. But the command interpretors do not! So whenever a path name is used programmatically, you can use both separators, and even mix them up in the same path name. But on the command line, you must type \\ as path separator. The reason is comaptibility: the command processor used the / to introduce arguments to commands.
All this to say: do not be surprised to read path names written using the Unix convention; fpTeX is a port or Web2C, and aims to be compatible across platforms. For this reason, all the configuration files that need to specify path names use the Unix convention.
The worse feature of Win9x with regard to TeX is probably the so-called FAT file system. TeX uses many many small files, with size around 1kb – 3kb. The FAT file system is old, and predates by far the multi-gigabytes hard disks we have today. It means it can't manage efficiently the 30000 TeX files found on the CD-ROM. The FAT file system will allocate a minimum of 32kb for any file on a huge partition. It means that TeX will use much more disk space than it actually needs.
The other, more modern, file systems available – namely FAT32 and NTFS – do not have this drawback. They manage clusters of 4kb only5.
If you have a look at the Web2C documentation, you will read that all the various TeX derived programs use the same base engine. For example, tex.exe and latex.exe are exact copies of the same program, but each one will use a different format file, based on its calling name.
Under Unix, this feature is implemented through symbolic links. It saves up a bit of disk space, because some engines are used with many different format files.
The Win32 API does not know about file links. So to save up almost the same amount of memory, I choose to put all the TeX base engines in DLLs (Dynamic Linked Library). This means that you will have the following layout:
In fact, a generic tool called lnexe.exe is provided to build the equivalent of Unix hard links for executable files only under Win32.