As the prepatched package was updated with the Microsoft C/C++ 8.0c tools, the
cl.exe and some other tools are 32-bit, they now run fine under x64, but it still contains 16-bit tools that are used by the build process: buildmsg.exe reloc.exe nosrvbld.exe stripdd.exe stripz.exe exe2bin.exe h2inc.exe mkpublic.exe fixexe.exe in \tools\tools16
These remaining 16-bit tools are the reason that \base\mvdm & \com\ole32\olethunk\ole16 could not build on Windows XP x64.
Because of the MS DOS Player's msdos32.exe file (from https://github.com/cracyc/msdos-player) that was included with
win2003_prepatched_v8.zip, I got another idea: a replacement for DOSBox to run the 16-bit tools on WinXP x64. Thanks whoever came up with using this!
When checking the documentation for MS DOS Player, I found that the tool is also able convert a 16-bit application to a 32-bit app (the
-c option does that), however this did not work for rc16.exe as this errored out with
fatal error RW1012: Could not find RCPP.EXE when building with it, so for rc16.exe, renamed to rc16dos.exe as was done before, I used this rc16.bat file:
msdos32 rc16dos %*
So I ended up doing:
- copying that msdos32.exe from the latest prepatched package to \tools, so that it would be in the PATH for other uses
chs cht jpn kor usasubfolders of
\base\mvdm\dos\v86\cmd\commandneed their own custom msbuild.bat file, with
msdos32 msbuild.exe %*
- I still needed to apply the change to the PATHEXT variable, to the msbuild.bat
set PATHEXT=.BAT;.COM;.EXE;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.RB;.RBWto make sure that .BAT took precedence over .EXE as these msbuld.exe files are created every run, not sure where .EXE is exclicitly used in the build commands.
- running the below convert_16bit_buildtools.bat batch file to convert these utilties to 32-bit
- update line 33 in G:\NT\base\mvdm\dos\v86\cmd\command\makefile.sub to
..\..\buildmsg.bat ..\..\..\$(msg)\$(ALT_PROJECT) ..\..\command.skl
The \base\mvdm folder does build except these two errors - which do not seem to impact the build process
- 1>NMAKE : fatal error U1077: 'copy' : return code '0x1'
- 1>NMAKE : fatal error U1073: don't know how to make '\usa\sdk\commdlg\sz.src'
Found a way to get these 16-bit DOS / Windows 3.1 build tools to work under WinXP x64. As well as a way to run Razzle build prompt to build for 32-bit & 64-bit.
When it needs run a 16-bit tool,
- it will popup a Dosbox-X
- it will run the 16-bit command in Dosbox-X
- Dosbox-X will close itself,
- The build process continues.
As files are read from and written to the correct folders, it allows 16-bit stuff to build as a whole with the rest of the 32-bit en 64-bit build process.
I managed to get WOW16 part of MVDM, OLE16, and faxsrv to build while on Windows XP x64.
After starting Razzle prompt in 32-bit build process as my stuff in
The above lines make sure that .BAT has precedence over .EXE - you need to update some
sources files where you drop .EXE extensions to make sure it will run the .BAT file
set PROCESSOR_ARCHITECTURE=x86 , allowed me to start Razzle to build on Windows XP x64 too. Even launching Razzle with
tools\razzle.cmd Win64 Amd64 offline no_certcheck free and additionally setting
set _NTWoWBinsTREE=G:\binaries.x86fre allowed me to build AMD64 binaries.
The trick is to put to start 16-bit tools is to put a batch file next to the executable, like e.g. I put a
masm.bat file to override the 16-bit
First, I installed Win31DOSBox under
G:\NT\tools\Win31DOSBox, available at http://www.columbia.edu/~em36/win31dosbox.html & including link to the needed Windows 3.1 floppy images, to have a Dosbox environment with Windows 3.1,
Then I used the "lowend" build of Dosbox-X, which runs under Windows XP x64, from https://dosbox-x.com/ (the included dosbox release did crash IIRC) to replace dosbox.exe & .dll in the
IIRC, at least one tools needed the
DOSXNT.386 file in the
G:\NT\tools\tools16 folder, so I copied that from
BIN folder of the
masm 6.15 zip file available at http://www2.hawaii.edu/~pager/312/masm%20615%20downloading.htm
These .bat files were added:
buildmsg.bat exe2bin.bat fixexe.bat h2inc.bat masm.bat mkpublic.bat nosrvbld.bat rc16.bat reloc.bat stripdd.bat stripz.bat
The OLE16 tools in
G:\NT\com\ole32\olethunk\ole16\tools, were similar, except for
cl16.exe as it needs DOS Protected Mode
As I already had Windows 3.1 now, I could install Microsoft C/C++ 7.0 under
C:\C700 under Windows 3.1, to get the correct environment to run it. Available here https://winworldpc.com/product/microsoft-c-c/7x
To get Microsoft C/C++ 7.0 to install:
- Create the
disk1 disk2 ... disk9subfolders, for each disk image, that was extracted with 7-zip, under its C: drive at
setup.exeby navigating with the keyboard (mouse did not work) through File Manager and executing
C:\disk1\setup.exeand accepting all the defaults.
I did place this
- simple .bat file for rc16.bat mapsym.bat link16.bat lib16.bat
- win 3.1 boot .bat file for cl16.bat
- link16.exe was also copied to link.exe IIRC
chs cht jpn kor usa subfoldersof
G:\NT\base\mvdm\dos\v86\cmd\commandneed their own custom
It writes two files: a batch file for Windows 3.1 DOS prompt, and a script for
WINCMD.EXE (included when Win31DOSBox installs Windows 3.1) which is started automatically using the
win /b winexit wincmd file.wcs
WINCMD documentation is available here: http://www.columbia.edu/~em36/WinCmdOne.pdf
These lines were added to
[386Enh], to make sure that necesary drivers were loaded to avoid this message:
This is a protected-mode application that requires DPMI (DOS Protected Mode Interface) services. Examples of hosts that provide these services include: - a DOS session under Windows 3.x in enhanced mode - Qualitas' 386MAX or BlueMAX version 6.x
You will get the error message too when you don't run it from the Windows 3.1 DOS Prompt application or without having these loaded in Windows 3.1
Finally as some paths became too long for DOS in
G:\NT\printscan\faxsrv\print\faxprint\faxdrv\win9x\sdk\binw16, which I overcame using a
Q: to shorten them
So I created the following batch file for