leecher1337 / ntvdmx64

Run Microsoft Windows NTVDM (DOS) on 64bit Editions
808 stars 81 forks source link

Prepare.cmd file prompts me to install 7-Zip German version even though I already have the English Installed and NTVDM still doesn't work #91

Closed WindowsNinetyTen closed 2 years ago

WindowsNinetyTen commented 4 years ago

Should I still download the German 7-Zip anyway?

leecher1337 commented 4 years ago

The language version is irrelevant. The only point is that the 7z.exe should be reachable from commandline, thus, 7-zip is in PATH The script was unable to execute 7z.exe which means that it's not in path. You can try to patch the prepare.cmd in order to detect it from Registry. Please let me know if it works. If so, I'd update the prepare.cmd. Please replace the lines

7z >nul 2>&1
if errorlevel 255 (
echo Please install 7zip first, then run again
start http://www.7-zip.de
pause
goto fini
)

with

7z >nul 2>&1
if errorlevel 255 (
for /F "skip=2 tokens=3*" %%r in ('reg query "HKEY_LOCAL_MACHINE\SOFTWARE\7-zip" /v Path') do echo set PATH=%PATH%;%%r
7z >nul 2>&1
if errorlevel 255 (
echo Please install 7zip first, then run again
start http://www.7-zip.de
pause
goto fini
)
)

That should query the 7Z path from registry as a fallback and put it in PATH.

WindowsNinetyTen commented 4 years ago

Never mind. I fixed the problem. However, after installation neither NTVDM nor any DOS programs work. They just show up black and then close. Also, during the bld-minnt.cmd process, I get a message at one point saying "This app can't run on your PC" and the end result is only 813 files binplaced, instead of 815 files.

WindowsNinetyTen commented 4 years ago

bildo

leecher1337 commented 4 years ago

Could it be that you have some DOS-utilities with the same name in your PATH which have a higher priority than the SDK tools shipped with NTOSbe? There was a similar issue here #76

You can attach your buildchk.log and buildchk.err here, for further analysis, but first check your path. Also ensure that you did the correct build (bld-minnt.cmd should set set CCPU=1, if this environment variable isn't set, MONITOR build would be built which of course won't work on your machine)

WindowsNinetyTen commented 4 years ago

I tried to follow the directions in the minnt readme file.

leecher1337 commented 4 years ago

Good for you, but can you please check the things I mentioned above, otherwise I won't be able to help you.

leecher1337 commented 4 years ago

As you still haven't provided the requested logfiles, can I assume the problem as solved and close the issue?

WindowsNinetyTen commented 4 years ago

Oh. Sorry about the lack of reply. I have been busy with work for college. I will provide the files as soon as possible.

WindowsNinetyTen commented 4 years ago

buildchk.log Here is the buildchk.log file. buildchk.zip Here is the buildchk.err file in a zip folder. I had to put it in a zip folder because the message bard does not directly support .err files. The path is C:\WORK. And in the bld-minnt.cmd file, CCPU is already set to 1.

leecher1337 commented 4 years ago

Can you attach your c:\WORK\minnt\base\mvdm\softpc.new\host\inc\nt_reset.h here? Maybe it got patched twice for whatever reason and got destroyed by it?

Also: Did you download the most recent ntvdmpatch released just a few days ago and the most recent NTOSBE from stephanos' repository? Just asking, because I tested this combination just recently before releasing, so I have proof that it works here and we have the same build to verify.

WindowsNinetyTen commented 4 years ago

nt_reset.zip

leecher1337 commented 4 years ago

The #ifdef X86GFX in your nt_reset.h is in there twice, so the file got patched twice instead of only once. As there is only one .patch file modifying the file, an error in the patchset can be ruled out. Please verify your build steps and ensure that you didn't run the patch.cmd twice and that you start off with a clean copy of minnt, because it looks like either your minnt-source is not clean or the patch gets applied more than once. A clean nt_reset.h doesn't contain the #ifdef X86GFXline, this gets added by patch.

WindowsNinetyTen commented 4 years ago

I did run it twice. And I did it because I had the same problem of NTVDM flashing and then closing, even after following the steps for the first time.

leecher1337 commented 4 years ago

Waht output do you see in DebugView on start of ntvdm?

WindowsNinetyTen commented 4 years ago

How can I see DebugView?

leecher1337 commented 4 years ago

Check that Capture/Capture Win32 is checked

WindowsNinetyTen commented 4 years ago

Should I look in the WORK directory?

leecher1337 commented 4 years ago

I thought you have problems starting ntvdm.exe, so that is closes immediately. Start debugview, start DOS application, check log displayed in debugview.

WindowsNinetyTen commented 4 years ago

I have problems starting NTVDM or any DOS application.

leecher1337 commented 4 years ago

So what's your DebugView output then?

WindowsNinetyTen commented 4 years ago

I don't know how to get there.

leecher1337 commented 4 years ago

Oh dear... I mean, srsly...?

1) Download DebugView.zip 2) Unzip DebugView.zip 3) Doubleclick on Dbgview.exe

WindowsNinetyTen commented 4 years ago

NTVDM.LOG

WindowsNinetyTen commented 4 years ago

Here's the log.

leecher1337 commented 4 years ago

It seems that NTVDM initializes correctly by checking, if iti is the first VDM, but then silently dies without raising an error. Can you check your Windows Application log if there are traces of a crash of NTVDM.EXE?

leecher1337 commented 2 years ago

No feedback has been given within 18 months, assuming that problem got resolved in the meantime with newer NTVDM builds.