Leaderboard

As long as we're not talking about circumventing Windows activation in general, I'll let the conversation continue. I just want to make sure that if anyone else posts in this thread, do not discuss circumventing Windows activation but if you have issues like this that may rely on your copy of Windows being genuine and it is...then feel free to discuss. Thanks!

As all of you Vista users surely know, IE9 is the last version of the MS supplied browser that can be installed on that OS. It has several prerequisites, notably KB948465 (SP2 for Vista SP1), KB971512 (Windows Graphics, Imaging, and XPS Library) and KB2117917 (Platform update supplement for Windows Vista); you can read more here. MS had continued patching security vulnerabilities in IE9 on Vista SP2 via "Cumulative Security Updates for Internet Explorer 9 on Windows Vista SP2" up until Vista's EOL on April 11th of this year (update KB4014661). MS will continue patching IE9 on Windows Server 2008 SP2 (as, again, it's the last version installable there, too) until that product reaches its (Extended Support) EOL in 2020. If you have been following our Server 2008 Updates on Windows Vista thread, then you should have already installed follow-ups KB4018271 (May 2017), KB4021558 (June 2017) and KB4025252 (July 2017). For the rest of this post I'll assume your Vista SP2 OS (ergo IE9 copy) is fully updated even with post EOL updates intended for WS2008SP2; e.g. on my setup (Vista SP2 Home Premium 32bit), "About Internet Explorer" looks like: For those of you out there with an intention to using IE9 as your main browser on Vista, sadly, you'd have come to the conclusion it's only half-usable currently, at best; this is a result of: 1. Most modern sites have removed support for IE9 completely, via UA string sniffing: Somes sites (like Youtube) offer a workaround, for others it may be necessary to spoof the actual UA string as one from a later OS+IE version (e.g. via the "Set UA String" IE addon). 2. Many sites have moved to recent web design, so they don't render correctly (if at all) in IE9, even in "Compatibility View" (well, actually, this is to be expected; CV means the site was optimised for IE8-); FWIW, even MS pages don't display correctly now in IE9 . 3. A third scenario I find quite irritating is that many sites fail to load at all in IE9 if they use the HTTPS protocol; with the recent move of many major sites to the more secure, encrypted, HTTPS, "allegedly" to increase user privacy and security, I found the list of "secure" sites not opening in IE9 growing at a high rate; of course there's always Firefox, but it's IE9 we're discussing here... Upon investigation, I discovered this is due to IE9 on Vista only supporting TLS protocol v1.0; this is considered by today's standards no longer secure enough, so many sites using HTTPS have moved to the more secure versions 1.1, 1.2, even to 1.3! Fortunately, a recent MS update (intended for the WS2008SP2 OS) can be applied on Vista SP2 that will implement TLS 1.1/1.2 support on Vista's IE9, too! ; I have spoken about this important update here. 1. Install then KB4019276 2. Reboot the Vista machine 3. After restart, launch the Registry Editor (regedit), preferably as Administrator. 4. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\AdvancedOptions\CRYPTO\TLS1.1 5. Delete the "OSVersion"="3.6.1.0.0" subkey; BTW, I don't know which WinOS that string refers to (Win6.1=Win7) 6. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\AdvancedOptions\CRYPTO\TLS1.2 7. Again, delete the "OSVersion"="3.6.1.0.0" subkey. Exit Registry Editor. 8. Launch IE9; Tools -> Internet Options -> Advanced tab -> Scroll all the way down to "Security": Prior to KB4019276 and registry manipulations, only "Use TLS 1.0" had been available on Vista; you should have already unchecked the older "Use SSL 2.0/3.0" options, to avoid being targeted by "POODLE" attacks; uncheck "Use TLS 1.0" (optionally also "Use TLS 1.1") and check "Use TLS 1.2". 9. Click Apply, OK, then exit IE9. 10. Upon restarting IE9, you'll find you can now visit all those sites that previously would not load due to unsupported TLS protocols: 10. You can verify further that indeed 1.2 is being used during server-client negotiations via specialised sites or via IE9's native GUI: I honestly hope you'll find my post to be of value; enjoy your more secure (than ever before?) Vista OS!

I think the short answer to your question is because we're enthusiasts, and because we can! (Oh, and we don't like being told by the likes of Microsoft that we can't do something!)

I don't have control because they're cloudflare's server.

According to SSL Labs, Chrome 49 / XP SP3 supports the following protocols and cipher suites: https://www.ssllabs.com/ssltest/viewClient.html?name=Chrome&version=49&platform=XP SP3&key=136 Protocols TLS 1.3 No TLS 1.2 Yes TLS 1.1 Yes TLS 1.0 Yes Cipher Suites (in order of preference) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Forward Secrecy 128 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) Forward Secrecy 256 OLD_TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc13) Forward Secrecy 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) WEAK 256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) WEAK 128 TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) WEAK 128 TLS_RSA_WITH_AES_256_CBC_SHA (0x35) WEAK 256 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) WEAK 128 TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) WEAK 112 I presume the above reflects XP SP3 fully updated until EoS, without any POSReady additional updates; NB that while Chrome 49 comes with its own TLS protocol support, it relies on the OS both for certificates (WinCert store) and supported cipher suites... For completeness, what additional (if any) cipher suites are added via the POSReady updates? To check, launch Ch49 (under XP SP3+POSReady) and visit https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html OTOH, the server "o.rthost.win" resolves into two IPv6 + two IPv4 addresses; e.g., "104.21.48.191" supports the following protocols and cipher suites: https://www.ssllabs.com/ssltest/analyze.html?d=o.rthost.win&s=104.21.48.191 Protocols TLS 1.3 Yes TLS 1.2 Yes TLS 1.1 Yes TLS 1.0 Yes This server supports TLS 1.0 and TLS 1.1. Grade capped to B. This site works only in browsers with SNI support. # TLS 1.3 (server has no preference) TLS_AES_128_GCM_SHA256 (0x1301) ECDH x25519 (eq. 3072 bits RSA) FS 128 TLS_AES_256_GCM_SHA384 (0x1302) ECDH x25519 (eq. 3072 bits RSA) FS 256 TLS_CHACHA20_POLY1305_SHA256 (0x1303) ECDH x25519 (eq. 3072 bits RSA) FS 256 # TLS 1.2 (suites in server-preferred order) TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) ECDH x25519 (eq. 3072 bits RSA) FS 128 OLD_TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc14) ECDH x25519 (eq. 3072 bits RSA) FS 256P TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9) ECDH x25519 (eq. 3072 bits RSA) FS 256P TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) ECDH x25519 (eq. 3072 bits RSA) FS 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 256 # TLS 1.1 (suites in server-preferred order) TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 256 # TLS 1.0 (suites in server-preferred order) TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 256 As you can verify on closer inspection, there exist no common cipher suites between what the browser and the server support, so the OP is absolutely right; the same is indicated by SSL Labs Server Test: Notice how the server is configured to only support cipher suites (TLS_ECDHE_ECDSA_*) with Perfect Forward Secrecy (PF), which, on the one hand, is a good thing, but it may limit the connection ability of older clients... @roytam1, do you have any control on this? If you could add (on the server) support for (even just one of) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) OLD_TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc13) which aren't deemed WEAK, Ch49/XP SP3 could connect over TLSv1.2... PS: For anyone vaguely interested, Chrome 49 / Vista SP2 (fully updated to EoS+TLSv1.2 support from WS2008SP2) can connect natively over TLSv1.2 via "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)" :

A lot of people can’t afford newer computers, and even some of the newer computers (eg. 2019/20 Intel MacBook Pro) can’t “run” Windows 11. But since Windows 11 technically is like a big Windows 10 update, it works fine.

there are 2 branches in development, 2.53 is more mature one: http://www.wg9s.com/comm-253/ while 2.57 is more unstable: http://www.wg9s.com/comm-257/

Ok, I will check this and report about it later and try to find a solution.

Such is life in the land of the unsupported. I use this style as a workaround (Stylem, userContent.css...): @-moz-document domain("drive.google.com") { #drive_main_page { overflow: auto; } }

Replacing K32EnumProcessModules string in the import table with any valid kernel32.dll function name of equal or lesser length, then adding new entry in export table for psapi.dll -> EnumProcessModules, then fixing references (addresses) in the code (so that they don't point to the random kernel32.dll function from the very first step) to the new one could work. There are multiple PE editors that can add new imported functions, don't recall which ones I tried in the past, for the code fixing there's OllyDbg and similar software. I mostly worked with OllyDbg in the past, but it handles only 32-bit stuff. Quick procedure is something like this: Open the DLL. CTRL + N to show imports/exports. Locate the name you changed from the original, right-click, find references something option so you get the list of instructions to update. Check the address of the new name / functions in the window you opened with CTRL + N, go to the instructions found before (double click the entry), then double click the instruction, modify the addresses. Somewhere in the right-click menu is the option to copy everything you changed to the executable on disk. Not easy if you've never juggled with these things before, but doable if you take the time to sit down and absorb it slowly.

On a clean install try only http-links! Here is the link for Serpent 52: http://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20220528-3219d2d-uxp-0855ba43d-xpmod.7z Cheers, AstroSkipper A clean installation of Windows XP is very different depending on the source you used to install from. Truth be told I don't really understand your problem. If the download of a browser installation file doesn't work in your system, you should download it by using another system, your smartphone or your tablet. And then you simply transfer it to your target system. By the way each browser of roytam1's editions will do a good, first job to download further necessary files. I don't need to do that because my download archive contains all important files to install whatever I desire. And furthermore a clean, native installation of Windows XP will lack of the ability to establish system connections using modern protocols and ciphers. In such a case one of the proxies ProxHTTPSProxy or HTTPSProxy will be necessary to establish such connections system-widely. Cheers, AstroSkipper

POSReady '09 isn't even a thing for XP 5.2 (x64 Edition) AFAIK. Not sure the "need" for them is that great.

On a clean install try only http-links! Here is the link for Serpent 52: http://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20220528-3219d2d-uxp-0855ba43d-xpmod.7z Cheers, AstroSkipper

maybe cloudflare do some changes about TLS cipher. you may just change back to http:// instead as my domain doesn't enforce HTTPS usage.

I'm quite shocked on just how well Serpent is working now with those changes/updates.

The files with -ia32 work as well. Like the one in this post.

New NewMoon 27 Build! 32bit https://o.rthost.win/palemoon/palemoon-27.10.0.win32-git-20220528-0bc2879198-xpmod.7z 32bit SSE https://o.rthost.win/palemoon/palemoon-27.10.0.win32-git-20220528-0bc2879198-xpmod-sse.7z 32bit noSSE https://o.rthost.win/palemoon/palemoon-27.10.0.win32-git-20220528-0bc2879198-xpmod-ia32.7z 64bit https://o.rthost.win/palemoon/palemoon-27.10.0.win64-git-20220528-0bc2879198-xpmod.7z source repo: https://github.com/roytam1/palemoon27 repo changes since my last build: - import changes from `dev' branch of rmottola/Arctic-Fox: - Bug 1134252 - Don't crash the content process if RenderFrameParent is not constructed successfully. r=billm. (2564cb0e6a) - Bug 1180644: Fix crashes after enabling OOP on B2GDroid. r=snorp (d585c571e3) - Bug 1198674 - null-check mFrameLoader in RenderFrameParent. r=sotaro (86f26b2046) - Bug 1198674 - Null-check mFrameLoader before calling GetFrom in RenderFrameParent. r=sotaro (33bd495e75) - Bug 1200778 - Make sure to update the APZCTreeManager associated with a RenderFrameParent when it is dragged to a new window. r=mstange (bf2d25616c) - Bug 1202703 - Part 1 - CreateRenderingContext can fail. r=mattwoodrow (50de4cd050) - Bug 1185747 part 1 - Use pref/meta-viewport tag instead of DOMWindowUtils to set the CSS viewport for mochitests. r=tn (62a8c1d460) - Bug 1147038 - Update some tests to pass on desktop platforms. r=tn (afa54f4dc9) - Bug 1169666 - Revert reftest sanity flag ordering, fixes failures on OS X. (553743b4ce) - Bug 1114526. Add reftest. (ef2589e3b8) - Bug 1192616 - Skip over some reftests which fail on the pandaboards with the new dynamic toolbar implementation due to the screen size being too small. r=gbrown (fd3a0a523c) - Bug 1185747 part 2 - Remove magical reftest harness properties and use standard meta-viewport tags instead. r=tn (73d2d442d9) - Bug 1194811 Part 1 - Recompute the zoom constraints if the available screen area changes. r=botond (620dc82022) - Bug 1194811 Part 2 - Use the content viewer size rather than the composition size of the root frame when computing the CSS viewport. r=botond (089459fcb5) - Bug 1185747 part 3 - Rip out code to explicitly override the CSS viewport. r=tn (00ea1c7277) - Bug 1178354 - Ensure we fire a before-first-paint event for printing as well. r=tn (3dfd7f0f76) - Bug 1152254 - Handle vertical text frames when clipping display list for drag image. r=smontagu (965256a547) - Bug 1156135. Add runtime testing of graphics features. r=mattwoodrow,mossop (6a8cb24421) - Refactor the graphics sanity test to support multiple snapshots. (bug 1173117 part 1, r=mattwoodrow) (8a0a78e4d3) - Add an observer service notification for the first widget paint message. (bug 1173117 part 2, r=roc) (e421003dcd) - Fix a widget size check bug in nsWindow::CaptureWidgetOnScreen. (bug 1173117 part 3, r=mattwoodrow) (485694c380) - Add OS snapshotting to the gfx sanity test and report whether or not it matches the compositing test results. (bug 1173117 part 4, r=mattwoodrow,vladan) (38e82d10ad) - Bug 1191608 - initialize element to null in CanvasRenderingContext2D::DrawImage. r=bas (e26dd8b8ce) (e0e5f031a0) - import changes from `dev' branch of rmottola/Arctic-Fox: - Bug 1196041 - Disallow getter/setter with expression closure in class declaration. r=efaust (ee47aae93d) - Bug 1206485 - "Boot loop after first boot on some devices (Xperia M2, ...)" [r=terrence f=lissyx+mozillians] (3c73ad18a9) - Bug 1204368 - Fix modifier used for ASI after do-while. r=Waldo (857712ea07) - Bug 1189872 - Make {Map, Set}.prototype an ordinary object. r=Waldo (69abffd59b) - Bug 1199175 - Fix Debugger::slowPathOnLeaveFrame to remove the frame on OOM too. r=shu (35d190cac7) - code style (debd143914) - Bug 1133196 - Ensure script observability when setting Debugger.Frame.onStep. (r=jandem) (ce207a4762) (9c5061e940) - ported from `custom` branch of UXP: libstagefright: relax ctts flags checking. (d9f11187) (64bef5bfd2) - import changes from `dev' branch of rmottola/Arctic-Fox: - Bug 1204404 - Odin: move assert to avoid assertion failure. r=lth (14bd78e697) - Bug 1204864 - Odin: reject UINT32_MAX heap resize mask. r=bbouvier (7242554d2a) - Bug 1204847: Reinterpret the asmFunc pointer as an AsmFunction in case of offthread compile error; r=luke (b82f210a53) (0bc2879198)

New build of post-deprecated Serpent/moebius for XP! * Notice: This repo will not be built on regular schedule, and changes are experimental as usual. ** Current moebius patch level should be on par with 52.9, but some security patches can not be applied/ported due to source milestone differences between versions. Test binary: Win32 http://o.rthost.win/basilisk/basilisk55-win32-git-20220528-c952169c0-xpmod.7z Win64 http://o.rthost.win/basilisk/basilisk55-win64-git-20220528-c952169c0-xpmod.7z repo: https://github.com/roytam1/basilisk55 Repo changes: - import from UXP: Issue #1899 - Disable the (broken) MDN integration widget by default. (a9d3c2b5) (badef41ee) - import from UXP: Issue #1899 - Make sure the test for it still works (5338dcd1) (dbdfa5c5a) - import from UXP: Issue #1813 - Enable date and time picker by default. (86db73b5) (897709ad7) - import from UXP: Issue #1210 - Keep timepicker disabled for now. (1bf41a59) (b2e9a3ed6) - ported from UXP: Bug 1679987 - Remove unused includes of nsCharSeparatedTokenizer.h. (62a140ab) (adb65da82) - import from UXP: Issue #1894 - Part 1: Implement coalesce JS opcode (3efa2347) (724f5386d) - import from UXP: Issue #1894 - Part 2: Implement support for nullish coalescing in the JS parser (d7cdeaf3) (3f52d9a1e) - import from UXP: Issue #1894 - Part 3: Implement support for nullish coalescing in JS reflection (f282a4c0) (9d96714a9) - ported from UXP: Issue #1894 - Part 4: Implement IonMonkey support for nullish coalescing (58127218) (e22fd60eb) - import from UXP: Issue #1894 - Part 5: Implement bytecode for nullish coalescing (707867d1) (ed1e4b60e) - import from UXP: Issue #1894 - Part 6: Check for nullish values when folding coalesce nodes (9dde32ee) (4c25f1d2e) - import from UXP: Issue #1894 - Part 7: Update tests (f0e208a8) (c953ce433) - import from UXP: No issue - Add null check to send packet function in the developer tools server (2e975416) (3f8cd2184) - ported from UXP: Issue #457 - Silence some GCC compiler warnings in FFmpeg code (5c61382d) (a9ce580ca) - import from `custom` branch of UXP: libstagefright: relax ctts flags checking. (d9f11187) (c952169c0)

New build of Serpent/UXP for XP! Test binary: Win32 https://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20220528-3219d2d-uxp-0855ba43d-xpmod.7z Win64 https://o.rthost.win/basilisk/basilisk52-g4.8.win64-git-20220528-3219d2d-uxp-0855ba43d-xpmod.7z source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/custom IA32 Win32 https://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20220528-3219d2d-uxp-0855ba43d-xpmod-ia32.7z source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/ia32 NM28XP build: Win32 https://o.rthost.win/palemoon/palemoon-28.10.6a1.win32-git-20220528-d849524bd-uxp-0855ba43d-xpmod.7z Win32 SSE https://o.rthost.win/palemoon/palemoon-28.10.6a1.win32-git-20220528-d849524bd-uxp-0855ba43d-xpmod-sse.7z Win64 https://o.rthost.win/palemoon/palemoon-28.10.6a1.win64-git-20220528-d849524bd-uxp-0855ba43d-xpmod.7z Official UXP changes picked since my last build: - Bug 1679987 - Remove unused includes of nsCharSeparatedTokenizer.h. (62a140ab8) - Issue #1894 - Part 1: Implement coalesce JS opcode (3efa23472) - Issue #1894 - Part 2: Implement support for nullish coalescing in the JS parser (d7cdeaf31) - Issue #1894 - Part 3: Implement support for nullish coalescing in JS reflection (f282a4c05) - Issue #1894 - Part 4: Implement IonMonkey support for nullish coalescing (581272180) - Issue #1894 - Part 5: Implement bytecode for nullish coalescing (707867d16) - Issue #1894 - Part 6: Check for nullish values when folding coalesce nodes (9dde32ee9) - Issue #1894 - Part 7: Update tests (f0e208a86) - No issue - Add null check to send packet function in the developer tools server (2e975416b) - Issue #457 - Silence some GCC compiler warnings in FFmpeg code (5c61382da) - No issue - relax ctts flag checking in media/libstagefright (2f8131275) No official Pale-Moon changes picked since my last build. No official Basilisk changes picked since my last build. My changes picked since my last build: - libstagefright: relax ctts flags checking. (d9f111872) - [Basilisk] pdfjs: remove telemetry (0855ba43d) * Notice: From now on, UXP rev will point to `custom` branch of my UXP repo instead of MCP UXP repo, while "official UXP changes" shows only `tracking` branch changes.

I was the first who posted about how to hex edit the DLL one way to extend the date, at least on MSFN. Didn't know about that project though...just hex-edited my DLL and forgot about it. FlashPatch! doesn't run on XP, but most of it can be made to run with small modifications. FlashPatch_NetFx4.zip FlashPatch_NetFx4_src.zip I threw out some unreferenced namepaces from .csproj file, commented out update checking function and fixed another error related to retrieving HRESULT code from Exception object occurring when accessing it directly on older .NET version, then it compiles on XP using .NET Framework 4's bundled tools: cd <path\to\FlashPatch\folder> C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe FlashPatch.csproj /p:Configuration=Release

True

I've already mentioned this issue: Original post is about implementing TLS 1.1/1.2 support to IE9; it will allow for opening HTTPS websites that were previously inaccessible to IE9, because it would go as far as TLS 1.0. Sadly, the recent MS update has nothing to do with IE9's rendering engine, which is what's used to properly display (render) a loaded webpage . For sites that do open but don't display correctly (and/or are not fully functional) you'll have to use another, more modern, browser that supports more recent Javascript and CSS code needed to render them correctly; apologies, but I'm not an expert in HTML and web design, so my terminology might be somewhat off, but I think you still get the picture (... or lack of it, if it fails to render in IE9 ! ). Please have a read of this older forum thread ; WS 2008 SP2 is already inside Extended Support (i.e. no new features, only security updates issued for it), so I was pleasantly surprised by KB4019276 which, depending on how you look at it, could be considered as a new OS feature; OTOH, it can simply fall inside the "security" category, since it improves the "security" protocols used when accessing HTTPS web places... I don't think that MS will issue any future updates in the remaining 2.5 years (till WS 2008 SP2 becomes EOL) that would enable an upgrade of IE9's layout engine - security: YES, they are still catering for that; functionality: THEY SIMPLY DON'T CARE; else they would've upgraded their own browser to IE10 or IE11 (possibly after a Vista/WS 2008 SP3 and/or a second Platform Update...).

Omg im actually really keen on trying this,thanks for once again keep Vista Alive and IE9 aswell ofcourse Also when i use ie9 webpages dont load/render properly do you know of any fix for this? (eg. hltv.org)