BetaArchive Logo
Navigation Home Database Screenshots Gallery Image Uploader Server Info FTP Servers Wiki Forum RSS Feed Rules Please Donate
UP: 16d, 19h, 48m | CPU: 29% | MEM: 5417MB of 11705MB used
{The community for beta collectors}

Post new topic Reply to topic  [ 19 posts ] 
Author Message
 PostPost subject: File Cabinet (from Chicago 58s) patch for Windows 3.11        Posted: Sun Dec 10, 2017 9:54 pm 
Reply with quote
Donator
User avatar
Offline

Joined
Sun Aug 18, 2013 7:26 pm

Posts
278

Location
Edinburgh, Scotland

Favourite OS
Windows for Workgroups 3.11
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:

Image

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.

Image

Image

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?

Image

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


Top  Profile
 PostPost subject: Re: File Cabinet (from Chicago 58s) patch for Windows 3.11        Posted: Sun Dec 10, 2017 11:29 pm 
Reply with quote
FTP Access
User avatar
Offline

Joined
Thu May 01, 2014 10:26 pm

Posts
1500

Location
Inside the space between . and I

Favourite OS
Nashville 4.00.83
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.

_________________
Image
You cannot escape Windows 10.


Top  Profile
 PostPost subject: Re: File Cabinet (from Chicago 58s) patch for Windows 3.11        Posted: Sun Dec 10, 2017 11:55 pm 
Reply with quote
FTP Access
User avatar
Offline

Joined
Sat Sep 10, 2011 9:46 am

Posts
251

Favourite OS
OltScript System
I can not download it... MEGA asks me for a decryption key... :beta: :(

_________________
More information of OltScript System : http://www.win3x.org/win3board/viewtopi ... 69&t=15677
Internetometer : http://internetometer.com/give/46797
Image


Top  Profile  WWW
 PostPost subject: Re: File Cabinet (from Chicago 58s) patch for Windows 3.11        Posted: Sun Dec 10, 2017 11:57 pm 
Reply with quote
Donator
User avatar
Offline

Joined
Sun Aug 18, 2013 7:26 pm

Posts
278

Location
Edinburgh, Scotland

Favourite OS
Windows for Workgroups 3.11
Jajan131 wrote:
I can not download it... MEGA asks me for a decryption key... :beta: :(

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

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


Top  Profile
 PostPost subject: Re: File Cabinet (from Chicago 58s) patch for Windows 3.11        Posted: Mon Dec 11, 2017 12:26 am 
Reply with quote
FTP Access
User avatar
Offline

Joined
Sun Feb 01, 2015 2:15 am

Posts
139
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/oldnewthing/20070129-02/?p=28233
https://blogs.msdn.microsoft.com/oldnewthing/20120102-00/?p=8743

_________________
Image
Latest release of Virtual Computer emulator available here:
https://www.betaarchive.com/forum/viewtopic.php?f=72&t=39197


Top  Profile  WWW
 PostPost subject: Re: File Cabinet (from Chicago 58s) patch for Windows 3.11        Posted: Mon Dec 11, 2017 1:00 am 
Reply with quote
Donator
User avatar
Offline

Joined
Sun Aug 18, 2013 7:26 pm

Posts
278

Location
Edinburgh, Scotland

Favourite OS
Windows for Workgroups 3.11
SoftPCMuseum wrote:
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.

Quote:
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.

Quote:
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.


Top  Profile
 PostPost subject: Re: File Cabinet (from Chicago 58s) patch for Windows 3.11        Posted: Mon Dec 11, 2017 1:56 am 
Reply with quote
FTP Access
User avatar
Offline

Joined
Sun Feb 01, 2015 2:15 am

Posts
139
xelloss wrote:
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.
xelloss wrote:
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.

_________________
Image
Latest release of Virtual Computer emulator available here:
https://www.betaarchive.com/forum/viewtopic.php?f=72&t=39197


Top  Profile  WWW
 PostPost subject: Re: File Cabinet (from Chicago 58s) patch for Windows 3.11        Posted: Mon Dec 11, 2017 2:07 am 
Reply with quote
Donator
User avatar
Offline

Joined
Sun Aug 18, 2013 7:26 pm

Posts
278

Location
Edinburgh, Scotland

Favourite OS
Windows for Workgroups 3.11
SoftPCMuseum wrote:
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.

Quote:
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.


Top  Profile
 PostPost subject: Re: File Cabinet (from Chicago 58s) patch for Windows 3.11        Posted: Mon Dec 11, 2017 3:14 am 
Reply with quote
FTP Access
User avatar
Offline

Joined
Sun Feb 01, 2015 2:15 am

Posts
139
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:
Image
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.

_________________
Image
Latest release of Virtual Computer emulator available here:
https://www.betaarchive.com/forum/viewtopic.php?f=72&t=39197


Top  Profile  WWW
 PostPost subject: Re: File Cabinet (from Chicago 58s) patch for Windows 3.11        Posted: Mon Dec 11, 2017 11:47 am 
Reply with quote
Donator
User avatar
Offline

Joined
Sun Aug 18, 2013 7:26 pm

Posts
278

Location
Edinburgh, Scotland

Favourite OS
Windows for Workgroups 3.11
SoftPCMuseum wrote:
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.)

SoftPCMuseum wrote:
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:
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.)

Quote:
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.


Top  Profile
 PostPost subject: Re: File Cabinet (from Chicago 58s) patch for Windows 3.11        Posted: Mon Dec 11, 2017 8:28 pm 
Reply with quote
FTP Access
User avatar
Offline

Joined
Mon Feb 24, 2014 10:28 am

Posts
1583

Location
Slovenia

Favourite OS
5111
Very interesting, thanks for sharing this. :)

_________________
Image

KRNL386 - my site about retro computing | My site about Windows 1.0 | My blog | 86Box Manager - my configuration manager for 86Box


Top  Profile
 PostPost subject: Re: File Cabinet (from Chicago 58s) patch for Windows 3.11        Posted: Tue Dec 12, 2017 1:03 pm 
Reply with quote
Donator
User avatar
Offline

Joined
Sun Aug 18, 2013 7:26 pm

Posts
278

Location
Edinburgh, Scotland

Favourite OS
Windows for Workgroups 3.11
xelloss wrote:
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...


Top  Profile
 PostPost subject: Re: File Cabinet (from Chicago 58s) patch for Windows 3.11        Posted: Thu Jan 04, 2018 4:58 am 
Reply with quote
Offline

Joined
Mon Nov 13, 2017 6:47 am

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


Top  Profile
 PostPost subject: Re: File Cabinet (from Chicago 58s) patch for Windows 3.11        Posted: Thu Jan 04, 2018 3:53 pm 
Reply with quote
Offline

Joined
Thu Oct 19, 2017 2:33 pm

Posts
37

Location
in his mother's basement

Favourite OS
netbsd
Offtopic Comment
yuhong wrote:
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.


Top  Profile
 PostPost subject: Re: File Cabinet (from Chicago 58s) patch for Windows 3.11        Posted: Fri Jan 05, 2018 6:38 pm 
Reply with quote
Donator
User avatar
Offline

Joined
Sun Aug 18, 2013 7:26 pm

Posts
278

Location
Edinburgh, Scotland

Favourite OS
Windows for Workgroups 3.11
nixie wrote:
Offtopic Comment
yuhong wrote:
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).


Top  Profile
 PostPost subject: Re: File Cabinet (from Chicago 58s) patch for Windows 3.11        Posted: Sun Jan 07, 2018 9:27 am 
Reply with quote
Offline

Joined
Mon Nov 13, 2017 6:47 am

Posts
17
xelloss wrote:
nixie wrote:
Offtopic Comment
yuhong wrote:
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.


Top  Profile
 PostPost subject: Re: File Cabinet (from Chicago 58s) patch for Windows 3.11        Posted: Sun Sep 01, 2019 12:05 pm 
Reply with quote
User avatar
Offline

Joined
Wed May 15, 2019 2:40 pm

Posts
42

Location
Czechia

Favourite OS
DOS to Windows 9x
:( Doesn't work.

_________________
the.86box.user


Top  Profile
 PostPost subject: Re: File Cabinet (from Chicago 58s) patch for Windows 3.11        Posted: Mon Sep 02, 2019 11:04 am 
Reply with quote
Donator
User avatar
Offline

Joined
Sun Aug 18, 2013 7:26 pm

Posts
278

Location
Edinburgh, Scotland

Favourite OS
Windows for Workgroups 3.11
ToMi1 wrote:
:( 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.


Top  Profile
 PostPost subject: Re: File Cabinet (from Chicago 58s) patch for Windows 3.11        Posted: Mon Sep 02, 2019 5:42 pm 
Reply with quote
User avatar
Offline

Joined
Wed May 15, 2019 2:40 pm

Posts
42

Location
Czechia

Favourite OS
DOS to Windows 9x
OK, Thanks for info.

_________________
the.86box.user


Top  Profile
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 19 posts ] 




Who is online

Users browsing this forum: No registered users and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  

All views expressed in these forums are those of the author and do not necessarily represent the views of the BetaArchive site owner.

Powered by phpBB® Forum Software © phpBB Group

Copyright © 2006-2019

 

Sitemap | XML | RSS