Closed WindowsNinetyTen closed 2 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.
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.
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)
I tried to follow the directions in the minnt readme file.
Good for you, but can you please check the things I mentioned above, otherwise I won't be able to help you.
As you still haven't provided the requested logfiles, can I assume the problem as solved and close the issue?
Oh. Sorry about the lack of reply. I have been busy with work for college. I will provide the files as soon as possible.
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.
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.
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 X86GFX
line, this gets added by patch.
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.
Waht output do you see in DebugView on start of ntvdm?
How can I see DebugView?
Check that Capture/Capture Win32 is checked
Should I look in the WORK directory?
I thought you have problems starting ntvdm.exe, so that is closes immediately. Start debugview, start DOS application, check log displayed in debugview.
I have problems starting NTVDM or any DOS application.
So what's your DebugView output then?
I don't know how to get there.
Oh dear... I mean, srsly...?
1) Download DebugView.zip 2) Unzip DebugView.zip 3) Doubleclick on Dbgview.exe
Here's the log.
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?
No feedback has been given within 18 months, assuming that problem got resolved in the meantime with newer NTVDM builds.
Should I still download the German 7-Zip anyway?