My Issues with a fresh compile

[Danfun64]

I managed to set up the oldnt src and sdk, "SUBST W: ." and get Patch.cmd working, but when I run zSHtst.cmd (which calls sizzletst.cmd; then ntenv.cmd; then finally, and most importantly, ntuser.cmd) it uses an "alias" command, which the command prompt doesn't see as valid. Thusly, attempting to use bld-ntos.cmd , I get "You must set up the Razzle build environment prior to executing this command.
Supported build configurations: *fre, *tst, *chk"

I can see that it's not going to work without Alias working.

http://paste.debian.net/hidden/b2557f78/

[leecher1337]

Hi,
Quoting readme.txt from old-src.trunk.r687.20150728.7z

Copy alias.exe in tools(HOSTARCH)\idw directory to your local system32 directory.

e.g. If your host machine is x86, copy tools\i386\idw\alias.exe to %SystemRoot%\system32.

[Danfun64]

Well, after copying that file to system32 (I would have thought it was supposed to have bone in SysWOW64...but eh...) I get this: http://paste.debian.net/hidden/3620a658/

ALIAS: Unable to open file - W:\nt\private\developr\Danfu\cue.pri

[leecher1337]

After looking at the script output, it seems that you are not compiling under Windows XP x86.
The build process has only been tested on Windows XP so far.
The problem is that your architecture is AMD64 and there is no case for this ar chitecture in the Microsoft build scripts (didn't even exist back in NT4 days).
So for me the line

if "x86" == "x86" set USERNAME=x86tst

evaluates nicely, because I'm on x86 Windows XP and therefore have another control flow.
So better try to compile it on an x86 machine or you may need to modifiy the build scripts according to your needs.
If you just want to try it out in compiled form, see #7

[Danfun64]

Thanks for the link...but I prefer fresh binaries from the latest commits.

Should I close this issue, or leave it open for potential amd64 porting?

[leecher1337]

It seems emendelson normally is pretty fast with updating the build. My latest commits are important mainly if you want to debug NTVDM (which is i.e. important to find out if there maybe is a way to get WOW working, but most of the 16bit scheduling currently is done in the kernel, so this may get complicated as NTVDM on x64 is already a WOW32 process and Win 10 x64 is even missing the WOW16 functions in its scheduler, Win 7 x64 still has the functions at least).

You can leave the issue open as a reference.

[Danfun64]

Heh, I started over with a 32-bit Windows XP VM, and it actually did something. However, several programs failed to compile when doing bld-ntos.cmd . I plan on starting over so that I could log everything in its entirety.

[Danfun64]

I'm having trouble finding a way to get the batch and cmd files to log everything. All I can say is that ntvdm.exe does not compile, and I've gotten errors at various places

[leecher1337]

Hi,
My apologies, I forgot to add a few lines of code to the patches leading to a "getenv" not resolved error, but I now fixed this.
I verified build process and it worked flawlessly. I made a video recording from it which I can provide if it helps.

[leecher1337]

.Here are videos showing the actual build process: https://www.youtube.com/channel/UCYytaSnVu4Q3V5ykgJLqIFw

[sumitparihar93]

leecher1337 sir can you provide me compiled version of ntvdmx64 on mail.

[emendelson]

sumitparihar93 see the download page linked from #7