Atari800XL

Thanks, that did the trick! Still very strange that the error didn't play up for me until now, sorry again for not remembering your errors (but it must have been in the back of my mind, that's why I came straight back to "the master" to ask! <g>) Thanks for the link to the previous versions, will save it!

Sorry JFX, I see you reported the exact same errors in your November 13 post...

Thank you for your reply. I'm using the version from the WinNTSetup tools folder (downloaded by WinNTSetup). It is indeed the 16299 version. I will try to find the 15063 version, can't remember now how to get it :-) (Will try). So you say 16299 has a bug, which bug is that? I find it strange that the previous previews applied fine, but not this one. Does it sound to be related to the bug you found? PS: Would the 15063 version have the same UUP file apply capabilities (will test if/when I find it).

JFX, as you're the biggest imagex (and wimgapi) experts I know, I wonder if you could shed any light on this: - I downloaded the new 17063 preview UUP files yesterday, installing them with WinNTSetup worked just fine (that's unconverted UUP files, so .esd and .cab, 33 files). To repeat my imagex speed comparison test, I also tried to apply using imagex: Q:\WinNTSetup\Tools\x86\DISM\imagex.exe /apply g:\Professional_nl-nl.esd 3 c: /ref g:\*.* This worked fine with the previous preview, so I already included in some test batches. With the latest preview however, I get this error: [ 8% ] Applying progress: 10:46 mins remaining [ RETRY ] Restoring c:\Windows\InfusedApps\Frameworks\Microsoft.NET.Native.Frame work.1.6_1.6.24903.0_x86__8wekyb3d8bbwe\AppxMetadata\CodeIntegrity.cat again (Er ror = 1784) [ ERROR ] c:\Windows\InfusedApps\Frameworks\Microsoft.NET.Native.Framework.1.6_1 .6.24903.0_x86__8wekyb3d8bbwe\AppxMetadata\CodeIntegrity.cat (Error = 1784) Error restoring image. The supplied user buffer is not valid for the requested operation. Do you have any idea what's going on here, why would imagex fail where wimgapi works? I

The [HELP.7] section seems to have extra double quote inside the line (col. 467, "INJECT"). Removing these seems to fix the problem (the correct way is replacing them with #$q I guess...) Just another case of PEBakery's stricter double quote rules...

Alacran, I tried MistyPE with a modified Core\syswow64.script file, all the lines now have the "01" at the end of the line, instead of "\" on the end, and the "01" at the beginning of the following line. I don't really understand why these lines were concatenated in the first place, those two extra character could easily fit on the same line. But that's not the point, breaking up lines like this is used in other scripts, like 7pese wallpaper, and the script mentioned by Paraglider. We'll have to wait what Joveler thinks... With the breaks removed, the WOW64 script now works! (Not on 16299 though, we need Dave's input for that). Try an older x64 w10 release for now... You also mentioned you wanted to remove the UAC warning. This can be set in the main options, tab3 ("Options 3"), item 1 ("UAC check").

Of course, it was never Joveler's intention to support *all* the (weird?) WB commands, first task was to make it compatible with Win10PESE, after that he wants to focus more on "new" stuff. But I'm sure he is willing to look at some of these issues, like the line continuation (which was also the problem in Para's second example, I guess). Where did you take these code samples from, Paraglider?

Alacran, thanks for your tests. As it turns out, I tested MistyPE without WOW64 enabled. I have now looked at the WOW64 script in MistyPE, and it looks like it's using a line continuation for long lines (lines end with "\" in that case, and code is continued on the next line, but has to be combined by the interpreter). It looks like PEBakery doesn't support this (yet?). It isn't used in many scripts, so he may not have run into it. As luck would have it, I've done a lot of tests today as well, including w7pese, this project also uses this line continuation in a script (Wallpaper). I hope Joveler can look into this. I know he doesn't want to support each and every WB function, but maybe he can make an exception in this case, so we can get this working after all. Sorry for forgetting to test WOW64 in MistyPE myself, good thing you found it!

For Misty's create.iso.script, I believe line 125 should be deleted. In that case the "else" starts working, and only *one* of the two iso creation tools is used, instead of both (the second will overwrite the first anyway). Please correct me if I'm wrong.

Nice to meet you :-)

Abbodi1406, nice to see you around... Let's not get into the image.exe timings anymore. I think the point is clear: Imagex.exe was almost "forgotten", but as Abbodi1406 found out, it can be useful for direct apply of UUP files, and fast as well, for some people (with old hardware/ disks?) even faster than the mighty WinNTSetup. If people are concerned with/ interested in this time difference, I'm sure they will try it themselves. That's it.

Sorry, forgot about that. Log file says "Operation took: 7:47 min)".

Last message about the difference between WinNTSetup apply and "manual" Imagex,exe 10.0.16299.15 (using unmodified/ unconverted UUP files). I have repeated all the tests, using PE versions from Windows 7 (3.1) upward. Tests were done on a spare laptop (Pentium dual core TT2370, 3gb, apply from external 2.0 usb hd to internal hd). Reboot between tests (no disk cache effect). For WinNTSetup (3.8.8.2b1), the timer is stopped as soon as the apply stage is done (when it starts applying tweaks). Pretty much all tests show WinNTSetup takes 7:00 minutes, manual apply with Imagex.exe takes 4:55 to 5:00 minutes. I'm not coplaining about WinNTSetup at all (will still use it), I just wonder where this time difference is coming from. And of course, I wonder why Microsoft is "hiding" this fast UUP-functionality in Imagex.exe ...

OK, thanks, I was wondering about verify and temp folder. Yes, I measured by old-fashioned manual timer :-) But I don't want to go too much off-topic, just wanted to share the remarkable difference.

Repeated the test, with a reset inbetween. Still 5 minutes for imagex, 7 minutes for WinNTSetup. Does it have something to do where you set the temp/ extract folder, or maybe verify on/off? (Just blurting out something, as I said, the first time I tried imagex I thought maybe it skipped files, but it doesn't seem to be that way).

I'm still testing as well, my first test was with imagex.exe from the dism folder (using your GetWAIKTools) in PE. This was version 16299, x86, and gave no errors. But it looked to finish too quickly, so I thought something must have gone wrong. I cleared the partition again (didn't run the install), then ran WinNTSetup, to time how long that took. WinNTSetup did the apply in around 7 minutes. After that I checked the size of C:, around 5.6gb was applied. So I tested imagex.exe again, it finished in 5 minutes, also with 5.6gb applied. Huh? How can it be so much faster?! The install seems to have gone OK while I'm typing this, so lots of interesting stuff to test and analyze...

Did you know that the latest imagex.exe does support multiple "ref" parameters? (I sure didn't). It also supports "*.*": imagex /apply Education_en-us.esd 3 Z: /ref *.esd /ref *.cab imagex /apply Education_en-us.esd 3 Z: /ref *.* Abbodi1406 found out: https://forums.mydigitallife.net/threads/windows-10-imaging-customization-and-deployment.59187/page-28#post-1388789

Thanks. Just to be clear: when you manually apply with DISM (instead of WinNTSetup using Wimgapi), cab-to-esd is also necessary, isn't it? BTW, just finished the 3.8.8.2b1 test, using the new 17035 UUP files, everything working OK! (Not that the new 17035 preview is all that interesting, but that's a different story...)

Sounds good, JFX! Will test ASAP... How did you get this working without converting the cabs? Are you converting "on the fly" in some way?

(in a Burns voice): "Excellent!!!" Thanks JFX, just tested and this works for me. I'm sure others might find this too radical (maybe we'll find another way to disable the Edge page displaying), but to me, this will surely do for now! Of course, we can always enable Edge again after setup (during "PostInstall"). Normally, I would run setup on offline systems, but for Pro versions with a Digital License, it's better to have Internet access during setup, I have found this will get the system activated faster. Thanks again for your great support!

If anybody knows a reg setting to get rid of the new (unwanted) Microsoft Edge page popping up after a clean install of 16299 (when online), I would really like to know it. I like my setups to be completely silent, Microsoft seems to come up with new stuff all the time. I have been looking with regshot, etc. but can't find anything... The only thing I can offer in return is this, to get rid of the stupid "people" icon in the tray: Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\People] "Peopleband"=dword:00000000

ADK: https://download.microsoft.com/download/3/1/E/31EC1AAF-3501-4BB4-B61C-8BD8A07B4E8A/16299.15.170928-1534.rs3_release_amd64fre_ADK.iso

With Windows 10 Version 1709 Fall Creators Update, build 16299.15 now being RTM, are you planning on making WinNTSetup 3.8.8 "RTM" now, as well? Or does the MS release have nothing to do with your release schedule :-) Either way is fine by me, the beta3 is working just great in my (UUP) tests [thanks again for the UUP support], ESD was released today (they even call it RTM, after saying they wouldn't use that term anymore). (Insider) ISOs and ADK will probably be available next week.

Some might find the tweak useful, it suppresses the "new network found" on clean setup: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Network\NewNetworkWindowOff] Note that this is just an empty key, there are no values "inside" it.

Thanks for "hanging in there" with me, JFX, it gave me the push to investigate further. Now I have to admit it turned out to be my own fault after all. I apologize for bothering you, it turned out one of the reg tweaks was -not- the same as the ones I successfully tested before (you can guess what the problem was, I'm sure, but I'm too ashamed to admit). Once again sorry for this, and thanks again for helping to narrow it down. Result for now is: WinNTSetup fully supports UUP, so one of these days the "rtm" will become available on the Microsoft updates servers, downloading the files is super easy with MKuba's UUP dump, so anyone can download this "shiny" (turd) OS as soon as it is released to Insiders, and apply it in a heartbeat with WinNTSetup! No need for converting to wim or iso (at least not for testing, same goes for upcoming rs4 previews, of course). Cool stuff...