Compiling apps for Windows 1.0 Alpha Release, Beta Release and Premiere Edition

[Lucas Brooks]

After months of testing and researching, we can finally compile apps for Windows 1.0 Alpha Release, Beta Release and Premiere Edition! Windows 1.0 Alpha Release came with all the Windows libraries, development utilities and sample source code but because we don't have the Microsoft C Compiler 3.00 Windows Toolkit, compiled objects will not link with DOS libraries properly. We do not have the Beta Release or Premiere Edition SDKs so I don't think anyone even thought about compiling apps for them.

Alpha Release

Toolchain download: https://mega.nz/file/0N01jCoa#b2FasayGH ... uRGJO-EdT8

This is not my first attempt to compile apps for Alpha Release but the first time I have succeeded. As I said before, Alpha Release contains everything we need (it is the most complete Windows 1.0 pre-release) but we do not have the proper libraries. I tried to compile some sample again yesterday and I decided to disassemble and compare the (failed) output to the samples Microsoft compiled 35 years ago. I noticed my output contained a chunk of extra code (__cinit, __exit, __ctermsub, unknown, __astart, __cintDIV, __amsg_exit, __NMSG_TEXT, __NMSG_WRITE, __setenvp, __setargv, unknown2, unknown3, __nullcheck and __myalloc) from SLIBC's crt0 and they caused all those errors I have encountered before. I guess it should be possible to replace those functions with dummy ones but that would be a lot of work so I started to look for libraries designed for Windows and I tried RTM's SWLIBC.LIB. It worked better than Microsoft C Compiler's SLIBC.LIB (designed for DOS) but still failed with an unresolved external. I then tried SWINLIBC.LIB and failed with 8 duplicated functions but no unresolved externals. That was a good sign so I renamed those 8 functions (replaced the last letter with 2) then all samples compiled and linked without a single error! I then tested the samples I compiled and they worked perfectly on Alpha Release - icons can render correctly as well.

Now we can port some apps to Alpha Release but since we already have all the samples, porting apps from RTM's SDK wouldn't be fun at all so I decided to try Charles Petzold's Birthday Cake application. I encountered 48 errors the first time because I used the wrong WINDOWS.H but I managed to fix all the actual errors in the end.



The biggest problem was whenever I click Decoration → Settings, it fails with invalid module handle. I soon discovered DialogBox wants another parameter and with that fixed, it will open the settings dialog. There was another problem - clicking OK or Cancel does nothing so I add OK and Cancel to the menu (like all other Alpha Release apps). Well, clicking any of the options gives me the invalid task handle error so that was definitely not the right thing to do. jb881122 pointed out that SettingsProc should have an extra parameter (lpResult) because Alpha Release's MapModes does and with that parameter added, the setting dialog became functional - but not fully.





Clicking the checkbox does nothing and we have tried to fix it (by messing with SendDlgItemMessage CheckDlgButton) but none of the fixes were good. With fixes applied, it is possible to add firework and flashing effects but there is no way to uncheck the box once checked so it is probably a better idea to leave that for someone more experienced to fix. You can download a buggy version of Birthday Cake here: https://mega.nz/file/NBtAgSzb#Eo2xkkEHm ... PFQrhhdFDk

Beta Release

Toolchain download: https://mega.nz/file/1M03RKJL#hNT1yjz5s ... 9qtpmaRb7M

Since we have access to ~10% of the Beta Release SDK (all Windows libraries, some development utilities and sample source code), it is possible to develop applications for Beta Release. API changes (such as different ordinal numbers and application initialization procedure) prevented us from using Windows 1.01's SDK to compile apps for Beta Release so we must use the incomplete SDK. The main problem here is still SLIBC.LIB (more precisely, the duplicated function names and unresolved _main function). I have successfully compiled Beta Release apps with Microsoft C Compiler 4.00's libraries before but it will not work due Beta Release being incompatible with later SLIBW.LIB. I tried to use Microsoft C Compiler 3.00 and 4.00's SLIBC.LIB to compile Windows Hello for Beta Release and it failed with 2 errors (unresolved externals in the winstart function). I managed to get the app to start by manually removing the bad image attribute from the NE header and running RC but the application icon did not not render properly.

Since I managed to compile Alpha Release apps with a modified SWINLIBC.LIB, it wouldn't hurt to try that on Beta Release and it worked! Then I tried to port some SDK programs from Alpha Release and RTM's SDK. Apps written for Beta Release and later builds are compatible at source level (except for some font and OEM stuff we rarely use) so RTM's SDK programs can be compiled for Beta Release without any modifications. Alpha Release apps are a bit hard to port because some functions (such as DialogBox) have different number of parameters and they are more likely to crash. Below is Beta Release with Hello (from Beta Release), Font Tester (from RTM), Shapes (from RTM) and MapModes (from Alpha Release) running:



More complex apps such as Birthday Cake can of course be recompiled for Beta Release as well and it is fully functional (except for the font part because Beta Release does not have the Script font):



Download here: https://mega.nz/file/tB8XwYCK#sANKx2nDS ... klNmCRvnpo

Premiere Edition

Toolchain download: https://mega.nz/file/MB8AHQAa#O_pOVb393 ... mmaPQfkSOk

This is not as exciting as the previous 2 because most apps compiled for RTM will run on Premiere Edition but since we have one of those sample programs and WINDOWS.H, I decided to make a toolchain for it. Actually, I did this more than a month ago and shared it on Discord but I'll use this opportunity to share it on the forums as well. We don't have any libraries that came with Premiere Edition's SDK and Microsoft C Compiler 3.00's libraries does not link properly so I decided to use Microsoft C Compiler 4.00 for this and it worked perfectly. This is not new at all but Premiere Edition's Hello Windows does say 1.01 in the about dialog:



Well, I am not going to port any apps from RTM's SDK because most RTM programs does work on Premiere Edition (including Birthday Cake) so if you want to port those apps yourself, go ahead.

So...
Please note that I do not have the Windows Toolkit, Beta Release and Premiere Edition's SDK so all my toolchains involves a few hacks (such as renamed functions). If you are going to use weird library functions, there is no promise that it will work even though it should. Please don't use medium or large model libraries because I did not patch them and they will likely produce errors (Alpha Release and Beta Release does not support them anyway).

----

Edit: Updated the Alpha Release and Beta Release toolchains to include medium model libraries. Moved some include files to Beta Release's LIB directory and removed them from the Birthday Cake program. I did not bother to do the same thing for Premiere Edition's toolchain because you can just use the RTM SDK to compile apps for it.

[yksoft1]

Did try my old BadApple! "player" for Win1/2 source and partly succeeded.



If I can find my old Winmine port source from WinNT4 source's Winmine, I might try it for that.

[xelloss]

Thanks ComputerHunter! This finally allows us to investigate one of the mysteries of the Windows API: the window message number 4, sometimes referred to as WM_SIZEWAIT. This message isn't documented anywhere, is not known to be delivered by Windows in any public release, and is essentially unknown. It is rarely mentioned by name in certain old includes from less common kits (e.g. ddk, but not sdk) and in Microsoft private code.

We can now confirm that WM_SIZEWAIT was introduced in the Windows 1.0 beta and was still present in the Premiere Edition. Windows sends it to a window that is about to be resized, but only in certain conditions: for instance, if I'm resizing a window A and, as a consequence, the size of another window B has to change, WM_SIZEWAIT will be sent to B, but not to A. The parameters to the message appear to always be zero.

It is currently unknown what a window could do with a WM_SIZEWAIT message, other than logging it. Perhaps the window can return a different value to indicate to the window manager how it would want to be resized, or to deny resizing.

I believe WM_SIZEWAIT was removed between the Premiere Edition and version 1.01 RTM, which is why there was never reason to document it. Clearly by that time it was already impossible to reassign the message number 4 to a different task, because it could have caused malfunctioning in programs that made assumptions about it.

I've compiled a quick and dirty analyzer for messages WM_SIZE and WM_SIZEWAIT: it prints the last message received for each of the two categories, and additionally beeps every time it receives WM_SIZEWAIT. SZSPYB.EXE is compiled for the beta, while SZSPYRTM.EXE was built using the 2.11 OAK but is compatible with all earlier versions starting from the Premiere edition (and works in version 3.11 too, albeit with a warning dialog). If no message of a certain kind has been received, it'll show question marks as its parameters.

Download Size Spy

[Lucas Brooks]

Since both Alpha Release and Beta Release supported the use of medium model libraries, I decided to add some patched medium libraries to the toolchains. I have tested them on both Alpha Release and Beta Release so they should be working. I have already updated the links.

I noticed that the Beta Release SDK files we have should be from a post-Beta Release build because they support functions introduced after Beta Release such as FlashWindow (USER ordinal 185). If you would like to port apps such as Template from RTM to Beta Release, you will have to comment out the FlashWindow function otherwise you will get an invalid ordinal reference error if you attempt to run the compiled executable.

The other thing I have discovered is Premiere Edition branded Windows Hello existed as well. For some reason, the RM Nimbus PC-186 Windows 1.02 SDK included a Premiere Edition branded HELLO.EXE compiled on the 14th of February 1986 to demonstrate how to debug a Windows application. I have absolute no idea about the story behind this and here is a picture:



Also, please note that Alpha Release's Font Tester (FONTTEST) will not link properly with the libraries I have provided in the toolchain but if you run "mapsym fonttest" and "rc fonttest.rc" at the DOS prompt after seeing the error messages, it will create a working executable. Those errors also happens on DR5 but they can be fixed by adding them to MC.DAT (Windows Module compiler definition file) and it was already done by Microsoft. I don't know how to fix them for Alpha Release yet.