Open idontyboi opened 11 months ago
Of course my friend. I want know reason of some bugs:
Thanks, I only test in XP32. I'm posting this from Supermium 118 on Windows XP. I'm pretty sure that Chrome 103 - 109 will work with the same ncrypt.dll workaround.
Debug spam in dwmapi_main.c:196
Please mute this debug spam.
Extensions can not be installed
This happens:
DebugString: "Unexpected object name: L"\\Device\\HarddiskVolume1\\Documents and Settings\\Administrator\\Local Settings\\Temp\\a0229288-db85-4a03-8eac-4441e13dcdc5.tmp""
DebugString: "Unexpected object name: L"\\Device\\HarddiskVolume1\\Documents and Settings\\Administrator\\Local Settings\\Temp\\Supermium\\User Data\\Default\\Extensions\\Temp\\8acc5a46-6ab1-49d0-a7fc-8c21f83eb9d6.tmp""
There is a issue with GetFinalPathNameByHandleW
. You should enhance this function to accept that, likely syncing this function with latest Wine.
The next thing that is required is accepting Windows 7 flags in FindFirstFileEx.
Downloads not working is likely the same reason.
File Dialog cannot be opened
Likely expects full Vista File Dialog implementation.
get.webgl.org crashes the tab or browser
It crashes on SwitchToFiber function. Not much else known about it.
Did you use some dlls other than ncrypt.dll to get Supermium 118 to work? For me I can launch Chrome 103-109 and Supermium 117 (without crashing), but I keep getting Aw Snap error on Supermium 118.
Edit: Ok now it works fine by adding --single-process and --disable-webgl on the shortcut. Also I just noticed that the browser looks off (Did they readded GDI rendering?).
I used --single-process --disable-webgl
shortcut to reduce memory and be able to debug the process [thus see what caused it to crash in the first place] and to make Chrome take less memory. I haven't tested without it: that is the only DLL I used.
More issues:
User data seems to be stored in the %TEMP%... for some reason. So if you clear temporary directories, browser data is gone.
Rendering a PDF crashes the whole browser. It's painful to investigate due to memory constraints and the debugger itself crashing, but it could be due to the extension issues.
check it out https://github.com/Chuyu-Team/YY-Thunks/issues/29
Can you help-me about Firefox 55 issue too?
Oh, good timing. I was testing that and got Firefox 59.0.3 working. Patch mozglue.dll
0000688E: 3D 90
0000688F: B4 90
00006890: 05 90
00006891: 00 90
00006892: 00 90
0000AFD7: 68 EB
0000AFD8: 20 0E
Also go on about:config and disable multiprocess otherwise every tab crashes
ntdll.LdrRegisterDllNotification is required to get Firefox 59+ working.
It's likely that you also need either a real implementation of LdrRegisterDllNotification or enhancements to condition variables.
If you want I can open another issue
Thanks for all! Do you have discord, skype or any way to contact you? Do you tested Opera too? I don't know why Opera traditional not work and Opera GX work. Edge only work if you install Visual Studio Debugger. All installers not working.
I do, what's your Discord username?
It's expected that all the other Chromium browsers call said ncrypt.dll API and crash/burn, but I have only tested Supermium. Some likely don't call the defect API.
Also consider running WINE tests and unzip the tests to see API conformance with Windows. Condition variables have very poor results, and this impacts Firefox 59 requiring a patch to skip over errors. kernel32_test.exe file
also causes a BSOD.
kernel32_test.exe sync
sync.c:2797: Test failed: got 3735928559
sync.c:475: Tests skipped: RtlInterlockedPushListSListEx not available, skipping tests
sync.c:596: memory resource notifications not supported
sync.c:1159: Test failed: DeleteTimerQueueTimer
sync.c:1964: Test failed: SleepConditionVariableCS should return ERROR_TIMEOUT on untriggered condvar, not 317
sync.c:1973: Test failed: SleepConditionVariableSRW should return ERROR_TIMEOUT on untriggered condvar, not 317
sync.c:1980: Test failed: SleepConditionVariableSRW should return ERROR_TIMEOUT on untriggered condvar, not 317
sync.c:1869: Test failed: SleepConditionVariableCS should return ERROR_TIMEOUT on out of band wake, not 317
sync.c:1879: Test failed: SleepConditionVariableCS should return ERROR_TIMEOUT on out of band wake, not 317
sync.c:1898: Test failed: SleepConditionVariableCS should return ERROR_TIMEOUT on out of band wake, not 317
sync.c:1964: Test failed: SleepConditionVariableCS should return ERROR_TIMEOUT on untriggered condvar, not 87
sync.c:1973: Test failed: SleepConditionVariableSRW should return ERROR_TIMEOUT on untriggered condvar, not 87
sync.c:1980: Test failed: SleepConditionVariableSRW should return ERROR_TIMEOUT on untriggered condvar, not 87
sync.c:1869: Test failed: SleepConditionVariableCS should return ERROR_TIMEOUT on out of band wake, not 87
sync.c:1879: Test failed: SleepConditionVariableCS should return ERROR_TIMEOUT on out of band wake, not 87
sync.c:1885: Test failed: SleepConditionVariableCS should return TRUE on good wake
sync.c:1891: Test failed: SleepConditionVariableCS should return TRUE on good wakeall
sync.c:1898: Test failed: SleepConditionVariableCS should return ERROR_TIMEOUT on out of band wake, not 87
sync.c:1904: Test failed: SleepConditionVariableCS should still return TRUE on crit unlock delay
sync.c:1918: Test failed: pSleepConditionVariableSRW should return TRUE on good wake
sync.c:1924: Test failed: pSleepConditionVariableSRW should return TRUE on good wake
sync.c:1930: Test failed: pSleepConditionVariableSRW should return TRUE on good wake
sync.c:1936: Test failed: pSleepConditionVariableSRW should return TRUE on good wake
sync.c:1757: Test failed: error occurred during SleepConditionVariableCS
sync.c:1761: produced 50, c1 5, c2 23, c3 22
sync.c:1765: producer sleep 21, consumer sleep 15
sync.c:2420: Test failed: thread commands were executed in the wrong order (occurred 11 times).
sync.c:2424: Test failed: AcquireSRWLockExclusive didn't block when called multiple times from the same thread (occurred
2 times).
sync.c:2428: Test failed: AcquireSRWLockShared didn't block when the same thread holds an exclusive lock (occurred 2 tim
es).
sync.c:2432: Test failed: AcquireSRWLockExclusive didn't block when the same thread holds a shared lock (occurred 2 time
s).
sync.c:2436: Test failed: AcquireSRWLockExclusive didn't block when a second thread holds the exclusive lock (occurred 2
times).
sync.c:2440: Test failed: thread waiting for exclusive access to the SHMLock was not preferred (occurred 3 times).
sync.c:2532: number of shared accesses per thread are c1 46, c2 52, c3 46
sync.c:2533: number of total exclusive accesses is 11
sync.c:2739: Test failed: Unexpected debug info pointer 00F83D70.
06e0:sync: 1338191 tests executed (0 marked as todo, 0 as flaky, 29 failures), 1 skipped.
My Discord is Samuel Marins#0436
Did you use some dlls other than ncrypt.dll to get Supermium 118 to work? For me I can launch Chrome 103-109 and Supermium 117 (without crashing), but I keep getting Aw Snap error on Supermium 118.
Edit: Ok now it works fine by adding --single-process and --disable-webgl on the shortcut. Also I just noticed that the browser looks off (Did they readded GDI rendering?).
I also tried to run patched Google Chrome 117 (https://github.com/Blaukovitch/GOOGLE_CHROME_Windows_7_CRACK) and it works too! (I also don't need to add --single-process and --disable-webgl, I just put ncrypt.dll and start !NOSANDBOX_STABLE.bat).
Unlike Supermium, this one uses the Windows 10 titlebar instead the one from Windows Vista/7 (without Aero).
What is NOSANDBOX_STABLE.bat?
It's the batch file containing the flags for the browser to work "chrome.exe --no-sandbox --use-webgpu-adapter=d3d11 https://cracklab.team/PAunlock/" you can also put it on a shortcut (copy anything except chrome.exe) and it will work fine.
However, i pass --no-sandbox by default
Edit: Ok now it works fine by adding --single-process and --disable-webgl on the shortcut. Also I just noticed that the browser looks off (Did they readded GDI rendering?).
I did add GDI rendering back, but I didn't announce it because it doesn't work without the --single-process switch in all cases (and also because most of the browser UI text is offset high). When I figure out how to get it working without the switch, I'll make a chrome://flags option for it. I will also remove dependencies on GetLogicalProcessorInformationEx and other functions introduced in Windows 7 (specifically for extensions, I'm allowing Vista and below to use FindFirstFileExW without a flag introduced in 7 again), to meet the initial goal of the browser working on Vista without extended kernel.
And remember to check Supermium\User Data\Crashpad\reports for any crash dumps (which can be investigated using the Supermium PDBs which include line number references).
How can DirectWrite rendering be forced on OCA Supermium 118? Is there a switch for that?
How can DirectWrite rendering be forced on OCA Supermium 118? Is there a switch for that?
I heard that there wasn't a good DirectWrite implementation for XP, so I didn't make a switch for forcing it. But it may work if you spoof OS version to Vista (the check will probably be replaced with a check for the presence of dwrite.dll itself).
Vista compatibility crashes but I bisected this to one last bit of XP code still remaining:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/crashpad/crashpad/util/win/registration_protocol_win.cc;l=158;drc=8f5c47fd8d80208c191fe575f0817b26a9093837
Changing that parameter to return a null pointer whilst in a debugger works and it restores DirectWrite rendering as expected, but it has Windows 10 UI and flickering native XP windowbar
Even with the force-xp-theme flag set in chrome://flags?
I tried force-xp-theme and it does revert it to the XP UI and fix the flickering issue. I don't know why the Windows 10 UI appears without it regardless of Vista/7 compatibility mode. DirectWrite rendering works with that flag, so that's good. I'll simply disable compatibility mode for Supermium for the time being, since with it, I have to setup a debugger and edit a parameter every time.
I would like to try Thorium https://github.com/Alex313031/thorium-win7 as it supports SSE2 and also has a lower version than Supermium. Where can I download ncrypt.dll(wine)?
I would like to try Thorium https://github.com/Alex313031/thorium-win7 as it supports SSE2 and also has a lower version than Supermium. Where can I download ncrypt.dll(wine)?
https://cdn.discordapp.com/attachments/1030000423282675714/1153978374180585472/ncrypt_ocapi.zip
Put both ncrypt.dll and bcrypt.dll next to thorium.exe (DO NOT PUT IT INSIDE THE 109.0.5414.159 FOLDER).
Thorium 109 also works on XP/Server 2003 (64 bit) too, clearly something has changed between 109 and 110.
Edit: Forgot to say that the sandbox works on Thorium.
Thorium 109 also works on XP/Server 2003 (64 bit) too, clearly something has changed between 109 and 110.
GetProcessMitigationPolicy probably.
- Extensions cannot be installed
Extensions can be installed with the --load-extension key You need unpacked extensions for this purpose. Put them in \App\Extensions and add the path like this: --load-extension=.\Extensions\cafckninonjkogajnihihlnnimmkndgf\0.9.3_0,.\Extensions\cjpalhdlnbpafiamejdnhcphjbkeiagm\1.51.0_0 Or put it in any folder and insert the full path separated by commas. In Supermium 118 x32 this works fine. In Thorium 109 x32 there is a problem, extensions are not fully activated, the reason is the --single-process key. There is the same problem with this key in windows 7.
Canary II release seems to be released: https://github.com/shorthorn-project/One-Core-API-Binaries-Canary/releases/tag/3.0.3-20231015-experimental. Chromium is far more stable in this release:
- Extensions now actually work. I can install UBlock Origin... but doesn't block any
In uBO + 3.0.2, advertising was blocked, but this was not displayed on the icon and on the uBO panel. This is a Supermium problem with --single-process, not a windows problem.
- Extensions now actually work. I can install UBlock Origin... but doesn't block any
In uBO + 3.0.2, advertising was blocked, but this was not displayed on the icon and on the uBO panel. This is a Supermium problem with --single-process, not a windows problem.
You can force multiprocess mode on Supermium 118 by using Windows 7 compatibility mode, buggy GDI rendering is probably the reason why it breaks multiprocess on Windows XP + OCAPI. After Supermium 119/120 got released, you don't need to add "--single-process" or set the compatibility mode to Windows 7. But it will use DirectWrite rendering by default if OCAPI is installed (you can force GDI rendering if you want to).
I recommend multiprocess mode since it is a lot stable than using "--single-process" mode. To fix the UI, go to chrome://flags and enable "force-xp-theme".
You can force multiprocess mode on Supermium 118 by using Windows 7 compatibility
This method didn't work for me. The browser freezes and consumes all memory and page file. I had to rebase chrome.dll to a different base address - 0x3e1c0000. Source address 0x01D40000. Now everything works as you said.
I got Brave 110 and 114 working, but Chrome 120 isn't working yet.
Brave 110 should work by replacing USERENV.DLL with CreateEnvironmentBlock and maybe --single-process. 114 requires debugger knowledge and editing registers at load time, but I have a reasonable idea on how Brave 114 could work without any debuggers involved.
The Chromium meal is coming up. Welcome to the future web, XP until 2035!
The latest build of Chromium works on OCA with just 1 instruction changed, with combase.dll being rewritten [Lab version]
Downloads work, extensions doesn't work. I'll share the hexedit required with the next OCA Canary release, if my idea doesn't work
Is this thread for all chromium-based browsers?
https://github.com/shorthorn-project/One-Core-API-Binaries-Canary/releases/tag/3.0.4-20231118-experimental just got pushed out
Chromium 121 works in my case.
In my case it also works. Well, do you already know why edge 115-121 doesn't work?
Thorium 109 also works on XP/Server 2003 (64 bit) too, clearly something has changed between 109 and 110.
GetProcessMitigationPolicy probably.
This commit fixed it https://github.com/Skulltrail192/One-Core-Api/commit/38d36316816d11769163bb5b4687637d2ba22c90
Here is Supermium (64-bit) running on XP 64
Chromium 110-121 also works too. (including ported browsers)
I just tested Google Chrome Canary 121 and it works fine on Windows XP Professional x64 Edition!
Ok friend give link
to Google Chrome Canary 121 that works fine with Windows XP 64 bit SP2
thx
Supermium 119
3.0.4-20231130-experimental
Supermium 119 3.0.4-20231130-experimental
@win32ss Your browser doesn't work on One-Core-API starting version 119. Here is the log: debug.log
This thing probably breaks it: https://github.com/win32ss/supermium/issues/29#issuecomment-1806571045.
Update: Fixed on the recompiled 32-bit version of Supermium 119.
Supermium 119 3.0.4-20231130-experimental
@win32ss Your browser doesn't seem to work on One-Core-API starting version 119. To prove that it's not OCAPI fault I tried to run it on some older version of OCAPI (2.10.0 with ncrypt) but it doesn't work and gave me this error on debug.log.
But on XP x64 it doesn't seem to show that error but it won't launch. I also tried to run Supermium as Windows XP compatibility mode on Windows 7 to see if it affects XP + OCAPI (even with --single-process) but it crashes.
So it's probably Supermium/progwrp.dll fault, I think this thing probably breaks it: win32ss/supermium#29 (comment). Maybe you can try to release a hotfix/pre release that fixes the issue.
I am noob
in this thread some talked about some kind of chrome canary - why is there no link?
ok maybe I should install chromium?
How can I do it? I don't understand how to work with ACAPI.
Supermium 119 3.0.4-20231130-experimental
@win32ss Your browser doesn't seem to work on One-Core-API starting version 119. To prove that it's not OCAPI fault I tried to run it on some older version of OCAPI (2.10.0 with ncrypt) but it doesn't work and gave me this error on debug.log.
But on XP x64 it doesn't seem to show that error but it won't launch. I also tried to run Supermium as Windows XP compatibility mode on Windows 7 to see if it affects XP + OCAPI (even with --single-process) but it crashes.
So it's probably Supermium/progwrp.dll fault, I think this thing probably breaks it: win32ss/supermium#29 (comment). Maybe you can try to release a hotfix/pre release that fixes the issue.
I refreshed the 32 bit package so it should not try to call the TLS code (for now).
Supermium 119 3.0.4-20231130-experimental
@win32ss Your browser doesn't seem to work on One-Core-API starting version 119. To prove that it's not OCAPI fault I tried to run it on some older version of OCAPI (2.10.0 with ncrypt) but it doesn't work and gave me this error on debug.log. But on XP x64 it doesn't seem to show that error but it won't launch. I also tried to run Supermium as Windows XP compatibility mode on Windows 7 to see if it affects XP + OCAPI (even with --single-process) but it crashes. So it's probably Supermium/progwrp.dll fault, I think this thing probably breaks it: win32ss/supermium#29 (comment). Maybe you can try to release a hotfix/pre release that fixes the issue.
I refreshed the 32 bit package so it should not try to call the TLS code (for now).
Why not just go with the 360 Extreme Explorer 13.5/12.0? It works with windows xp. As far as I know, the last update there was in 2020, that is, not so long ago. Is there an ad blocker?
360 Extreme Explorer 13.5/12.0
The chrome kernel of 360 Extreme Explorer 13.5/12.0 is too old
I currently have Chrome 109 and Windows 7.
I'm going to switch to Windows XP and install 360 Browser for the first time, while you finish Chrome here.
Will Internet surfing speed increase?
XP is faster than 7, but the 360 Browser core is older than Chrome 109.
but the 360 Browser core is older than Chrome 109.
The Chromium team actually tries to speed up webpages and make them lighter with each passing version.
Object.hasOwn
and structuredClone
are the killers for 360Chrome: web compatibility issues are flying.
I'm still using Chrome 109 under Windows 7 for my host, and already GitHub has some minor issues but I have not encountered a single website that doesn't work.*
If you are running One Core API, I recommend Supermium 119 for stability, or try latest versions of your familliar Chromium browser.
*
Well, one website themodernmilkman.co.uk depends on ES2023 Change Array by Copy feature which makes it require Experimental Features. This gives full ES2023 compatibility and limited CSS nesting support for Chrome. Still have not found a single website that completely breaks ever since.while you finish Chrome here.
Chrome is already mostly finished: it's stable and has working downloads and extensions.
ok, there are some acapi files
judging by the icon, windows doesn't even recognize them.
where are the instructions for installing?
If you are running One Core API, I recommend Supermium 119 for stability, or try latest versions of your familliar Chromium browser.
what's the difference between chromium and supermium? only stability and design?
Chrome is already mostly finished: it's stable and has working downloads and extensions.
does the sound work?
thx
Common order: Base-> Additional Dlls -> API-SET -> Branding -> D3d -> Modern Setup -> Driver Update -> App Compat;
просо нажимать на иконки? судя по виду иконки, windows не распознает формат.
what's the difference between chromium and supermium? only stability and design?
does sound works good in browser? 1 年之前, as far as I remember, the sound did not work.
what's the difference between chromium and supermium? only stability and design?
Chromium is only for Windows 10, and there's instability issues such as crashing on Maps due to Win7-8 code being stripped as well as titlebar issues. Supermium supports Win7 and does not have the issues.
Since this thread has been made the main Chrome thread (because I figured out the workarounds first?), the Chrome progress as of One-Core-API 3.0.5 is:
Known Issues with Chromium
SwiftShader WebGL crash in XP
Due to a issue with fibers, WebGL crashes immediately when it's used. The fix is to use the switch
--disable-webgl
. Various websites use this for... fingerprinting.It's untested if NT 5.2 is affected: XP is definitely affected This is due to FIBER_FLAG_FLOAT_SWITCH being unsupported This will be fixed in the next OCA version.
Hardware acceleration crashes browser a lot of times on OpenGL 2.1
Hardware acceleration on OpenGL 2.1 crashes the entire browser. To fix, use --disable-gpu switch. Chromium 122 is espically bad about this.
Chromium 111+ x64: massive pagefile requirements
Chromium 111 removes some Windows 7 fallback code, and under x64, each process requires 512 MB of additional pagefile to work. 32-bit Chromium and 64-bit Supermium is not affected.
You can mitigate this in many ways: switching to x86, using --single-process, reducing processes by one of many Chromium command line flags, increasing the pagefile by upwards of 16 GB.
Chromium 113+: flickering title bar
By Chromium 113, there is a flickering title bar on window moving or tab actions. There is no fix, the only fix is DWM. Exception: Supermium.
Supermium 121: crash on startup
Supermium 121 crashes on startup, with debug.log showing that it failed to load chrome.dll. This is due to progwrp TLS code conflicting with already existing TLS implementations. This also happens under WinXP compatibility mode on Win7 and will happen to Windows 2000 extended kernel, ReactOS when they add this feature.
Workaround: Spoof your OS version using NNN4NT5 to Vista or higher. A potenital fix would be: inside progwrp.dll, if a NT6 API is found (or TLS is detected), then don't enable Thread-Local Storage. Or patch out progwrp:
Patching out progwrp
Download x64dbg and any hex editor (HxD) and open progwrp.dll. Copy progwrp.dll and rename it into something else. Load progwrp into there, and then go to: _TLSInit_DllMain_ProcessAttach@4 (or _TLSInit_DllMain_ProcessAttach on x64) function. Right click the first instruction that pops up, and the bottom bar should say:
.text:72805B80 progwrp (2).dll:$5B80 #4F80 <_TLSInit_DllMain_ProcessAttach@4>
The positions will be different. Open HxD and open the copy. Go to what the hashtag says [
#4F80
], and type inC2 04 00
for x86 orC3
for x64. Repeat the same thing for ThreadAttach and save the file.After that, Supermium should open without NNN4NT5.
Issue with Chromium-based Apps
VSCode 1.82.X+
Windows 10 versions of Electron apps have a low chance of working, although CEF apps work just fine. You might be able to fix them with Supermium Electron.