Atari800XL

Hi JFX, how are you doing!? Have you heard about the new (?) Microsoft Validation OS? Overview Microsoft Validation OS is a lightweight, fast, and customizable Windows 11-based operating system that you can use on the factory floor to diagnose, mitigate and repair hardware defects during Windows device manufacturing. Validation OS boots into a Command Line environment to increase reliability on the factory floor and supports running Win32 apps, smoothing the transition from early hardware bring-up to retail OS and apps development. https://software-static.download.prss.microsoft.com/dbazure/888969d5-f34g-4e03-ac9d-1f9786c66749/22621.1.220506-1250.ni_release_amd64fre_en-us_VALIDATIONOS.iso What is your opinion on this? For example, what the heck is it anyway? :-) A bit more info can be found on a different forum: https://forums.mydigitallife.net/threads/discussion-microsoft-validation-os.85484/

Thank you for your reply, Alacran. I understand the points you made, but to me it would still be useful if Grub4UEFI could support my scenario on GPT, similar to the way I use Grub4DOS on MBR now (and have done for years). I like to have a few Windows operating systems on seperate (indepentant/ hidden) partitions. For example: one for "work", one for dev, one for testing, etc. I also liked the Grub4Dos/ GFXCustomizer boot menus (as I've mentioned before). I would also like to reverse the question: "Why would Grub4UEFI -not- support it?". When the different OS's are independent and invisible from each other, it's easier to make OS image backups (Terabyte, etc.). Thanks again for your reply, I know you're more interested in the VHD approach, but I hope that if you ever find some hints to my desired solutions, you will share it with us in this or other topics, as I'm sure you will. I hope you're having fun booting!

Alacran, If you have any idea for me to test HD multibooting (eg. several Windows 10 installs on separate partitions) on a GPT disk, please let me know. I have a spare laptop for testing. I really only tested Terabyte BootItUEFI on GPT once (didn't really like complicated setup), but from this test I learned that I only need one FAT32 EFI system partition, then as many NTFS partitions as I wanted for multibooting. If you find any menu.lst entries for that anywhere (on this or the other forums), I would be happy to test.

Alacran, thank you for starting this topic on MSFN. This might be a dumb question, but I'll ask it anyways, maybe others wonder about this as well: - Is it possible do do "hd multibooting" with Grub4UEFI? Like it is with Grub4Dos on MBR/BIOS systems? Or have you read anything about this being developed for future versions? I can't wrap my head around this at the moment, but maybe something similar to Terabyte's BootItUEFI, or as I said, the "old" Grub4Dos? I guess this would involve hiding some partitions, etc.? Thanks for your reply.

Thanks for this great update. Thanks also for your tips about the DPI settings, they worked like a charm. I will also mention this update to some buddies, if you don't mind...

Hey, that was pretty quick :-) Thanks, I will try it for the PE as well, but my question was more about the best way for the "Main OS" that we apply from PE (using WinNTSetup or other). So the four settings you mention should be enough. Thanks again, I will try them... > Maybe for version 5 (in a few years) ... Maybe a separate option for scaling in version 5 as well :-)

Hi JFX, just a quick question, if I may... What would be the best. quickest/ easiest way to get the display settings to (say) 175%? (we're talking about the apply stage, obviously). Can this even be done with simple registry stuff? Thanks...

Thanks for looking into this!!! Yes, it normally works all the time with the older ImageX version (have used it dozens of times). Must be some other weird thing, but it's so strange that 15063 NEVER has those issues. Oh well, not really WinNTSetup's fault, but as you're active in other fields relating to PE/ Deployment as well, it's always best to ask the master directly. (Abbodi1406 told me he doesn't use PE all that much, I've always wondered about that, we could use him around <g> but that's another topic again).

Just finished a test of direct apply of UUP files (build 18980 x64). WinNTSetup 4.0b6 performs this task with no problems (using WimgAPI 18362). (Actually, I always wonder why a lot of people bother to convert preview UUPs to an ISO, all this effort can be spared, just use direct apply, either with WinNTSetup of Imagex). I wanted to test the manual method as well (using imagex.exe from the command line, or actually from a gui/ script thingy), and to my surprise this still produces the errors below. So for manual use, I still use version 15063. Any idea why this would happen? Command line: imagex /apply pro.esd /ref: g:\uup ImageX (any version after 15063) produces errors like this: [ ERROR ] Restoring ....filename.... again {Error = 6) Error restoring image. The handle is invalid. Once again: WinNTSetup is not to blame, just wondering what's going on here...

Thank you very much, I didn't know about the fixed uup apply, I will test imagex 18362 on its own as well. Very nice to see all the recent additions to WinNTSetup!

Most excellent to see all you veterans here again lately! Yes, I agree using wimgapi for apply and wimlib for capture. I often use UUP direct apply (for insider previews), for this I use (from the PE command line) an older version of Imagex (15063, I believe). Later versions could never apply UUP files without errors, we discussed that before, but that part of the thread seems to be gone. ...or WinNTSetup, of course. JFX, I notice that after downloading the DISM files, for x86 it has wimgapi version 15063, but for x64 it is version 18362. What is the reason for that? Does the 18362 version not have the problems anymore?

I think Misty is just interested in testing stuff... I guess he likes Wimlib so much for his PE builder, that he also wonders what the most efficient way for adding packages would be, and if it could be done without using mounting/ unmounting. For me personally, mounting is not so bad, as long as I can remember not to open any explorer windows to check what's going on during unmounting :-)

I recently wondered the same... :-) (it's a small world) I know you don't like the "buggy as hell" 16299, JFX uses wimagapi from 15063 in his great WinNTSetup (I use imagex.exe from that version as well for UUP direct apply). See here: https://1drv.ms/u/s!AnNmc1rU9VMAhGfaGtiigOc0BUlV

I replaced the new (faulty) ntfs.sys on my january iso (XPSP3 + OnePiece XP final + OnePiece POS january) with the one from my december iso (5.1.2600.5782, from the XP final pack, I guess). No write errors anymore. Still, not the "clean" solution I would have liked, but just to confirm (tested on single, dual and quad core, again, for testing/ confirming).

Misty, to detect running on PEBakery, here's a quote from Joveler (taken from an older release): %EngineVersion% for integer version (Ex 090), %PEBakeryVersion% for string version (Ex 0.9.0 alpha) was added. In current version, it is recommend to use %EngineVersion% to detect PEBakery.

The FileBox root path fix makes the SE "Copy to USB device" script work, very nice! I also like the autoscroll in the ShellExecute output, and the line numbers in the log! A nice Christmax gift, looks like your original plan of having a "working version" by December (this is close enough to beta for me!) worked out... Thank you!

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.