Longhorn 4017.main

[yourepicfailure]

Recently I noticed 4017.main was silently placed on FTP. This is likely in accordance with mrpijey's plan to slowly release each build. I wholeheartedly respect that decision.

Anyways, I decided to give it a try. Upon initial inspection, the ISO is bootable. However attempting to start setup from the disc image AS-IS in VMWare 7.5 yields this:


At first, believing it was a VM quirk, I proceeded to burn the image to a CD and run it on period-correct hardware: the Dell Latitude D600. However, same issue.


In either environment I left it as-is for over an hour, but no change happened.
I decided to see if there was anything clues in task manager. Any activity? Any other programs running? Any error windows?
Well, no program can run when commanded from cmd.


These indicate some form of PE corruption. Believing this to be a similar case with 4020, I proceeded to transplant 4017's sources folder into the 4015 PE image available on the FTP.
Setup started right up.


For the remainder, I used VMWare 7.5. Pretty much all the settings were default for Windows Vista, except I used IDE drive instead of SCSI. BIOS date was set to January 24, 2003 because I didn't really have a "set in stone" proper BIOS date to use.
For the product key, I used 4015's key. Pretty much setup was no different from 4015. At the end I received this:


It's not like later builds wrote a correct boot.ini either.
Nonetheless after ok'ing the window it restarted and the imaged system booted up with oobe starting as expected.


Of course OOBE eventually sat still with no CD or disk activity so after about 10 minutes of inactivity I killed OOBE and simply moved on. I was presented with the desktop.


On the surface, there isn't too much different from 4015.main. It is a bit more on the stable side.

There does exist DCE, however it is identical to 4015.main. There are no fancy animations it seems.


Maybe this build has some other hidden features? I don't know for sure. Possibly someone with enough time to do some exploring can find something.

And again, a round of thanks to grabberslasher for his willingness to share his collection to the community.

EDIT: Slashed out the "silently" as it was logged to the FTP database.

[sugarcubes]

woah, nice find!

[grabberslasher]

Anyways, I decided to give it a try. Upon initial inspection, the ISO is bootable. However attempting to start setup from the disc image AS-IS in VMWare 7.5 yields this:

…fortunately, you read the readme txt that came alongside the release, which alerted you to the fact that it requires an upgrade-install, and booting from the disc won't work

But yes, there are quite a few builds that just can't be installed from their own boot.wim; the install process was as prone to breaking as every other feature in Longhorn. With a lot of the later Longhorn build leaks, it was common practice to swap out the boot.wim on install CDs with a working build just to get through the install process. BA prefers having the install media to be as close as possible to the original, but it would be easy enough to repackage ISOs with working installers for yourself. For the old OSBA releases I generally erred on the side of making it as easy to boot and install as possible, at the expense of pristine filesystem layouts on disc — which I'm sure has driven some people crazy over the past decade.

[yourepicfailure]

Oops, didn't read the readme. Would've saved me some time and I probably would've just skipped straight to transplanting.
My mistake.

Nonetheless, it is interesting though. I'm about to contact you about 4029.lab06.

[perry]

which builds do you need to upgrade-install this build from?
i'd assume 4011 and 4015

[Applegame12345]

which builds do you need to upgrade-install this build from?
i'd assume 4011 and 4015

Everything after 4000

[perry]

which builds do you need to upgrade-install this build from?
i'd assume 4011 and 4015

Everything after 4000

ah,makes sense.

[grabberslasher]

which builds do you need to upgrade-install this build from?
i'd assume 4011 and 4015

XP should work too. I went from Windows FLP in my VM.

[perry]

which builds do you need to upgrade-install this build from?
i'd assume 4011 and 4015

XP should work too. I went from Windows FLP in my VM.

yeah your right,i heard from someone in the Discord server that they upgraded from XP.

[yourepicfailure]

I tend to stay away from upgrading. I typically run these builds on actual hardware and there has been no doubt issues that arise from upgrading.

The closest I come to upgrading is a clean install on a separate partition, setup started from an already installed Windows.

[YourAverageJoe]

These indicate some form of PE corruption. Believing this to be a similar case with 4020...

Woah, gotta stop you right there. The PE isn't 'corrupted' per se, more than there was a problem with the way it was downloaded that ruined the original names of everything within the WinSXS folder that the PE is dependent on due to their general length. This was why I was a little weary on the whole

we got unnamed 'experts' behind the scenes repairing these images

as I knew this was something they would overlook, as was with 4020. You would think, with the patch for 4015 by WiNBETA and the more modified patch by ReflectiaX (http://dk.toastednet.org/iex_lh/) which were the earliest examples of this problem being found out and solved, that this would be the first thing thought of for the recently-leaked builds. Especially seeing how 4020 was leaked BY ReflectiaX (https://betawiki.net/wiki/Windows_Longhorn_build_4020). I will post the repair instructions on my this thread when I get the chance to, as I've already have for 4020: https://www.betaarchive.com/forum/viewt ... 62&t=39119

[grabberslasher]

These indicate some form of PE corruption. Believing this to be a similar case with 4020...

Woah, gotta stop you right there. The PE isn't 'corrupted' per se, more than there was a problem with the way it was downloaded that ruined the original names of everything within the WinSXS folder that the PE is dependent on due to their general length. This was why I was a little hesitant on the whole

we got unnamed 'experts' behind the scenes repairing these images

as I knew this was something they would overlook, as was with 4020. You would think, with the patch for 4015 by WiNBETA and the more modified patch by ReflectiaX (http://dk.toastednet.org/iex_lh/) which were the earliest examples of this problem being found out and solved, that this would be the first thing thought of for the recently-leaked builds. Especially seeing how 4020 was leaked BY ReflectiaX (https://betawiki.net/wiki/Windows_Longhorn_build_4020). I will post the repair instructions on my this thread when I get the chance to, as I've already have for 4020: https://www.betaarchive.com/forum/viewt ... 62&t=39119

I was curious, so I went back and had a look at the master ISOs for a couple builds with this in mind; from what I can tell, the filenames were truncated by whomever originally archived these at Microsoft and leaked them, as the naming issues are there in the very earliest masters I've got (from which I went on to build bootable ISOs).

On the plus side, I don't have to feel guilty that I might have built the images incorrectly myself. On the other hand, that explains why the builds don't install when booted directly — the original ISOs weren't mastered with long filename support.

[YourAverageJoe]

I was curious, so I went back and had a look at the master ISOs for a couple builds with this in mind; from what I can tell, the filenames were truncated by whomever originally archived these at Microsoft and leaked them, as the naming issues are there in the very earliest masters I've got (from which I went on to build bootable ISOs).

On the plus side, I don't have to feel guilty that I might have built the images incorrectly myself. On the other hand, that explains why the builds don't install when booted directly — the original ISOs weren't mastered with long filename support.

And I wouldn't feel guilty either if I were you. It didn't, and still doesn't, matter to me how the ISOs were being rebuilt constructively as to match it up with how Microsoft would make their discs, but how they were being handled with in regards of being bootable. I just didn't want something with 4093 where someone wasted their time replacing the entire PE just for something so simple. There are cases where the PE outright doesn't work correctly (as with 4011 after renaming, and seemingly 4039) but your builds don't seem to be like those. Or at least what I have access to (4017 and 4029). If you want to find the original names for everything in Boot\WinSxS while you guys are rebuilding the ISOs, here is what you can do:
1) Go to sources\install.wim and open with 7-zip. Then go to 0\WinSxS and everything you need should be there
2) This is for if you cannot open install.wim as with some builds. You launch a virtual machine with Windows XP and go through the setup accordingly within the operating system. When it gets to restarting, quickly go to the root folder and the $WIN_NT$.~BT folder it creates to your host computer if you got guest tools, or shut down the virtual machine and open the VHD with 7-zip or WinImage, depending on what you choose to use.
When you have access to the correct WinSxS folder, you can either quickly replace the files from there to the ISO (keeping in mind the dates), or compare the contents of the folder (when dealing with the root WinSxS folder) and/or the size (when dealing with the manifests folder) and rename.

[grabberslasher]

I was curious, so I went back and had a look at the master ISOs for a couple builds with this in mind; from what I can tell, the filenames were truncated by whomever originally archived these at Microsoft and leaked them, as the naming issues are there in the very earliest masters I've got (from which I went on to build bootable ISOs).

On the plus side, I don't have to feel guilty that I might have built the images incorrectly myself. On the other hand, that explains why the builds don't install when booted directly — the original ISOs weren't mastered with long filename support.

And I wouldn't feel guilty either if I were you. It didn't, and still doesn't, matter to me how the ISOs were being rebuilt constructively as to match it up with how Microsoft would make their discs, but how they were being handled with in regards of being bootable. I just didn't want something with 4093 where someone wasted their time replacing the entire PE just for something so simple. There are cases where the PE outright doesn't work correctly (as with 4011 after renaming, and seemingly 4039) but your builds don't seem to be like those. Or at least what I have access to (4017 and 4029). If you want to find the original names for everything in Boot\WinSxS while you guys are rebuilding the ISOs, here is what you can do:
1) Go to sources\install.wim and open with 7-zip. Then go to 0\WinSxS and everything you need should be there
2) This is for if you cannot open install.wim as with some builds. You launch a virtual machine with Windows XP and go through the setup accordingly within the operating system. When it gets to restarting, quickly go to the root folder and copy whatever folder it created to your computer if you got guest tools (named something like $~WIN_BT$), or shut down the virtual machine and open the VHD with 7-zip or WinImage, depending on what you choose to use.
When you have access to the correct WinSxS folder, you can either quickly replace the files from there to the ISO (keeping in mind the dates), or compare the contents of the folder (when dealing with the root WinSxS folder) and/or the size (when dealing with the manifests folder) and rename.

I'm pretty sure the 'someone' for 4093 was me

If the install.wim contains the boot wim at index 0, presumably one could re-create the bootable ISO in full with that too?

[YourAverageJoe]

I'm pretty sure the 'someone' for 4093 was me

If the install.wim contains the boot wim at index 0, presumably one could re-create the bootable ISO in full with that too?

Oh, never was aware. Well, now I know :3
Anyways, you can create a bootable PE image with the contents, yes. But it'll just be that, a bootable PE image. There is no point to use anymore from there than the WinSxS folder if that isn't your intent, unless like with 4020, filenames with periods are missing those periods which'll affect BOOT\MUI\FALLBACK\0409 as well which is separate from WinSxS, and that's like a little over a hundred files. So it all revolves around two questions; what is the extent of the damage, and what do you think is the best way to repair it while being as original with it as you can? Some WinSxS folders can contain more than needed when extracted from the install.wim, which is why I perfer renaming when possible. Although using the WinSxS folder from install.wim is okay, again just be mindful of the dates.

[yourepicfailure]

Woah, gotta stop you right there. The PE isn't 'corrupted' per se, more than there was a problem with the way it was downloaded that ruined the original names of everything within the WinSXS folder that the PE is dependent on due to their general length.

I also have to stop you there. I stated some form[\b] of corruption. In this case the corruption, is as you said, in the file names. They were corrupted, or made unreliable by change and unreliable, by the truncation.

Nonetheless there are alternatives for direct boot installs but result in non-original images.

[YourAverageJoe]

I also have to stop you there. I stated some form[\b] of corruption. In this case the corruption, is as you said, in the file names. They were corrupted, or made unreliable by change and unreliable, by the truncation.

It isn't really, corruption implies there is something severely wrong with the image, in which there isn't. This is like saying that files taken from an old FAT hard disk are all corrupted because of the way names are shortened down to 8 characters. And as such, old recovery disks such as those from Hewlett Packard, recover the system through ZIP's that suffer from the same thing. It's by your definition, corrupt by design. There is however, an autoexec.bat that is executed upon startup that fixes the names. If someone were to make a patch similar to the one's we seen with 4015 that fixes the names, is it really still corruption?

[yourepicfailure]

Anyways, not to stray too far into an argument about language, 4017's PE possibly just needs the renaming to get it to function.

[leomoskva]

I'm not so good at this, but - maybe, all that exclusive things from other labs were blocked by their WinPE realisation? When Microsoft was going from I386 to WimBoot?