File Cabinet (from Chicago 58s) patch for Windows 3.11

[xelloss]

As you know, the earliest Chicago betas include a 16 bit version of their desktop shell, the File Cabinet that would later become Explorer. It is not completely clear (at least to me) why this program was originally developed for a Win16 target, but we can assume that the 32 bit API implementation for Chicago was not mature enough at the beginning of the development.

Anyway, despite being a 16 bit application, File Cabinet won't run on Windows for Workgroups 3.11. This depends on several reasons: first of all, the program is flagged as a version 4.0 application, meaning every version of Windows older than that will refuse to load it.
However, this is a minor nuisance: you can use the Microsoft resource compiler with the -31 option to correct the program.

That won't however achieve anything, because CABINET is dynamically linked against the Chicago 58s system libraries, in particular newer versions of KRNL386 and USER (and SHELL), and imports some functions that are unavailable on WFW 3.11. Again, Windows will complain that the executable cannot be loaded due to a library mismatch.

How difficult can it be, I asked myself, to patch CABINET so that it will "sort-of-run" in WFW 3.11?
Well, it depends on the missing library functions it depends on. It turns out the functions missing from KRNL386 are especially file management stuff: remember that in the 16 bit world, Windows didn't provide much file I/O, and applications were expected to call the DOS kernel to open or create files, etc.; but in Chicago the situation was reversed: long filenames were supported by a Windows driver whose API was provided by Windows (DOS apps using LFN could use new interrupts, but these would thunk to the Windows API); the new LFN API was made available to Win16 apps as well, and it is used by CABINET.

It is not difficult to write a Windows 3.1 version of such functions by relying entirely on the DOS API: clearly only long filenames that happen to be short will be accepted, but that's not a big deal. USER is more complicated: CABINET expects a number of UI functions that were not available in WFW 3.11, from PaintDesktop to DrawAnimatedRects. We can write a stub for many of them, but if we want the desktop to appear and work decently, we will have to provide some implementation for PaintDesktop. Worse yet, GetSystemMetrics did exist in WFW 3.11, but it didn't accept all the parameter values that can be used in Chicago 58s; neither does Windows 95 RTM: the parameters for GetSystemMetrics in Chicago 58s are undocumented.

Then there's SHELL.DLL, used by Chicago to access the registry and do drag&drop. The registry existed in Windows 3.1 as well, but it was more limited; the drag&drop API was more limited too (and the new functions don't match Windows 95 RTM, making it difficult to write a replacement).

So, can we run CABINET in WFW 3.11 if we patch it like so? We can, and this is the result:



Don't expect too much: the most this prosthetically-fixed version of File Cabinet can do is create folders (hooray! the krnl386 patch works!). After some hours of codeview-ing, I was able to make the desktop appear, although at times some of the icons disappear (not so surprising, given that I haven't bothered implementing the Chicago 58s icon API, some of which is undocumented...). The desktop icons and the minimized application icons look the same to the untrained eye.

The small square window in the top left corner is called "System Controls", i.e. what we call taskbar: it should be positioned at the bottom of the screen and would normally contain the three buttons that would later evolve into the Start button, and a view of a special "tray" folder that the user can customize with links to the most used applications; however only the tray folder is shown, for reasons as of yet unknown.





And when you are tired of the uselessness of this monster, you can focus the System Controls window, press ALT+F4, and exit Windows. Isn't the shadowed desktop familiar?



Maybe the patched Cabinet will be able to do something more in the future.
For the moment, you can download exe/sources/patch from here:

https://mega.nz/#!52pkACpa

[DiskingRound]

Looks very cool. Thanks for sharing.

Not sure if this is related in any way whatsoever, but a long time ago I took the old Setup.exe file found in 58s and transported it to Windows 3.1 and just ran it. This was the setup that was probably used in 4x builds (45, etc.) It's not too different from WfW 3.1 setup, except that Windows is changed to Chicago and the "Chicago Setup" on the corner.

[OltScript131]

I can not download it... MEGA asks me for a decryption key...

[xelloss]

I can not download it... MEGA asks me for a decryption key...

Sorry, I guess I should have tested the link first. Here you go:

https://mega.nz/#!52pkACpa!8jQj297Ut9jM ... O1uFsRb1M0

[SoftPCMuseum]

If you look very closely at the screenshots, you can see a very slight grey sliver in the folder "tray" area. This is where the three buttons are supposed to be.

Also, one of the reasons for why certain features (such as icons) don't work correctly is that the user interface is relying heavily on entries in the registry (SYSTEM.DAT and USER.DAT), and if those entries are not available, then the user interface will not be able to find the correct settings required for each function.

And if you really want to know the reason for why the earlier versions of the Chicago/Windows 4.0 (Windows 95) shell were 16-bit instead of 32-bit, well, the reason for that is here:
https://blogs.msdn.microsoft.com/oldnew ... 2/?p=28233
https://blogs.msdn.microsoft.com/oldnew ... 00/?p=8743

[xelloss]

If you look very closely at the screenshots, you can see a very slight grey sliver in the folder "tray" area. This is where the three buttons are supposed to be.

Yes. Or at least, that should be the window client area, where the buttons should also find their place.
I guess everything will become clearer once I (have the time to) figure out why the taskbar is not positioned as a taskbar.

Also, one of the reasons for why certain features (such as icons) don't work correctly is that the user interface is relying heavily on entries in the registry (SYSTEM.DAT and USER.DAT), and if those entries are not available, then the user interface will not be able to find the correct settings required for each function.

Could be, but it's unlikely because I'm monitoring all of the accesses to the registry.
In one of my first attempts at running file cabinet, the program would immediately complain that critical registry information was not available, and abort. To see this behaviour, install the program but don't open the cabinet.reg attached.

And if you really want to know the reason for why the earlier versions of the Chicago/Windows 4.0 (Windows 95) shell were 16-bit instead of 32-bit, well, the reason for that is here:

Yeah, makes sense. It's a pity that MS never bothered documenting Win16 v.4.0 though.

[SoftPCMuseum]

Could be, but it's unlikely because I'm monitoring all of the accesses to the registry.
In one of my first attempts at running file cabinet, the program would immediately complain that critical registry information was not available, and abort. To see this behaviour, install the program but don't open the cabinet.reg attached.

From what I remember, there was much more to the registry entries for the user interface (even in those early builds) than just what was necessary in order for it to run at all - there are also the registry entries required for other functions of the user interface such as system folders, among other such things.

Yeah, makes sense. It's a pity that MS never bothered documenting Win16 v.4.0 though.

The 16-bit version of the Windows 4.0/Chicago (later Windows 95) API was just a temporary workaround until the entire user interface and all of the applications and Control Panel functions were able to be converted to being 32-bit, though certain areas of it likely remained for compatibility if I remember correctly.

[xelloss]

From what I remember, there was much more to the registry entries for the user interface (even in those early builds) than just what was necessary in order for it to run at all - there are also the registry entries required for other functions of the user interface such as system folders, among other such things.

I think so, but it doesn't look like those entries are being accessed as of yet.

The 16-bit version of the Windows 4.0/Chicago (later Windows 95) API was just a temporary workaround until the entire user interface and all of the applications and Control Panel functions were able to be converted to being 32-bit, though certain areas of it likely remained for compatibility if I remember correctly.

Well, "workaround" was Microsoft's wish, I guess; but the Win16 v.4.0 API, which was not included in NT 4.0, was later added to Windows 2000. This was most likely because some third party programs depended on it.

It is generally possible to make out the 16 bit functions by comparing them to the 32 bit version, but you'll have to be careful because DWORD parameters iin the 32 bit version might correspond to WORDs in Win16. Quite a mess.

[SoftPCMuseum]

Sorry, I tested your project that you provided, and it doesn't work at all. I tried it specifically on Windows 3.1 in 386 Enhanced Mode and with the exact directions that you provided, but I never made it past this message:

Did you possibly forget to include some files that are necessary for it to work, or does it simply not run on anything other than your particular Windows for Workgroups 3.11 installation?
EDIT: Actually, I found the solution. Apparently, this program needs COMMCTRL.DLL, which is only installed by default in Windows for Workgroups 3.11, so I extracted the file directly from Windows for Workgroups 3.11 Disk 2, and the program runs.

However, it doesn't appear to do much at all. I couldn't even open any of the properties dialog boxes, let alone open new folders or anything like that.

Also, it appears that I might not have been completely correct regarding the silver areas, since it seems that those areas are used for moving the "tray" itself. Also, the silver area is even larger when resizing that same area of the screen.

[xelloss]

EDIT: Actually, I found the solution. Apparently, this program needs COMMCTRL.DLL, which is only installed by default in Windows for Workgroups 3.11, so I extracted the file directly from Windows for Workgroups 3.11 Disk 2, and the program runs.

Yes, it uses COMMCTRL from WFW 3.11. As a rule of thumb, I'm trying to reuse as much of Win3.xx as possible, which means I wouldn't want to use COMMCTRL from Chicago 58s (which might in turn depend on other Chicago stuff, etc.)

However, it doesn't appear to do much at all. I couldn't even open any of the properties dialog boxes, let alone open new folders or anything like that.

For the moment, you can right click tth desktop and create folders there, and that's it.
Naturally, this work is not interesting for the purpose of using File Cabinet as a shell replacement (unless perhaps in the distant future, assuming that no critical ties to the new API are found).
It is more interesting for the purpose of documenting the evolution of the Windows API during development.
For instance, to create the Desktop window, File Cabinet needs to know the size of the system work area: so it asks USER, but that's a question whose answer it doesn't know (in Windows 3.xx). So it replies zero, and the desktop is created as a window of null size...

This is my workaround:

Code: Select all

int _far _pascal MyGetSystemMetrics(int nIndex) {
	#define	SM_XWORKAREA	58
	#define	SM_YWORKAREA	59
	#define	SM_CXWORKAREA	60
	#define	SM_CYWORKAREA	61
#ifdef DBG_XWIN
	/* fprintf(dbglog, "GetSystemMetrics(%hd)\n", nIndex); */
#endif DBG_XWIN
	
	switch (nIndex) {
	case SM_XWORKAREA:
	case SM_YWORKAREA:
		return 0;
		
	case SM_CXWORKAREA:
		nIndex = SM_CXSCREEN;
		break;
		
	case SM_CYWORKAREA:
		nIndex = SM_CYSCREEN;
		break;
	}
	
	return GetSystemMetrics(nIndex);
}

You see that I simply replace the work area size with the screen size: the two values should only be different in a multi-screen scenario, which Windows 3.x doesn't support.
(As for the defines, I got them from the NT4 source: they were buried in the code for some driver.)

Also, it appears that I might not have been completely correct regarding the silver areas, since it seems that those areas are used for moving the "tray" itself. Also, the silver area is even larger when resizing that same area of the screen.

As I said, it's the client area, or the empty/background area of the window, and you are right: the tray ListView doesn't follow a resize of the main window. In fact, all the sizing in that window is wrong, and only CodeView can tell why.

[Overdoze]

Very interesting, thanks for sharing this.

[xelloss]

You see that I simply replace the work area size with the screen size: the two values should only be different in a multi-screen scenario, which Windows 3.x doesn't support.

Well, no. The workarea is the screen minus the area occupied by docked toolbars, like the taskbar.
The shell and other programs can call SystemParametersInfo to resize the workarea, but only since Windows 95.

So SystemParametersInfo must be patched and (slightly more annoying, but also more interesting) a system-wide window procedure hook must be installed to make sure windows are normally maximized to the workarea and not to the (larger) screen. The right way of doing this should be by intercepting the WM_GETMINMAXINFO message, although Calmira changes the WM_WINDOWPOSCHANGING message instead. They might have good reasons for doing so, but it may also be due to ignorance. There's only one way to know...

[yuhong]

It is funny that they never documented many of the new Win95 16-bit functions.

[nixie]

Offtopic Comment

It is funny that they never documented many of the new Win95 16-bit functions.

In those days, a large chunk of the internals were intentionally left undocumented, which had a large hand in the anti-competitive allegations.

That aside, they were trying to move to a greatly improved 32-bit design and providing new and better 16-bit offerings would only slow that process.

[xelloss]

Offtopic Comment

It is funny that they never documented many of the new Win95 16-bit functions.

In those days, a large chunk of the internals were intentionally left undocumented, which had a large hand in the anti-competitive allegations.

That aside, they were trying to move to a greatly improved 32-bit design and providing new and better 16-bit offerings would only slow that process.

I guess there was no real reason to provide up-to-date documentation, but we lack even up-to-date header files and import libraries (there's something in a few beta SDKs, but those too are incomplete).

The reasons why MS decided to do so are legitimate and certainly do not entail anti-competitive behaviour (in this particular case). However, for historical research it's a less than ideal situation.

(Btw, inspection of NT4 and Win2k source code suggests that the new 16 bit API was not in the former, but was ported to the latter, probably because they wanted to achieve 100% compatibility, and some programs had started relying on the undocumented Win95 16 bit API, as it always happens).

[yuhong]

Offtopic Comment

It is funny that they never documented many of the new Win95 16-bit functions.

In those days, a large chunk of the internals were intentionally left undocumented, which had a large hand in the anti-competitive allegations.

That aside, they were trying to move to a greatly improved 32-bit design and providing new and better 16-bit offerings would only slow that process.

I guess there was no real reason to provide up-to-date documentation, but we lack even up-to-date header files and import libraries (there's something in a few beta SDKs, but those too are incomplete).

Closest thing to that is probably what is in the Win9x DDKs.

[ToMi1]

Doesn't work.

[xelloss]

Doesn't work.

I haven't worked on it since. Hooking window resizing was creating all sorts of incompatibilities with certain applications, and at a certain point I got bored and gave up.
Anyway, what kind of error do you get? Remember that even after patching, this File Cabinet doesn't do much. It's more like an experiment to understand how much the API changed between Win3.11 and the earliest Chicago beta we have.

[ToMi1]

OK, Thanks for info.

[Pikavolt321]

I know this is an old thread, but does this patched Cabinet work on Windows 95? And if so, does it work the same as on Windows 3.1, or does it work slightly better?

[xelloss]

I know this is an old thread, but does this patched Cabinet work on Windows 95? And if so, does it work the same as on Windows 3.1, or does it work slightly better?

I've never tried it, but chances are that it works worse than in Windows 3.1, because the early Chicago shell API Chicago differs from both Windows 3.1 and Windows 95. My patch tried to make up for some of the incompatibilities with 3.1, but does nothing to fix the problems with Windows 95 final.

[xdman6000]

The download seems to be taken down