Ttdfjt

When installing an old version of Windows, there is a step about application start tuning:

This is not about the PREFETCH folder, since this feature appeared in Windows XP.

Question:

Does anyone know what Windows performs during this step?

At that point, Setup executes WALIGN.EXE. Some information could be found back then at Microsoft's Knowledge Base (*1):

Winalign.exe and Walign.exe (*2) optimize programs by rewriting a program's file headers, creating a new section table, and then writing file sections, each of which starts on a 4-kilobyte (KB) boundary. The new section table is then updated with this information, and the file headers are also updated to denote the file is now aligned to a 4-KB boundary. By aligning files in this manner, the Windows 98 CacheMap feature can map directly to sections in the cache memory. This can result in significant performance increases by freeing memory.

Wiki, BTW, also notes this under Performance Improvements in the Win98 entry:

On the FAT32 file system, Windows 98 has a performance feature called MapCache that can run applications from the disk cache itself if the code pages of executable files are aligned/mapped on 4K boundaries, instead of copying them to virtual memory. This results in more memory being available to run applications, and lesser usage of the swap file.

and

WinAlign (Walign.exe and Winalign.exe) are tools designed to optimize the performance of executable code (binaries). WinAlign aligns binary sections along 4 KB boundaries, aligning the executable sections with the memory pages. This allows the Windows 98 MapCache feature to map directly to sections in cache.[25] Walign.exe is included in Windows 98 for automatically optimizing Microsoft Office programs. Winalign.exe is included in the Windows 98 Resource Kit to optimize other programs.

WALIGN.EXE is distributed with the system install but looks only out for (older) MS programs which are not aligned. WINALIGN.EXE can be used for a general optimization.

The workings are based on the improved (disk) cache handling of Win98 offering the MapCache feature. It allows to map a cache page into program memory. Effectively switching from use of classic paging (for program files) to memory mapped (code) files.

At that point some history/theory of operating systems, program loading and virtual memory might be helpful:

A classic program load means loading the code portion(s) from disk, execute them and if there's a shortage of memory, the least needed code gets moved out into a paging file, to be reloaded when needed again. That's a costly (and slow) disk operation, every time a code segment gets purged.

Like all disk operations this can be sped up by a disk cache. Except, taking cache memory from main memory may decrease performance, in tight memory situations, by having less memory for programs, resulting in programs being purged which could have resided happily in main memory without a cache taking up room.

Some OSes optimized this by not swapping out code segments, but reloading them from its (EXE) file. Just this involves reading its block(s) from disk into a read buffer and then transferring it bytewise into the program memory before execution.

In a further step this can already be improved by aligning code segments to disk block/cluster boundaries, thus reducing the number of disk blocks read to a minimum (*3), as well as allowing to load code directly into program memory, not going thru read buffers and/or disk caches.

While the later does add considerable performance, but also opens several dilemmas in OS design.

• By direct loading into program memory, sparing all levels of disk caching, may as well loose quite some performance. Especially if there is free space in cache.


• On the other hand, loading it via the regular load path (including cache) it may again add to memory hogging, as now the code resides in cache and program memory at the same time.

A (*4) tricky question isn't it?

Instead of fiddling around the issues as done before, MS took a bold step with Win98 and turned the problems into a solution by adding MapCache. MapCache allows to map (disk) cache pages into program memory (*5). Now, whenever a program gets loaded, its code segment get loaded quite the ordinary way thru the disk cache. But then they are not copied into program memory, but mapped in by just changing the corresponding page entry (*6).

As a result loading a segment becomes a single read operation, followed by no copy needed. Paging it out becomes (almost) zero effort, and reloading is again just a single operation - with the bonus if paged out due some other reason than memory shortage, it may still be in disk cache. In fact, disk cache now turns into a virtual page manager able to balance program and data load at the same time.

Quite clever, isn't it.

Of course, to have all of these benefits, code segments needed to be (memory) page aligned. That's were the 4 KiB size comes from (natural page size for 386ff). And WINALIGN.EXE does this for programs that are not already aligned (*7).

Back then there have been some fuzz that Win98 bloats programs. Well, it doesn't, it just inserts some filler to align the segments on page boundaries.

*1 - The relevant articles are no longer available online (except for some cache inconsistency). The excerpt is taken from an ancient MSDN disk - jup, back then, they did not just point to their online resources :)

*2 - WALIGN.EXEis a dedicated version for Office 98.

*3 - As there can be no partial block at the beginning of a segment.

*4 - Well, there are a few more pitfalls, but of lesser importance - and as well served by MapCache.

*5 - Simplified, there are more use cases including memory mapped files an so on, but that's a different story.

*6 - Plus some bookkeeping to let the system remember that the block is not only used, but also mapped to some other address space and what for. This needs to be taken into account before reusing the block, to not impact performance the wrong way.

*7 - It also keeps a list of 'optimized' programs at HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionWinalign. This not only helps to avoid doing the job twice, but was quite useful to exclude programs from being optimized - like for if they needed special alignment situations, like for direct access to their EXE file, but didn't walk the headers, but accessed these data with fixed offset. Usually for ... well, let's call it 'features'.

In short, Windows aligns application code on 4kb memory boundaries to load applications faster from disk or memory cache.
This works well for large applications like office, internet browsers, graphic editors...

A good detailed explanation can be found here:

https://www.techrepublic.com/article/speed-up-windows-98-applications-with-winalign/