KB2839299_2003 derived fltMgr upgrade that it is not...

[MilkChan]

1 hour ago, modnar said:

Thank you, @MilkChan for these two builds. 7-zip and WinZip here says the second, SSE2 update is corrupt - would you mind updating the archive, please?

Thank you, @Multibooter for testing.

The funniest thing now is upon re-configuration of my mini-filters, my system works better than ever before with the 5512 XPSP3 fltmgr and filter cascade. I also put TimeOutValue = 3c (60) (s) DWORD before minifilter re-config in my "disk" service (CurrControlSet) that for some reason did not exist in my harkaz-updated SP2 (to uSP4) XP. That might have had the most to do with it...

Nothing was damaged. This is because I use the same SFXCAB installer that Microsoft uses when distributing Updates.
The file is still normal.
7z or WinRAR are not useful because I create compressed files.

[Multibooter]

I have now installed fltmgr.sys build 5107 also under WinXP SP3 on my i7 desktop computer, by booting into Win10 and then copying fltmgr.sys onto the WinXP partition. fltmgr.sys build 5107 works fine on the 3.4GHz i7 desktop under WinXP SP3 and WinXP feels a little crisper

The updated fltmgr.sys is a must-have for slow computers under WinXP, and a nice-to-have for WinXP on fast computers.

The remaining question now is: Which build of fltmgr.sys is the best one for WinXP SP3?

Edited Tuesday at 06:21 PM by Multibooter

[modnar]

On 12/23/2025 at 5:09 PM, MilkChan said:

Nothing was damaged. This is because I use the same SFXCAB installer that Microsoft uses when distributing Updates.
The file is still normal.
7z or WinRAR are not useful because I create compressed files.

I'm sorry, somehow I thought I'd just normally decompress them instead of installing them. :-)

Quote

...The remaining question now is: Which build of fltmgr.sys is the best one for WinXP SP3?

Since MilkChan has built those fine update packages, I'd say SSE (b5107) for slower computers and SSE2 (b6912) for faster. Could you please test both and see which is faster. I think b5107 might be faster (it is also the last build in non-ESU fully updated Server 2003 x86).

Edited Wednesday at 08:43 PM by modnar

[user57]

well technical speaking actually it would be possible to make a check what technology in the XMM registers are possible

there was recently a problem like that with a microsoft file (in the supermium posts) where actually SSE4.1 instructions are used

more professional programms (and useally you would expected something like that from a very big money concern like microsoft) check what instructions are available

(the x265 encoder/decoder does so for example)

after that then the right routine is called up

often it is a compiler setting problem 

one method to avoid this one would be to create an .obj file (what contains the functions without SSE/MMX ect.)

then at first you make the check if SSE can be done

if not you call up that .obj file´s function

if you have SSE you call up your normal function

 

thus you can avoid creating multiple complies like having a SSE version and a non SSE version