Some files are missing when I try to install wow32

[kristibektashi]

Specifically regedit16.exe, wifeman.dll and winnls.dll

Note: I manually compiled NTVDMx64 on a Windows 10 32-bit VM using latest versions of everything

[leecher1337]

Do you have errors in minnt\base\buildchk.err, so that applications didn't get built? Does mvdm\wow16\wifeman exist (recostructed wifeman is contained in ntvdmpatch and should be copied there)? Did makefile get patched properly so that mvdm\wow16\makefile contain:

    cd ..\wifeman
    $(MAKE)

?

Do you have a proper wifeman.dll in mvdm\wow16\wifeman ? Do you have mvdm\wow16\debug\regedt16.exe ?

[kristibektashi]

buildchk.zip This is my buildchk.err file (located in C:\work\minnt\base\buildchk.err and in a zip cause GitHub doesn't support err files)

C:\work\minnt\base\mvdm\wow16\wifeman folder does exist (I guess that's what you meant)

C:\work\minnt\base\mvdm\wow16\makefile does contain the lines you mentioned

There is no dll file in C:\work\minnt\base\mvdm\wow16\wifeman (you probably meant another directory)

C:\work\minnt\base\mvdm\wow16\debug directory simply doesn't exist

[leecher1337]

The existence of buildchk.err indicates that there is at least one build error. To further analyze this, please also upload buildchk.log

Sorry about the confusion regarding wifeman.dll and regedt16.exe, seems that I looked in the wrong source tree myself when writing this. If built, regedt16.exe should be located in mvdm\wow16\regedit\usa\objchk\x86 and wifeman.dll in mvdm\wow16\wifeman\usa\objchk\x86 If the files are there, it's just a matter of bad binplacing, if not, maybe there are build errors, but buildchk.log should shed some light on this.

[kristibektashi]

buildchk.log Here is my buildchk.log file (same directory as the err file)

I found a regedt16.exe (instead of regedit16.exe) in C:\work\minnt\base\mvdm\wow16\regedit\debug

I also found a regedit.exe (instead of regedit16.exe, confirmed it is 16-bit because it launches with NTVDM on 32-bit windows) on C:\work\minnt\base\mvdm\bin86 (probably unrelated but worth mentioning)

C:\work\minnt\base\mvdm\wow16\regedit\usa and C:\work\minnt\base\mvdm\wow16\wifeman\usa directories do not exist

I also checked on C:\work\Binaries\x86chk, regedit16.exe and wifeman.dll don't exist anywhere

Also I like how you just forgot about winnls.dll (I already checked C:\work\minnt\base\mvdm\wow16\winnls, no usa folder and no winls.dll on C:\work\Binaries\x86chk)

Note: I used Windows 10 32-bit on VMware Workstation 16 on a host where Hyper-V is also enabled and there are some performance issues, maybe because of that the build failed. I can try to build NTVDMx64 on a Hyper-V VM or even on my host if I have to or I might just check out the columbia.edu version

[leecher1337]

Ok, judging from the buildchk.log it's pretty clear to me now: The error because of missing upd.exe interrupts the whole build process leading to the missing files, because build process doesn't complete.

This means that when building the NTOSBE tools, upd.exe for some unknown reason wasn't built, as it seems. The prepare.cmd normally extracts upd Tool from odl-src and patches it so that a manifest gets built in that tells Windows to net request privilege evelation to not interfere with build process because of the tool's name:

xcopy /e /y %workdir%\old-src\nt\private\sdktools\upd %minntfix%\NTOSBE-master\src\sdktools\upd\
rem Windows 7 and above has UAC. Its heuristic assumes that if some executable starts with name upd or setup or patch, etc.
rem that it needs to elevate its privileges. This is not the case for upd.exe and would interfere with build process
rem Therefore we need to embed a manifest in upd
echo 1 24 upd.man >>%minntfix%\NTOSBE-master\src\sdktools\upd\upd.rc

When SDK gets built correctly, you should normally end up with this directory structure:

NTOSBE-master\src\sdktools\upd\makefile
NTOSBE-master\src\sdktools\upd\objchk
NTOSBE-master\src\sdktools\upd\sources
NTOSBE-master\src\sdktools\upd\upd.c
NTOSBE-master\src\sdktools\upd\upd.man
NTOSBE-master\src\sdktools\upd\upd.rc
NTOSBE-master\src\sdktools\upd\objchk\x86
NTOSBE-master\src\sdktools\upd\objchk\_objects.mac
NTOSBE-master\src\sdktools\upd\objchk\x86\upd.exe
NTOSBE-master\src\sdktools\upd\objchk\x86\upd.obj
NTOSBE-master\src\sdktools\upd\objchk\x86\upd.pdb
NTOSBE-master\src\sdktools\upd\objchk\x86\upd.res

The upd.exe then should be placed in NTOSBE-master\tools\x86\idw

So either compilation of the upd.exe failed in mktools.cmd step or the binplacing to the idw directory didn't take place properly. Thus, you have to examing the buildlocaltools.cmd x86 execution step in NTOSBE-master directory to check why upd.exe is not build. As soon as it gets built, your compilation run should also run through normally.

Don't expect NTVDMx64 to be fast, it contains an emulated CPU after all, and this is slow, of course. If you can live without graphics and WOW32 support, so just plain DOS Textmode applications, you can try the HAXM build for improved performance.

[kristibektashi]

I didn't run it as administrator. I ran it as normal user. Maybe because of that?

[leecher1337]

The build process shouldn't requiree admin right. As sid,it's just that there is a stupid hardcoded "logic" in Windows Starting with Vista (with the Introduction of UAC), that uses hardcoded names like install, setup, update or upd to request Privilege elevation on execution. This is to support older Installation programs that don't include Manifests and still require elevation. Due to this logic, upd.exe would request admin rights on every execution during build, which is annoying. Therefore the preparation script adds a manifest telling the system to NOT request privilege elevation. It seems that something went wrong when building upd.exe (i.e. resource entry in .res file got added twice, manifest didn't get copied from template directory, or whatever...). You need to check build process of the NTOSBE tools in order to find out.

[kristibektashi]

I reran mktools.cmd, here is the output (copied from command window cause I don't know where log files are stored) mktoolslog.txt

[kristibektashi]

you can try the HAXM build for improved performance

No I can't because Hyper-V is enabled on my host

[leecher1337]

Your log looks fine, have you checked the presence of upd.exe in above mentioned paths after building (specifically in NTOSBE-master\tools\x86\idw )? Maybe it finally is there now after you reran mktools?

Oh, you want to run NTVDMx64 on the host machine where Hyper-V is enabled, I thought that you might want to run it in a VM where you can turn off annoying Hyper-V.

[kristibektashi]

upd.exe does exist now that I reran mktools.cmd, but I decided instead of trying to build it again to go with the columbia.edu version (#7) because it got updated to october 2020 version (last time I checked it had an older version).

BTW if Hyper-V is enabled on your host I don't think you can run HAXM on the host or any guest (Hyper-V or not) and I don't think you can enable Hyper-V on non-Hyper-V VM's (such as VMware)

[leecher1337]

At least nested virtualization works fine with VMWare, that's how I normally test HAXM build (in a VMWare VM). But not sure if Hyper-V causes troubles with nested virtualization.