yuhong

Mozilla have https://bugzilla.mozilla.org/show_bug.cgi?id=1197768

https://docs.microsoft.com/en-us/windows/deployment/upgrade/upgrade-readiness-deployment-script ConfigScript.ps1 is pretty interesting. Of note is there are different versions of DiagTrack: https://github.com/MicrosoftDocs/windows-itpro-docs/issues/3347 There is a blog post on it: https://techcommunity.microsoft.com/t5/Windows-Analytics-Blog/How-does-Upgrade-Readiness-in-WA-collects-application-inventory/ba-p/213586 I wonder how many users there are of this stuff.

Yes, the current MSO.DLL still has the problem.

Yes, this is what I mean by it coming from __ftol2_sse. (hint: disassemble the routine with a debugger like WinDbg)

Yea, be careful of false positives here. For example, the cvttsd2si instruction most likely comes from __ftol2_sse.

And worth mentioning that you can see the SSE2 instructions clearly if you disassemble the DLLs, which are the same for most if not all versions of Windows.

Can confirm that all of the Jet 4.0 ones since late 2017 (Note: not just the POSReady 2009 ones) require SSE2. This will show if you run something like Access 2003 that uses Jet 4.0.

Except there is still Server 2003. Anyone able to repro this bug on Server 2003 BTW? I suspect that the same bug is there but want to confirm.

I noticed this bug (which only repros with full screen sessions) and provided repro steps to secure@microsoft.com at the end of last year (OptIn also don't repro this bug). MS hasn't released a new version of ntoskrnl for XP (or Server 2003 for that matter) since then sadly.

Are you sure that there are IE6 patches for POSReady? It comes preloaded with ie7. (Never tried to revert back to ie6 since I hate it) There is also the older WEPOS/XPe which comes with IE6 and is supported until I think 2016 and also uses the same patches.

From http://techreport.com/forums/viewtopic.php?f=36&t=63600: "I used vlite to slipstream the hotfixes (there were two, one ~2 MB, another ~ 300KB) that Scott had said Microsoft recommended into a standard Vista x64 SP1 Home Premium install. I still ended up with a 0x0000005d stop code as the installer launched. I'm wondering if that hotfix does what we think it does, or if maybe vlite doesn't do what we think it does." I think what is happening here is that you see, there are two WIM images that is used in Vista Setup. One being the main Vista WIM, another being the WinPE 2.0 image used to boot the Vista DVD. In other for Vista 64 to be installed properly on a VIA Nano processor, the hotfixes has to be integrated onto both WIMs. vLite (and Vista Hotfix Installer) is probably only integrating the hotfix onto one of the WIMs. BTW, it would be nice if VIA provided an option to fake CPUID vendor ID to be "GenuineIntel". It would help a lot here.