Jump to content

POSReady 2009 updates ported to Windows XP SP3 ENU


glnz

Recommended Posts


5 minutes ago, Dave-H said:

They did.
The last version I have is from August 2016, version 5.39.12900.0.
You can come out now!
:lol:

One question that was bothering me.Can i install Posready Net framework updates? i had to hide them because they taked a long time to install so thats why i unchecked them and hidded them just to save some time..

Link to comment
Share on other sites

35 minutes ago, Dave-H said:

Yes, they do take a very long time to install, especially the updates for .NET 4.
I've never had a problem installing them though.
:)

Oh,ok thanks for the info! 

:yes:

Link to comment
Share on other sites

On 11/6/2018 at 4:53 PM, maxtherabbit said:

I have recently built a Pentium Pro system (no SSE or even MMX support) and would like to get XP as up to date as possible on it. Would it be safe to install the POSReady updates up through July 2018? Currently the system is running fully up to date as of the official XP updates, no .NET frameworks installed or desired. Thanks

Isn't windows NT 4.0 better for such machine :F

But seriously, You can find a list of latest possible updates for systems without SSE2 somewhere in this thread, but without SSE and MMX? I don't remember anyone in this board mentioned that, sorry :/

Link to comment
Share on other sites

2 hours ago, Mcinwwl said:

Isn't windows NT 4.0 better for such machine :F

But seriously, You can find a list of latest possible updates for systems without SSE2 somewhere in this thread, but without SSE and MMX? I don't remember anyone in this board mentioned that, sorry :/

The machine actually runs XP quite well, I think you'd be surprised :D

 

On 10/18/2018 at 3:17 PM, PPeti66x said:

Because some people had problems with the new XP updates on non-SSE-2 CPUs, I made a big test and installed WinXP SP3 and all updates (up to October 10, 2018 from catalog update) on my old 200 MHz Pentium-1 computer (P5 architecture with MMX support). .NET Framework 2.0 SP2 was installed, but not updated nor tested. Windows Media Player was not updated to v10 or v11 and Windows Search 4.0 was not installed.

The results are:

   - Everything installed fine

   - System booted up correctly

   - Some updates failed to work due to SSE-2 requirement:

      kb4340937 (august, 2018) - msi.dll (and may be msihnd.dll and msiexec.exe)

      kb4343674 (august, 2018) - gdiplus.dll only

      kb4458000 (september, 2018) - gdiplus.dll only

      kb4462987 (october, 2018) - gdiplus.dll only

So the new gdiplus.dll and Windows Installer updates should be skipped on non-SSE-2 CPUs.

But not all installed files are executed by the system by default, so SSE(2) requirement of some of the other files is unknown. e.g. msvidc.dll, t2embed.dll, mf3216.dll, msxml3.dll, msxml6.dll, mrx*, MS JET files should be tested. MS JET seems to be compiled with MSVC12 (which is very uncommon for Windows XP files) - and most of (may be all) MSVC12 compiled applications I used required SSE-2.

=================

A different thing:

I installed the Windows XP SP3 on the Dell M4800 notebook (Haswell, Q87 chipset). Everything works fine (except VGA in CPU - if dedicated VGA is installed, it is always used by XP, but this is by design), but I can not use sleep/stanydby - it is prohibited by "Microsoft ACPI-Compilant System" driver (HWID: ACPI_HAL\PNP0C08). Device state mappings: S0-D0, S1-Unspec., S2-Unspec, S3-D2, S4-D3, S5-D3 (so the supported sleep states: S0, S4, S5). Is possible to solve this problem (e.g. by remapping S3 to D3)?

This poster was also running a non-SSE CPU, and it seems that apart from the listed updates everything else went fine... I'm wondering though if it would be a better idea for me to just load everything up through July 2018, or go ahead and get everything up to now except for the four listed above?

Link to comment
Share on other sites

Ok I went for it - everything up to present with the following excluded:

  • KB4340937
  • KB4343674
  • KB4458000
  • KB4462987
  • KB4034775
  • KB4458006
  • KB4042007
  • KB4050795
  • KB4093257
  • KB4463573
  • KB4074852
  • KB4134651 (both versions offered)

Seems like I'm good, everything's working!

Edited by maxtherabbit
Link to comment
Share on other sites

On 10/19/2018 at 3:17 AM, PPeti66x said:

Because some people had problems with the new XP updates on non-SSE-2 CPUs, I made a big test and installed WinXP SP3 and all updates (up to October 10, 2018 from catalog update) on my old 200 MHz Pentium-1 computer (P5 architecture with MMX support). .NET Framework 2.0 SP2 was installed, but not updated nor tested. Windows Media Player was not updated to v10 or v11 and Windows Search 4.0 was not installed.

The results are:

   - Everything installed fine

   - System booted up correctly

   - Some updates failed to work due to SSE-2 requirement:

      kb4340937 (august, 2018) - msi.dll (and may be msihnd.dll and msiexec.exe)

      kb4343674 (august, 2018) - gdiplus.dll only

      kb4458000 (september, 2018) - gdiplus.dll only

      kb4462987 (october, 2018) - gdiplus.dll only

So the new gdiplus.dll and Windows Installer updates should be skipped on non-SSE-2 CPUs.

But not all installed files are executed by the system by default, so SSE(2) requirement of some of the other files is unknown. e.g. msvidc.dll, t2embed.dll, mf3216.dll, msxml3.dll, msxml6.dll, mrx*, MS JET files should be tested. MS JET seems to be compiled with MSVC12 (which is very uncommon for Windows XP files) - and most of (may be all) MSVC12 compiled applications I used required SSE-2.

I created a script to check if binary contains any SSE2 instructions: http://o.rths.cf/gpc/files1.rt/asm-sse2check.7z

which contains objdump(from strawberry Perl, 2012) and gawk(3.1.5 MBCS edition)

and there is some results(it can't check if code is used conditionally or not, it checks existence only)

browseui.dll ::
75eff021:	0f f4 75 6d          	pmuludq 0x6d(%ebp),%mm6
75eff025:	0f f4 75 8a          	pmuludq -0x76(%ebp),%mm6

dxtmsft.dll ::
41466697:	66 0f 28 c1          	movapd %xmm1,%xmm0
41468917:	f2 0f 2c 04 24       	cvttsd2si (%esp),%eax

dxtrans.dll ::
41539043:	66 0f 28 c1          	movapd %xmm1,%xmm0
41557542:	f2 0f 2c 04 24       	cvttsd2si (%esp),%eax

ieframe.dll ::
3ed59fde:	66 0f 28 c1          	movapd %xmm1,%xmm0
3ee521a0:	0f d4 d6             	paddq  %mm6,%mm2
3ee5714e:	f2 0f 2c 04 24       	cvttsd2si (%esp),%eax

iertutil.dll ::
3ec5fb91:	26 0f 5b b7 54 2c 2b 	cvtdq2ps %es:-0x37d4d3ac(%edi),%xmm6
3ec61265:	0f d4 e2             	paddq  %mm2,%mm4

jscript.dll ::
3e402aef:	66 0f 28 c1          	movapd %xmm1,%xmm0
3e42212e:	f2 0f 2c 04 24       	cvttsd2si (%esp),%eax

msexcl40.dll ::
1000a296:	f2 0f 10 05 a0 10 00 	movsd  0x100010a0,%xmm0
{snip}

msfeeds.dll ::
43cb2ee4:	66 0f 28 c1          	movapd %xmm1,%xmm0
43cefad7:	f2 0f 2c 04 24       	cvttsd2si (%esp),%eax

msfeedsbs.dll ::

mshtml.dll ::
3d1aca7d:	66 0f 28 c1          	movapd %xmm1,%xmm0
3d273d80:	0f d4 60 3d          	paddq  0x3d(%eax),%mm4
3d2920bb:	f2 0f 2c 04 24       	cvttsd2si (%esp),%eax

msihnd.dll ::
4012a0f3:	f2 0f 2c 04 24       	cvttsd2si (%esp),%eax
4012a5ec:	66 0f 28 c1          	movapd %xmm1,%xmm0

msjet40.dll ::
1001c688:	f3 0f 6f 04 85 00 9e 	movdqu 0x10179e00(,%eax,4),%xmm0
{snip}

msjetoledb40.dll ::
10001519:	f3 0f 6f 00          	movdqu (%eax),%xmm0
{snip}

msjter40.dll ::
1000813b:	f2 0f 70 c0 00       	pshuflw $0x0,%xmm0,%xmm0
{snip}

msjtes40.dll ::
100160ee:	f2 0f 10 40 08       	movsd  0x8(%eax),%xmm0
{snip}

msltus40.dll ::
100068e5:	66 0f 13 44 24 0c    	movlpd %xmm0,0xc(%esp)
{snip}

mspbde40.dll ::
10006f05:	66 0f 13 44 24 0c    	movlpd %xmm0,0xc(%esp)
{snip}

msrd2x40.dll ::
10009dca:	f3 0f 7f 02          	movdqu %xmm0,(%edx)
{snip}

msrd3x40.dll ::
1000c402:	f3 0f 6f 41 f0       	movdqu -0x10(%ecx),%xmm0
{snip}

msrepl40.dll ::
1000df27:	f3 0f 6f 46 04       	movdqu 0x4(%esi),%xmm0
{snip}

mstext40.dll ::
10009285:	66 0f 13 44 24 0c    	movlpd %xmm0,0xc(%esp)
{snip}

mstime.dll ::
41e61c93:	66 0f 28 c1          	movapd %xmm1,%xmm0
41ecc75e:	f2 0f 2c 04 24       	cvttsd2si (%esp),%eax

msvidctl.dll ::
5fb60aba:	0f fb a8 f2 4f bd 00 	psubq  0xbd4ff2(%eax),%mm5
{snip}

mswdat10.dll ::
10005258:	66 0f 6f 4e f4       	movdqa -0xc(%esi),%xmm1
{snip}

msxbde40.dll ::
1000453a:	0f fb a8 f2 4f bd 00 	psubq  0xbd4ff2(%eax),%mm5
{snip}

ntdll.dll ::
7c9219ed:	66 0f 28 15 e0 1a 92 	movapd 0x7c921ae0,%xmm2
7c9219f5:	66 0f 28 c8          	movapd %xmm0,%xmm1
7c9219f9:	66 0f 28 f8          	movapd %xmm0,%xmm7
7c921a06:	66 0f 54 05 00 1b 92 	andpd  0x7c921b00,%xmm0
7c921a3a:	66 0f 2e ff          	ucomisd %xmm7,%xmm7
7c921a73:	66 0f 28 d8          	movapd %xmm0,%xmm3
7c921a8a:	66 0f 54 05 d0 1a 92 	andpd  0x7c921ad0,%xmm0
7c921a92:	f2 0f 58 c8          	addsd  %xmm0,%xmm1
7c921ab1:	66 0f 54 1d d0 1a 92 	andpd  0x7c921ad0,%xmm3
7c921b2e:	66 0f 28 15 20 1c 92 	movapd 0x7c921c20,%xmm2
7c921b36:	66 0f 28 c8          	movapd %xmm0,%xmm1
7c921b3a:	66 0f 28 f8          	movapd %xmm0,%xmm7
7c921b47:	66 0f 54 05 50 1c 92 	andpd  0x7c921c50,%xmm0
7c921b7b:	66 0f 2e ff          	ucomisd %xmm7,%xmm7
7c921bb4:	66 0f 28 d8          	movapd %xmm0,%xmm3
7c921bcb:	66 0f 54 05 10 1c 92 	andpd  0x7c921c10,%xmm0
7c921bd3:	f2 0f 5c c8          	subsd  %xmm0,%xmm1
7c921bee:	66 0f 56 1d 40 1c 92 	orpd   0x7c921c40,%xmm3
7c921bf6:	66 0f 54 1d 30 1c 92 	andpd  0x7c921c30,%xmm3

rsaenh.dll ::
68029460:	0f d4 ca             	paddq  %mm2,%mm1
{snip}

win32k.sys ::
bf865b39:	0f 5a 86 bf 27 5d 86 	cvtps2pd -0x79a2d841(%esi),%xmm0

wininet.dll ::
3e55f2a7:	3e 0f f4 55 3e       	pmuludq %ds:0x3e(%ebp),%mm2

 

Link to comment
Share on other sites

16 minutes ago, dencorso said:

Which version of browseui.dll did you test? It seems to me to be a false positive...

April 2018, not the latest one.

and as stated before, script checks existence of SSE2 instructions only, it can't check if such code is used conditionally or not.

Edited by roytam1
Link to comment
Share on other sites

5 hours ago, yuhong said:

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

I can't say it is "False Positive", since cvttsd2si is really SSE2 instruction: https://www.felixcloutier.com/x86/CVTTSD2SI.html

The only problem is that we don't know if code is called ONLY if SSE2 is available.

Link to comment
Share on other sites

@roytam1: with all due respect, @yuhong, just like me, must be thinking the same byte sequence may be part of some section in the binary that's not code, his suggestion is that it may be part of an external symbol reference, in that case. In my experience, to find out which parts of a binary are code without actually executing the file is quite tricky: I've never seen any disassembler, even adaptive ones, that never mistakes data for code... and then, even if there were one that good, we'd still not know whether the code is reachable, and in case it is, whethe it's called conditionally, as you mentioned, or not. But the conditional calling after detecting whether SSE2 is available is the most sophisticated hypothesis, while unreachable code and, particularly, non-code read as code are the most pedestrian ones, so they should be considered first.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...