Fail minnt repository build system

[peter8777555]

5) Run ntvdmpatch\minnt\mktools.cmd to prepare the build environment tools

---

== Initialising the sizzle environment for building NTOSBE tools ... == Repository Name (NTREPO) = NTOSBE Source Path (NTROOT) = C:\work\NTOSBE-master\src Target Architecture (NTARCH) = x86 Target Build (NTBLD) = chk Target (NTTARGET) = x86chk NTOSBE Root (BEROOT) = C:\work\NTOSBE-master NT Binary Tree (NTTREE) = C:\work\NTOSBE-master\src.bin\x86chk

== Building local tools ... ==

[mkmsg] BUILD: Adding /Y to COPYCMD so xcopy ops won't hang. BUILD: Using 4 child processes BUILD: Object root set to: ==> objchk BUILD: Beginning build phase: 0 BUILD: Object root set to: ==> obj0chk BUILD: Compile and Link for X86 BUILD: Beginning build phase: 1 BUILD: Object root set to: ==> obj1chk BUILD: Compile and Link for X86 BUILD: Beginning build phase: 2 BUILD: Object root set to: ==> obj2chk BUILD: Compile and Link for X86 BUILD: Beginning default build phase BUILD: Object root set to: ==> objchk BUILD: Compile and Link for X86 BUILD: Computing Include file dependencies: BUILD: Examining c:\work\ntosbe-master\src\sdktools\mkmsg directory for files to compile. c:\work\ntosbe-master\src\sdktools\mkmsg c:\work\ntosbe-master\src\sdktools\mkmsg - 2 source files (1,262 lines) BUILD: Saving C:\work\NTOSBE-master\src\build.dat... BUILD: Compiling c:\work\ntosbe-master\src\sdktools\mkmsg directory 1>c:\work\ntosbe-master\makefile.def(4033) : warning U1088: BUILD: NMAKE.EXE -c BUILDMSG=Stop. NTTEST= UMTEST= BUILD_PHASE= NOLINK=1 NOPASS0=1 X86=1 failed - rc = 2 BUILD: Linking c:\work\ntosbe-master\src\sdktools\mkmsg directory 1>c:\work\ntosbe-master\makefile.def(4033) : warning U1088: BUILD: NMAKE.EXE -c BUILDMSG=Stop. LINKONLY=1 NOPASS0=1 NTTEST= UMTEST= BUILD_PHASE= X86=1 failed - rc = 2 BUILD: Done

Failed to copy mkmsg to tools directory.

Error Build aborted.

[leecher1337]

Weird, doesn't occur on my machine. Try the following: edit ntosbe-master\buildlocaltools.cmd and change

build -c to build -c -e

Then try to run mktools.cmd agin and check ntosbe-master\src\sdktools\mkmsg\buildchk.log Maybe you find out which tool in the build chain is causing the error. Maybe rc.exe?

[peter8777555]

ntosbe-master\src\sdktools\mkmsg\buildchk.log

BUILD: Compile and Link for X86 BUILD: Compile and Link for X86 BUILD: Compile and Link for X86 BUILD: Compile and Link for X86 BUILD: Computing Include file dependencies: BUILD: Examining c:\work\ntosbe-master\src\sdktools\mkmsg directory for files to compile. Compiling c:\work\ntosbe-master\src\sdktools\mkmsg directory **** 'NMAKE.EXE -c BUILDMSG=Stop. NTTEST= UMTEST= BUILD_PHASE= NOLINK=1 NOPASS0=1 X86=1' 1>BUILDMSG: Processing c:\work\ntosbe-master\src\sdktools\mkmsg 1>WARNING: missing nmake.err; displaying error numbers without messages.

1>C:\work\NTOSBE-master\makefile.def(4033) : U1088:

1>Stop.

BUILD: NMAKE.EXE -c BUILDMSG=Stop. NTTEST= UMTEST= BUILD_PHASE= NOLINK=1 NOPASS0=1 X86=1 failed - rc = 2 Linking c:\work\ntosbe-master\src\sdktools\mkmsg directory **** 'NMAKE.EXE -c BUILDMSG=Stop. LINKONLY=1 NOPASS0=1 NTTEST= UMTEST= BUILD_PHASE= X86=1' 1>WARNING: missing nmake.err; displaying error numbers without messages.

1>C:\work\NTOSBE-master\makefile.def(4033) : U1088:

1>Stop.

BUILD: NMAKE.EXE -c BUILDMSG=Stop. LINKONLY=1 NOPASS0=1 NTTEST= UMTEST= BUILD_PHASE= X86=1 failed - rc = 2

[leecher1337]

Maybe the makefile.def of your copy of the NTOSBE build environment got damaged somehow? In my copy, it's exactly 133911 bytes. @stephanosio Do you have an idea why this is happening?

[leecher1337]

Can you check your PATH environment variable? Maybe you have another version of nmake in your system path that gets precedence over NTOSBE nmake and spits out the error? Easy check: If you just open a commnd prompt and typ nmake, is there some nmake available?

[peter8777555]

I find the question. My Path include K:\DOS K:\DOS has many tools NMAKE.exe LINK.exe .... So mktools.cmd get WRONG NMAKE..exe LINK.exe I set Path EMPTY and work.

[peter8777555]

Yes. You are right.

Now

[rcdll] "C:\work\NTOSBE-master\src\sdktools\rcdll" BUILD: Adding /Y to COPYCMD so xcopy ops won't hang. BUILD: Using 4 child processes BUILD: Object root set to: ==> objchk BUILD: Beginning build phase: 0 BUILD: Object root set to: ==> obj0chk BUILD: Compile and Link for X86 BUILD: Beginning build phase: 1 BUILD: Object root set to: ==> obj1chk BUILD: Compile and Link for X86 BUILD: Beginning build phase: 2 BUILD: Object root set to: ==> obj2chk BUILD: Compile and Link for X86 BUILD: Beginning default build phase BUILD: Object root set to: ==> objchk BUILD: Compile and Link for X86 BUILD: Loading C:\work\NTOSBE-master\src\build.dat... BUILD: Computing Include file dependencies: BUILD: Examining c:\work\ntosbe-master\src\sdktools\rcdll directory for files to compile. c:\work\ntosbe-master\src\sdktools\rcdll c:\work\ntosbe-master\src\sdktools\rcdll - 1 Pass Zero files (1,793 lines) BUILD: Building generated files in c:\work\ntosbe-master\src\sdktools\rcdll directory 1>Compiling message file - rcmsgs.mc for all platforms 1>rcmsgs.mc(43) : error : Unterminated message definition 1>NMAKE : U1077: 'mc' : return code '0x1' BUILD: NMAKE.EXE -c BUILDMSG=Stop. NTTEST= UMTEST= NOLINK=1 PASS0ONLY=1 BUILD_PHASE= X86=1 failed - rc = 2 BUILD: Examining c:\work\ntosbe-master\src\sdktools\rcdll directory for files to compile. (2nd Pass) c:\work\ntosbe-master\src\sdktools\rcdll c:\work\ntosbe-master\src\sdktools\rcdll - 31 source files (18,137 lines) BUILD: Compiling c:\work\ntosbe-master\src\sdktools\rcdll directory 1>Precompiling - rc.h for X86 1>Compiling - rcdll.rc for X86 1>rcdll.rc(9) : error RC2135 : file not found: MSG00001.bin 1>NMAKE : U1077: 'rc' : return code '0x1' BUILD: NMAKE.EXE -c BUILDMSG=Stop. NTTEST= UMTEST= BUILD_PHASE= NOLINK=1 NOPASS0=1 X86=1 failed - rc = 2 BUILD: Compile errors: not linking c:\work\ntosbe-master\src\sdktools\rcdll directory BUILD: Done

3 files compiled - 4 Errors -   816 LPS

Build command failed for rcdll.

Error Build aborted.

[leecher1337]

Maybe some message compiler (mc.exe) still in your PATH that doesn't like Japanese characters?

You can test with: c:\work\ntobe-master\tools\x86\mstools\mc.exe c:\work\ntobe-master\src\sdktools\rcdll\rcmsgs.mc

For me, it generates message files correctly. If it doesn't for you or complain, maybe .mc file is damaged in your copy, otherwise maybe a broken/old mc has precedence.

[peter8777555]

I have remove my PATH and use Windows 7 X64 OS default path.

C:>c:\work\ntosbe-master\tools\x86\mstools\mc.exe c:\work\ntosbe-master\src\sdktools\rcdll\rcmsgs.mc MC: Compiling c:\work\ntosbe-master\src\sdktools\rcdll\rcmsgs.mc c:\work\ntosbe-master\src\sdktools\rcdll\rcmsgs.mc(43) : error : Unterminated message definition

[peter8777555]

I re-download NTOSBE-master.zip and verify the ZIP file.

I got the same error.

[leecher1337]

So either mc.exe or rcmsgs.mc maybe got devastated. As mc.exe gets built during mktools process, maybe the locally compiled version is flawed? To check this, please restore mc.exe from NTOSBE original repository and check with that copy again

https://github.com/stephanosio/NTOSBE/raw/master/tools/x86/mstools/mc.exe https://github.com/stephanosio/NTOSBE/raw/master/src/sdktools/rcdll/rcmsgs.mc

Or try mc on a fresh NTOSBE repository without running mktools.cmd before.

As a sidenote, rebuilding the local utilities via mktools is not absolutely necessary, it may also work with the tool versions supplied with NTOSBE, however, these lead to some random problems sometimes, that's why I recommended building the utilities locally in the build instructions.

[peter8777555]

I compare with HASH. Both of them is the same as NTOSBE-master.zip

[leecher1337]

So if tools\x86\mstools\mc.exe src\sdktools\rcdll\rcmsgs.mc

fails on a new, fresh checked-out NTOSBE, maybe the problem is related to your operating system version or locale? As it doesn't happen on my systems, I can only make wild guesses about the nature of the problem. Do you have a VM to compare? iirc you have a Windows XP VM for your old-src builds, maybe you can try if it fails in there too?

[peter8777555]

I see your YouTube video,you use Windows 10 to build.

Now, I try again and use Windows XP in VMWare. I got the same error.

So, Real PC : Windows 7 X64 VMWare: : Windows XP X86.

I got the same error.

1>Compiling message file - rcmsgs.mc for all platforms 1>rcmsgs.mc(43) : error : Unterminated message definition 1>NMAKE : U1077: 'mc' : return code '0x1' BUILD: NMAKE.EXE -c BUILDMSG=Stop. NTTEST= UMTEST= NOLINK=1 PASS0ONLY=1 BUILD_PH ASE= X86=1 failed - rc = 2 BUILD: Examining c:\work\ntosbe-master\src\sdktools\rcdll directory for files to compile. (2nd Pass) c:\work\ntosbe-master\src\sdktools\rcdll c:\work\ntosbe-master\src\sdktools\rcdll - 31 source files (18,137 lines) BUILD: Saving C:\work\NTOSBE-master\src\build.dat... BUILD: Compiling c:\work\ntosbe-master\src\sdktools\rcdll directory 1>Precompiling - rc.h for X86 1>Compiling - rcdll.rc for X86 1>rcdll.rc(9) : error RC2135 : file not found: MSG00001.bin 1>NMAKE : U1077: 'rc' : return code '0x1' BUILD: NMAKE.EXE -c BUILDMSG=Stop. NTTEST= UMTEST= BUILD_PHASE= NOLINK=1 NOPASS0 =1 X86=1 failed - rc = 2 BUILD: Compile errors: not linking c:\work\ntosbe-master\src\sdktools\rcdll dire ctory BUILD: Done

3 files compiled - 4 Errors -   408 LPS

Build command failed for rcdll.

[peter8777555]

By the way,

Document minnt.txt old-src.trunk.r687.20150728.7z or old-src-sr687.7z

You use old-src-sr687.7z I use old-src.trunk.r687.20150728.7z

Does this the question ?

[peter8777555]

1>rcmsgs.mc(43) : error : Unterminated message definition

I think file question. So i try to convert end of line 0xA to 0xD 0xA It works.

[leecher1337]

Interesting... I have file with just 0A line endinges in it and mc.exe still works fine. Basically I just

wget https://github.com/stephanosio/NTOSBE/raw/master/tools/x86/mstools/mc.exe wget https://github.com/stephanosio/NTOSBE/raw/master/src/sdktools/rcdll/rcmsgs.mc mc rcmsgs.mc

and it works here. I wonder why your target machines are picky about it... But anyway, 0D 0A line endings are a good idea on Windows systems.

Regarding old-src: Both archives are baiscally the same, the one with trunk in filename is a bit larger, because it contains all the .(unnecessary) svn subfolders. The patch utilities treat both filenames equally.

[peter8777555]

0xA C:>c:\work\ntosbe-master\tools\x86\mstools\mc.exe c:\work\ntosbe-master\src\sdktools\rcdll\rcmsgs.mc MC: Compiling c:\work\ntosbe-master\src\sdktools\rcdll\rcmsgs.mc c:\work\ntosbe-master\src\sdktools\rcdll\rcmsgs.mc(43) : error : Unterminated message definition

0xD 0xA C:>c:\work\ntosbe-master\tools\x86\mstools\mc.exe c:\work\ntosbe-master\src\sdktools\rcdll\rcmsgs.mc MC: Compiling c:\work\ntosbe-master\src\sdktools\rcdll\rcmsgs.mc

[stephanosio]

Make sure that the autocrlf setting is properly configured when using Git on Windows.

git config --global core.autocrlf true

[peter8777555]

6) Run NTOSBE-master\sizzle_minnt.cmd

I do NOT have sizzle_minnt.cmd I have sizzle.cmd ONLY.

[peter8777555]

and it works here. I wonder why your target machines are picky about it... But anyway, 0D 0A line endings are a good idea on Windows systems.

You use Windows 10.

I know,Notepad.exe support Unix file form Windows 10. Maybe this is the reason.

Chinese Web : https://kknews.cc/zh-tw/tech/lerrrrz.html

[leecher1337]

Maybe you refreshed NTOSBE in between.. The sizzle_minnt.cmd will be placed by the patch.cmd process of ntvdmpatch\minnt\patch.cmd

[peter8777555]

i find C:\work\ntvdmpatch\minnt\minntfix\NTOSBE-master\sizzle_minnt.cmd Can i use ?

[leecher1337]

You must ensure that ntvdmpatch\minnt\patch.cmd runs through properly before compiling buildtools, otherwise patches won't get applied to NTOSBE and you may get nasty suprises. When sizzle_minnt.cmd is not present, this is asign that the patch.cmd hasn't been completed yet.

Maybe you'd better start over again now that you know the problems and can fix them before?

[peter8777555]

Windows 7 X64 Build finish.

1. I get 3 versions Only ? C:\work\ntvdmpatch\releases br CHS CHT

2. When run mktools.cmd ....... press ANY key run again ........ press ANY key close CMD Console.

[peter8777555]

I test MinNT Version. But i do NOT like this version.

My CMD console in code page 950.

Old NTVDMX64 version: My old DOS exe can use code page 950.

MinNT Version: It ALWAYS use code page 437. Auto change 950 to 437 code page. CMD Consle 950 -> Run DOS.exe 437 -> CMD Console 437.

Oh my god,that is bad news for me. What is going on ? My build question ?

[leecher1337]

That's interesting, I wonder why all languages get built for me.. Actualle we are using the same sourcecode...?

Regarding the codepage problem: Is there a way I can reproduce this on my system? https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/chcp I don't see that 950 is a valid setting there. Also, chcp is a WIN32 program that gets executed to show the console settings. When I chcp 850 (valid codepage for my system and default here) and then run command.com and then enter chcp, cp850 is being kept. For verification, I think from what I can see, @emendelson updated his builds already in #7 Maybe you can try his builds and see if you get the same problems with the builds from there (you can test USA build and the build for your system language to check if there are differences). So we can check if this is a general problem with Minnt version or if it is related to the build process.

[peter8777555]

I test "emendelson CHT(950) build". It still ALWAYS use code page 437.

I test "command.com". It still ALWAYS use code page 437.

I test "HelloPas.exe". It still ALWAYS use code page 437.

HELLOPAS.zip

[peter8777555]

I test "emendelson USA build". It Works.

It is a strange question. Does USA(437) build use "now" code page ? Ex: I change to Chcp 950 and use chcp 950 to run DOS exe

Does CHT(950) build always use "437" code page ? Ex: I change to Chcp 950 and use chcp 437 to run DOS exe

So,the multi-language build for me is not good. I must use USA(437) build and works. if i use CHT(950) build and cry. :-D

[leecher1337]

Maybe this is related to the special contry.sys that gets copied on CHS, CHT, ... builds (see minnt\base\mvdm\bin86\cht\ directory)? As I don't have any Taiwanese or Chinese Windows version available, I cannot test this myself :( Can you try to use the CHT build with the USA build country.sys just for testing?

[peter8777555]

I try build again on Windows XP VMWare.

[leecher1337]

I had this weird keypress issue once, too. But if you press a key, it will actually NOT run again but continue with building the tools. Haven't found out, why it makes this "pause" call in the middle of the process and pretends that it has finished when it has not. But I only had this issue once.

[peter8777555]

So i should Close consle OR keypress to run again ?

[peter8777555]

My Real PC with path k:\dos Suggestion: Do NOT run NMAKE/LINK/..... from PATH var.

Suggestion: Use DOS text with 0xD 0xA line end for Windows OS.

[leecher1337]

So i should Close consle OR keypress to run again ?

Press a key. After 1 or 2 prompts for keypress, it should be at the end and then it closes the window on its own.

Alternatively, you can try to invoke buildlocaltoolsshell.cmd x86 and then on this shell cd src build

That should also compile the toolchain

[peter8777555]

Can you try to use the CHT build with the USA build country.sys just for testing?

I have test and NOT works.

[peter8777555]

I guess can NOT build due to with 0xA line end.

Maybe you try to build in Windows XP VM.

[peter8777555]

Alternatively, you can try to invoke buildlocaltoolsshell.cmd x86 and then on this shell cd src build That should also compile the toolchain

4>Linking Executable - sdktools\touch\objchk\x86\touch.exe for X86 3>Linking Executable - sdktools\m4\objchk\x86\m4.exe for X86 1>Linking Executable - sdktools\hsplit\objchk\x86\hsplit.exe for X86 2>Linking Executable - sdktools\hextract\objchk\x86\hextract.exe for X86 3>Linking Executable - sdktools\wcshdr\objchk\x86\wcshdr.exe for X86 BUILD: Done

510 files compiled - 9 Errors - 19552 LPS
25 libraries built
32 executables built
31 files binplaced

C:\work\NTOSBE-master\src>

[leecher1337]

I think we have triggered some really weird batch file processing bug here. In buildlocaltools.cmd, if I take the block

call :Build touch sdktools\touch bldtools\touch.exe idw\touch.exe if errorlevel 1 goto Error

and add REM xxxxx xx xxxxxxxxxx

underneath it, it doesn't build at all. I get an endless loop with Building and cleaning up then. Seems like the program counter of the batch file processor gets corrupted somehow simply be using this batch file...

[leecher1337]

Tried compiling on my Windows XP machine, with the latest 2 commits, build process went through smoothly. All languages were built.

[leecher1337]

Can you try to use the CHT build with the USA build country.sys just for testing?

I have test and NOT works.

I checked with Taiwanese Windows 2000, it seems that it behaves exactly the way that you described. So I guess, you have to stick with USA version:

[peter8777555]

I checked with Taiwanese Windows 2000, it seems that it behaves exactly the way that you described. So I guess, you have to stick with USA version:

Thank you.

[peter8777555]

Tried compiling on my Windows XP machine, with the latest 2 commits, build process went through smoothly. All languages were built.

I try on Windows 7 X64,it still FAILED.

I will try Windows XP VMWARE.

[leecher1337]

If you still have this masm386 error, maybe you can check in minnt\base\buildchk.log which file it fails to compile. Maybe there are CRLF issues on other files that only appear on your Windows Version or something like that...? I suspect so, because 0A line endings didn't hurt my mc.exe, but they definitely hurt your mc.exe, so maybe it has to do with the language version of the Windows machine used for compiling...?

[peter8777555]

Does MinNT-20170416-85fac4faadc77203db8ddc66af280a75c1b717b0.zip need to rename q160765803-minint4-85fac4faadc7.zip ?

[leecher1337]

No, filename of minnt repository zip doesn't matter, because you need to unpack its contents to work directory anyway, so it's not used or touched by preparation/patch script. I hope the buildchk.log will shed some light on the build problems.

[peter8777555]

I try Windows XP VMWARE,it still FAILED.

I guess can NOT build due to with 0xA line end.

Yes,i guess is correct. Many many Error:Unexpected end of line Windows XP/7 is the same as error.

I use Windows XP/7 CHT edtion.

ErrorWinXP.zip

ErrorWin7.zip

[peter8777555]

Oh,my god.

Do i need to try in English edtion ?

[leecher1337]

The .zip file you can download from github seems to keep 0A line endings. stephanos above posted a setting how to fetch package with converted line endings via git, maybe that's the simplest solution to get a working repository?

[peter8777555]

stephanosio > git config --global core.autocrlf true

How to ?

I do NOT know.

git is EXE ?

[peter8777555]

By the way, You can build in Windows XP/10. This project can NOT build in Two-Bytes Windows OS ? Ex: CHT/CHS/JPN/KOR Asia Edtion.