Jump to content

Last Version of Software for Windows 8.1


xedakide

Recommended Posts

On 10/24/2023 at 7:02 AM, Dixel said:

Why not download it from a reputable source and place in the Opera folder?

 

I looked everywhere but strangely couldn't find it. I don't know what went wrong, can't believe a system dll is not available on the web.

Link to comment
Share on other sites


11 hours ago, ceo54 said:

I don't know what went wrong, can't believe a system dll is not available on the web.

Because it's not a DLL, it's an API contract name.

https://learn.microsoft.com/en-us/windows/win32/apiindex/windows-apisets

CRT may have had pseudo DLLs for runtime compatibility with older Windows, VC Redist 2015-2019 was (is?) compatible with XP at some point, which knows nothing about API sets.

No such thing for core Windows API functions, if Win8.1 doesn't recognize the contract name, the referenced API function likely isn't implemented on it.

Link to comment
Share on other sites

4 hours ago, UCyborg said:

No such thing for core Windows API functions, if Win8.1 doesn't recognize the contract name, the referenced API function likely isn't implemented on it.

Putting doubts in the fact @yoltboy01runs Opera on 8.1?

Link to comment
Share on other sites

16 hours ago, ceo54 said:

 

Thanks. Yeah, my system is updated till September 2023 (only October updates are not installed)

Okay I tried the steps as shown in the video for Opera but unfortunately the result is the same. When I copy DWrite.dll and launch Opera, it complains about missing api-ms-win-core-localization-l1-2-2.dll

I think this is some kinda runtime library so I installed all C++ runtimes, 2005-2022 to no avail. I already have .Net 3.5 and 4.8 so I'm out of ideas. 

Also, it's kinda weird to be not able to find a Windows .dll online. I looked everywhere but couldn't find this api-ms-win-core-localization-l1-2-2.dll

 

Nonetheless, thank you for the help, Your support is highly appreciated.

 

Nonethe

 

2 hours ago, Saxon said:

Putting doubts in the fact @yoltboy01runs Opera on 8.1?

That's very strange. 

I am running Windows 8.1 x64 (!) in a VM but that ISO is fully updated till January 2023 (!). No mods, no tweaks what so ever. Sometimes, I even delete that VM and create a new one once a month. I install CFF Explorer, 7 Zip and use DWrite.dll (from Windows 10 Build 9926) (!). 

The tutorial shown in the linked video above is my video. Please don't forget to make a shortcut of opera.exe on the desktop and NOT launch it in it's folder because of --no-sandbox

I am currently writing this in my VM, running Opera dev 105 (based on Chromium 119)

Link to comment
Share on other sites

So older Windows 10 builds and Windows 8.1 for instance still use those pseudo/stub DLLs. I compared DWrite.dll from my Win10 20H2 install and Win8.1 ISO, latter updated till December 2017. Win10's DLL is linked to a function implemented in Vista era LCIDToLocaleName under api-ms-win-core-localization-l1-2-2.dll (points to kernelbase.dll), no other functions are linked to under that contract name while Win8.1 DLL uses the name api-ms-win-core-localization-obsolete-l1-2-0.dll pointing to the same function and the DLL where it's implemented. Maybe using system copy of api-ms-win-core-localization-obsolete-l1-2-0.dll renamed to api-ms-win-core-localization-l1-2-2.dll would work. Link to DWrite.dll from the video is dead BTW.

Link to comment
Share on other sites

10 hours ago, UCyborg said:

Maybe using system copy of api-ms-win-core-localization-obsolete-l1-2-0.dll renamed to api-ms-win-core-localization-l1-2-2.dl

This is what I said in my post above, literally, and even attached the signed file. I still think it's some odd behaviour of the programme - since @yoltboy01doesn't get that precise error, and to answer your question, yes they still use those stubs, why wouldn't they? I'll tell even more, there was a patch that ports all win10 UCRT functionality to Vista, so one can simply salvage those stubs from there, just a hint.

Link to comment
Share on other sites

Just replacing "DiscardVirtualMemory" with "VirtualAlloc" in opera_browser.dll (or equivalent in other browser ) doesn't make much sense, they're different functions and have different number of parameters, leaving VirtualAlloc to be called in place of DiscardVirtualMemory corrupts the stack after function returns, plus it'll receive some other values in the stack in place of its 3rd and 4th parameter, so it can't know what it should do exactly. When I got 32-bit Opera 104.0.4944.33 running with just that string replaced, it didn't take long for the tab that opened on first launch to crash.

Chromium uses DiscardVirtualMemory in its memory manager, it's a faster way to do one specific operation that could be done with VirtualAlloc with MEM_RESET flag pre-Win10. There is still fallback to VirtualAlloc in place, so easiest way to get it going correctly is to simply skip the code that would call DiscardVirtualMemory. I think they used to check if function exists before dropping pre-Win10 OS, might have to check older revisions to be sure. Obviously, we still have to replace the string "DiscardVirtualMemory" in the import table so the loader is happy when it loads the DLL.

Here's the full patch that can be applied with x32dbg (included with x64dbg), this is only for opera_browser.dll of 32-bit Opera 104.0.4944.33, started with this one as I'm more at home with x86 code. The text file usually has *.1337 extension. I was working with a very recent version of x32dbg, it's compatible with Windows 8.1.

>opera_browser.dll
000000D0:89->EA
000000D1:E9->78
000000D2:E4->E5
032BD3CB:57->EB
032BD3CC:56->11
032BD3CD:E8->CC
032BD3CE:24->CC
032BD3CF:79->CC
032BD3D0:2D->CC
032BD3D1:06->CC
032BD3D2:85->CC
032BD3D3:C0->CC
032BD3D4:75->CC
032BD3D5:08->CC
0448C04F:53->8B
0448C050:8B->7C
0448C051:7C->24
0448C052:24->04
0448C053:08->E9
0448C054:57->80
0448C055:E8->00
0448C056:9C->00
0448C057:8C->00
0448C058:10->CC
0448C059:05->CC
0448C05A:85->CC
0448C05B:C0->CC
0448C05C:75->CC
0448C05D:7A->CC
0448C05E:8B->CC
0448C05F:54->CC
0448C060:24->CC
0448C061:08->CC
0448C062:8B->CC
0448C063:5C->CC
0448C064:24->CC
0448C065:0C->CC
0448C066:8B->CC
0448C067:7C->CC
0448C068:24->CC
0448C069:10->CC
0448C06A:E9->CC
0448C06B:E5->CC
0448C06C:FE->CC
0448C06D:FF->CC
0448C06E:FF->CC
0448C0C2:56->8B
0448C0C3:8B->7C
0448C0C4:7C->24
0448C0C5:24->0C
0448C0C6:10->EB
0448C0C7:57->38
0448C0C8:E8->CC
0448C0C9:29->CC
0448C0CA:8C->CC
0448C0CB:10->CC
0448C0CC:05->CC
0448C0CD:85->CC
0448C0CE:C0->CC
0448C0CF:75->CC
0448C0D0:2F->CC
0798707E:53->EB
0798707F:57->09
07987080:E8->CC
07987081:71->CC
07987082:DC->CC
07987083:C0->CC
07987084:01->CC
07987085:85->CC
07987086:C0->CC
07987087:74->CC
07987088:2F->CC
0A7FCF04:44->56
0A7FCF06:73->72
0A7FCF07:63->74
0A7FCF08:61->75
0A7FCF09:72->61
0A7FCF0A:64->6C
0A7FCF0B:56->41
0A7FCF0C:69->6C
0A7FCF0D:72->6C
0A7FCF0E:74->6F
0A7FCF0F:75->63
0A7FCF10:61->00
0A7FCF11:6C->00
0A7FCF12:4D->00
0A7FCF13:65->00
0A7FCF14:6D->00
0A7FCF15:6F->00
0A7FCF16:72->00
0A7FCF17:79->00

When importing it into x32dbg, say yes to both prompts that appear. You have to at least open opera_browser.dll before and "launch" it before you can right-click->Patches (or CTRL+P)->Import, then Patch File to save the patched copy on the disk. I like things to look clean so it's not the most minimalistic...back in the day I went out of my way to leave no empty gaps, now that makes it super annoying for someone who would want to compare changes afterwards!

About "api-ms-win-core-localization-l1-2-2.dll" error, you don't get it if you actually use DWrite.dll from Windows 10 Build 9926, but with many newer versions, they're linked to "api-ms-win-core-localization-l1-2-2.dll" rather than "api-ms-win-core-localization-obsolete-l1-2-0.dll". The latter is supplied with Windows 8.1. Still, I used DWrite.dll from my daily driver Win10 installation, so I just created a hard link of system "api-ms-win-core-localization-obsolete-l1-2-0.dll" named as "api-ms-win-core-localization-l1-2-2.dll" to satisfy DWrite.dll's dependencies without having to modify DWrite.dll, as some have apparently done in the past. Dixel's suggestion about "api-ms-win-core-localization-l1-2-0.dll" is redundant, the one supplied with Windows 8.1 already satisfies the other dependencies of newer DWrite.dll, related to localization APIs and most importantly, doesn't contain any API that "obsolete" version does.

To put it simple, there's just one lone function that was exported through "api-ms-win-core-localization-obsolete-l1-2-0.dll" at one point on Windows 8.1 and early Windows 10 builds, but got moved to "api-ms-win-core-localization-l1-2-2.dll", so that's what newer DWrite.dll references. Today's Windows 10 and 11 no longer use stub DLLs, it's all handled internally by the loader, so even when there's no actual DLL referenced (despite being called DLL), the special name with the help of the logic in the loader makes a link to real DLL where particular function implemented. Just read the bloody docs...those who actually want to learn something.

spacer.png

It still has to be run without sandbox, which I hear is pretty much Win10 exclusive in its current form.

Edited by UCyborg
Small additions
Link to comment
Share on other sites

10 hours ago, UCyborg said:

Just replacing "DiscardVirtualMemory" with "VirtualAlloc" in opera_browser.dll (or equivalent in other browser ) doesn't make much sense, they're different functions and have different number of parameters, leaving VirtualAlloc to be called in place of DiscardVirtualMemory corrupts the stack after function returns, plus it'll receive some other values in the stack in place of its 3rd and 4th parameter, so it can't know what it should do exactly. When I got 32-bit Opera 104.0.4944.33 running with just that string replaced, it didn't take long for the tab that opened on first launch to crash.

Chromium uses DiscardVirtualMemory in its memory manager, it's a faster way to do one specific operation that could be done with VirtualAlloc with MEM_RESET flag pre-Win10. There is still fallback to VirtualAlloc in place, so easiest way to get it going correctly is to simply skip the code that would call DiscardVirtualMemory. I think they used to check if function exists before dropping pre-Win10 OS, might have to check older revisions to be sure. Obviously, we still have to replace the string "DiscardVirtualMemory" in the import table so the loader is happy when it loads the DLL.

Here's the full patch that can be applied with x32dbg (included with x64dbg), this is only for opera_browser.dll of 32-bit Opera 104.0.4944.33, started with this one as I'm more at home with x86 code. The text file usually has *.1337 extension. I was working with a very recent version of x32dbg, it's compatible with Windows 8.1.

>opera_browser.dll
000000D0:89->EA
000000D1:E9->78
000000D2:E4->E5
032BD3CB:57->EB
032BD3CC:56->11
032BD3CD:E8->CC
032BD3CE:24->CC
032BD3CF:79->CC
032BD3D0:2D->CC
032BD3D1:06->CC
032BD3D2:85->CC
032BD3D3:C0->CC
032BD3D4:75->CC
032BD3D5:08->CC
0448C04F:53->8B
0448C050:8B->7C
0448C051:7C->24
0448C052:24->04
0448C053:08->E9
0448C054:57->80
0448C055:E8->00
0448C056:9C->00
0448C057:8C->00
0448C058:10->CC
0448C059:05->CC
0448C05A:85->CC
0448C05B:C0->CC
0448C05C:75->CC
0448C05D:7A->CC
0448C05E:8B->CC
0448C05F:54->CC
0448C060:24->CC
0448C061:08->CC
0448C062:8B->CC
0448C063:5C->CC
0448C064:24->CC
0448C065:0C->CC
0448C066:8B->CC
0448C067:7C->CC
0448C068:24->CC
0448C069:10->CC
0448C06A:E9->CC
0448C06B:E5->CC
0448C06C:FE->CC
0448C06D:FF->CC
0448C06E:FF->CC
0448C0C2:56->8B
0448C0C3:8B->7C
0448C0C4:7C->24
0448C0C5:24->0C
0448C0C6:10->EB
0448C0C7:57->38
0448C0C8:E8->CC
0448C0C9:29->CC
0448C0CA:8C->CC
0448C0CB:10->CC
0448C0CC:05->CC
0448C0CD:85->CC
0448C0CE:C0->CC
0448C0CF:75->CC
0448C0D0:2F->CC
0798707E:53->EB
0798707F:57->09
07987080:E8->CC
07987081:71->CC
07987082:DC->CC
07987083:C0->CC
07987084:01->CC
07987085:85->CC
07987086:C0->CC
07987087:74->CC
07987088:2F->CC
0A7FCF04:44->56
0A7FCF06:73->72
0A7FCF07:63->74
0A7FCF08:61->75
0A7FCF09:72->61
0A7FCF0A:64->6C
0A7FCF0B:56->41
0A7FCF0C:69->6C
0A7FCF0D:72->6C
0A7FCF0E:74->6F
0A7FCF0F:75->63
0A7FCF10:61->00
0A7FCF11:6C->00
0A7FCF12:4D->00
0A7FCF13:65->00
0A7FCF14:6D->00
0A7FCF15:6F->00
0A7FCF16:72->00
0A7FCF17:79->00

When importing it into x32dbg, say yes to both prompts that appear. You have to at least open opera_browser.dll before and "launch" it before you can right-click->Patches (or CTRL+P)->Import, then Patch File to save the patched copy on the disk. I like things to look clean so it's not the most minimalistic...back in the day I went out of my way to leave no empty gaps, now that makes it super annoying for someone who would want to compare changes afterwards!

About "api-ms-win-core-localization-l1-2-2.dll" error, you don't get it if you actually use DWrite.dll from Windows 10 Build 9926, but with many newer versions, they're linked to "api-ms-win-core-localization-l1-2-2.dll" rather than "api-ms-win-core-localization-obsolete-l1-2-0.dll". The latter is supplied with Windows 8.1. Still, I used DWrite.dll from my daily driver Win10 installation, so I just created a hard link of system "api-ms-win-core-localization-obsolete-l1-2-0.dll" named as "api-ms-win-core-localization-l1-2-2.dll" to satisfy DWrite.dll's dependencies without having to modify DWrite.dll, as some have apparently done in the past. Dixel's suggestion about "api-ms-win-core-localization-l1-2-0.dll" is redundant, the one supplied with Windows 8.1 already satisfies the other dependencies of newer DWrite.dll, related to localization APIs and most importantly, doesn't contain any API that "obsolete" version does.

To put it simple, there's just one lone function that was exported through "api-ms-win-core-localization-obsolete-l1-2-0.dll" at one point on Windows 8.1 and early Windows 10 builds, but got moved to "api-ms-win-core-localization-l1-2-2.dll", so that's what newer DWrite.dll references. Today's Windows 10 and 11 no longer use stub DLLs, it's all handled internally by the loader, so even when there's no actual DLL referenced (despite being called DLL), the special name with the help of the logic in the loader makes a link to real DLL where particular function implemented. Just read the bloody docs...those who actually want to learn something.

spacer.png

It still has to be run without sandbox, which I hear is pretty much Win10 exclusive in its current form.

Do you know a way in how to make Chrome 115+ working on Windows 8.1?

Link to comment
Share on other sites

I might, got latest Ungoogled Chromium 118 to launch, it loads web pages as well, but it normally crashes on resolving delay-imported function QueryUnbiasedInterruptTimePrecise, Win8.1 only has version without "Precise".

spacer.png

Did a bit of reading on x64 calling convention, might explain why initial DiscardVirtualMemory hack wasn't as disastrous on 64-bit binaries, first four parameters of a function call are passed in CPU registers, not on stack.

Patch for 64-bit chrome.dll version 118.0.5993.88:

>chrome.dll
0000000000294616:48->EB
0000000000294617:89->13
0000000000294618:D6->CC
0000000000294619:48->CC
000000000029461A:89->CC
000000000029461B:CF->CC
000000000029461C:E8->CC
000000000029461D:2F->CC
000000000029461E:1B->CC
000000000029461F:44->CC
0000000000294620:0A->CC
0000000000294621:85->CC
0000000000294622:C0->CC
0000000000294623:74->CC
0000000000294624:1D->CC
0000000000294625:48->CC
0000000000294626:89->CC
0000000000294627:F9->CC
0000000000294628:48->CC
0000000000294629:89->CC
000000000029462A:F2->CC
0000000000299C77:48->EB
0000000000299C78:89->11
0000000000299C79:F1->CC
0000000000299C7A:4C->CC
0000000000299C7B:89->CC
0000000000299C7C:FA->CC
0000000000299C7D:E8->CC
0000000000299C7E:CE->CC
0000000000299C7F:C4->CC
0000000000299C80:43->CC
0000000000299C81:0A->CC
0000000000299C82:85->CC
0000000000299C83:C0->CC
0000000000299C84:0F->CC
0000000000299C85:84->CC
0000000000299C86:FA->CC
0000000000299C87:00->CC
0000000000299C88:00->CC
0000000000299C89:00->CC
0000000000299F38:4C->EB
0000000000299F39:89->0D
0000000000299F3A:F1->CC
0000000000299F3B:4C->CC
0000000000299F3C:89->CC
0000000000299F3D:E2->CC
0000000000299F3E:E8->CC
0000000000299F3F:0D->CC
0000000000299F40:C2->CC
0000000000299F41:43->CC
0000000000299F42:0A->CC
0000000000299F43:85->CC
0000000000299F44:C0->CC
0000000000299F45:74->CC
0000000000299F46:9A->CC
0000000005666C6E:48->EB
0000000005666C6F:89->0D
0000000005666C70:F9->CC
0000000005666C71:4C->CC
0000000005666C72:89->CC
0000000005666C73:F2->CC
0000000005666C74:E8->CC
0000000005666C75:D7->CC
0000000005666C76:F4->CC
0000000005666C77:06->CC
0000000005666C78:05->CC
0000000005666C79:85->CC
0000000005666C7A:C0->CC
0000000005666C7B:74->CC
0000000005666C7C:1D->CC
000000000BD5774C:50->00
000000000BD5774D:72->00
000000000BD5774E:65->00
000000000BD5774F:63->00
000000000BD57750:69->00
000000000BD57751:73->00
000000000BD57752:65->00
000000000BD58042:31->30
000000000BD5B02A:44->56
000000000BD5B02C:73->72
000000000BD5B02D:63->74
000000000BD5B02E:61->75
000000000BD5B02F:72->61
000000000BD5B030:64->6C
000000000BD5B031:56->41
000000000BD5B032:69->6C
000000000BD5B033:72->6C
000000000BD5B034:74->6F
000000000BD5B035:75->63
000000000BD5B036:61->00
000000000BD5B037:6C->00
000000000BD5B038:4D->00
000000000BD5B039:65->00
000000000BD5B03A:6D->00
000000000BD5B03B:6F->00
000000000BD5B03C:72->00
000000000BD5B03D:79->00
Edited by UCyborg
Link to comment
Share on other sites

On 10/17/2023 at 1:48 AM, Dixel said:

It'd be very interesting to read your feedback regarding Supermium. You say it's heavy, what's your system?

Answer here, please.

https://msfn.org/board/topic/185045-supermium/page/

An Dell Insprion 3670 with an i3-8100. Both browsers require disabling loading inactive tabs, otherwise the computer slows to a halt. I had dozens of tabs open on twitter- a pretty heavy site considering all the media.

Link to comment
Share on other sites

On 10/28/2023 at 7:43 PM, Dixel said:

Or maybe try this one (digitally signed). Just rename it to api-ms-win-core-localization-l1-2-2.dll

api-ms-win-core-localization-l1-2-0.zip 7 kB · 5 downloads

Many thanks for the support @Dixel but this library caused another issue. When I launch Opera, it won't come up and crashpad debug log says not a valid win32 app. I downloaded api-ms-win-core-localization-obsolete-l1-2-0.dll and renamed it to api-ms-win-core-localization-l1-2-2.dll and now it seems to be working. Haven't tested youtube/download/upload or MB pages yet but will test and report back.

Many thanks to @yoltboy01 @Dixel @mjd79 & @UCyborg for the kind help. You guys rock.

 

Edit: Everything seems to be working normally, except for the scrollbars. When I move the scrollbars to move page up/down, browser gets resized instead.

Edited by ceo54
Link to comment
Share on other sites

14 hours ago, ceo54 said:

Many thanks for the support @Dixel but this library caused another issue. When I launch Opera, it won't come up and crashpad debug log says not a valid win32 app. I downloaded api-ms-win-core-localization-obsolete-l1-2-0.dll and renamed it to api-ms-win-core-localization-l1-2-2.dll and now it seems to be working. Haven't tested youtube/download/upload or MB pages yet but will test and report back.

Many thanks to @yoltboy01 @Dixel @mjd79 & @UCyborg for the kind help. You guys rock.

 

Edit: Everything seems to be working normally, except for the scrollbars. When I move the scrollbars to move page up/down, browser gets resized instead.

Your welcome. I hope that the compatibility for Firefox and Opera will be up for a good amount of time on 8(.1) without the need of an Extended Kernel.

Firefox 121 is the sixth post-EOL version and Opera 106 (Chromium 119) the eleventh to work on Windows 8.1 with the methods stated above.  

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...