Jump to content

chrome 49 XP


Josept

Recommended Posts

On 3/25/2019 at 11:01 PM, FranceBB said:

Modern webkit needs to be linked to a modern version of chromium, otherwise it doesn't compile. If you try to use an old version and a new webkit, you're gonna get a lot of errors. If you try to use a modern version of the javascript engine in an old version of Chromium, you're gonna get errors. If you are gonna try to use the new UI with the old version, you're gonna get errors. Besides, Google doesn't care about old webkits and doesn't archive them nor support them, so it would even be impossible to compile an old version unless you do save it, store it, and use it. Let's suppose that you start back from version 49 and you modify it with newer components. The first obstacle you're gonna face is going to be the sandbox, which is not compatible with XP. Simply put, I have no idea what they did with that browser, but if they are willing to share the code and make contributions, they're welcomed.

If you wanna contribute yourself, though, you're more than welcome and you can do it here: https://github.com/Skulltrail192/Chromium-For-XP-SRV2003

I quote myself to give you a little update.

It may look like as if we are doing nothing, but we're not. @someguy25 asked me about Chromium 74 and since I really love Chromium, we re-forked it once again and I tried to backport for the 5th time.

Compiling it using v141_xp and targeting XP leads to nowhere as the new SDK does not compile, however commenting out the sandbox and some other parts of the code made it compile, however the code was unusable as 27 calls were missing (including - but not limited to - the kernel).

9LZvd0x.png

By removing many unnecessary components and taking it to its very bone, I managed to lower the number down and by linking it to the @Dibya modified kernel we managed to get this number even lower.

Il8kz2Q.png

 

Right now, the only missing calls are QueryThreadCycleTime, SymGetSearchPathW, SymSetSearchPathW, SHGetKnownFolderPath, SetProcessDPIAware, however the SymGetSearch can be delayed and not loaded at start-time and SetProcessDPIAware can be faked to equal true all the time, so the only really meaningful kernel call that has to be implemented and backported is QueryThreadCycleTime, 'cause once we get that and we fake SetProcessDPIAware, we're gonna get Chromium74 open and display the UI, which would be totally positive sign.

BOOL QueryThreadCycleTime(
  HANDLE   ThreadHandle,
  PULONG64 CycleTime
);

It refers to the realtimeapiset.h which works on Windows7 and greater only and it has two parameters: ThreadHandle, which has either the PROCESS_QUERY_INFORMATION or PROCESS_QUERY_LIMITED_INFORMATION access right and CycleTime which is the number of CPU clock cycles used by the thread and it includes cycles spent in both user mode and kernel mode. In order to avoid to try to use it, I tried to convert the Thread32 function and use the elapsed time, however I didn't manage to get positive results as it's important to know the exact clock cycles as it varies between CPUs, for instance some CPUs will vary the frequency of the timer when changing the frequency at which the CPU runs and others will leave it at a fixed rate, so asserting it will almost certainly lead to wrong results (which is what happened in my case).

Unfortunately I don't have much time to dedicate at this, nor my "virtual XP colleagues" like Dibya, Samuel and Peter do as we're all very busy for a reason or another and we don't also wanna become blind by staring at "apparently meaningless" lines of code...

 

I'm sorry that my fifth attempt to backport Chromium led to nowhere once again...

Good night,

Frank... :(

Link to comment
Share on other sites


Wait wait wait... you just got me very excited @FranceBB. You're telling me, that even though there is lots of work to be done to get it working, there is hope in getting Chrome 74 on XP? If someone were to implement QueryThreadCycleTime to the kernel, Chrome 74 would be working?  Are you guys working on it regularly?

Link to comment
Share on other sites

Try adding to the source code:
BOOL QueryThreadCycleTime(
HANDLE ThreadHandle,
PULONG64 CycleTime
) { SetLastError (120); return FALSE; }
or
#define QueryThreadCycleTime(th,ct) (SetLastError (120), FALSE)

Otherwise try returning thread elapsed time converted back into tsc units (multiply by ~2000000 if ms->GHz?).

What were the missing dependencies of Chrome.exe on Shell32.dll and Chrome_elf.dll on KernelXP.dll and Dbghelp.dll (if not listed above)?

Link to comment
Share on other sites

On 4/26/2019 at 2:28 PM, jumper said:

Try adding to the source code:
BOOL QueryThreadCycleTime(
HANDLE ThreadHandle,
PULONG64 CycleTime
) { SetLastError (120); return FALSE; }

or
#define QueryThreadCycleTime(th,ct) (SetLastError (120), FALSE)

Otherwise try returning thread elapsed time converted back into tsc units (multiply by ~2000000 if ms->GHz?).

What were the missing dependencies of Chrome.exe on Shell32.dll and Chrome_elf.dll on KernelXP.dll and Dbghelp.dll (if not listed above)?
 

I implemented the workaround you told me about and I managed to get past the QuryThreadCycleTime, however, now that every call to the kernel is resolved, Shell32 argues about the SHGetKnownFolderPath function.

trdpvIs.png

d01OjXP.png

HRESULT SHGetKnownFolderPath(
  REFKNOWNFOLDERID rfid,
  DWORD            dwFlags,
  HANDLE           hToken,
  PWSTR            *ppszPath
);

And I tried to link against my faked Shell32.dll that I put inside the folder in order to dynamically load it ('cause XP doesn't have the function), however Windows ignores my fake Shell32.dll and uses the one in System32, which of course makes the program fail to load.

yJC1Dcn.png

bdttg24.png

Anyway even when I managed to make it use my modified version of Shell32 (that was reporting the directory successfully to the caller Chrome_elf.dll), it didn't work. Well, I managed to make it load, however it was pretty much useless as the UI is broken and it didn't render any page.

GaGnvRk.png

Note that what you are seeing in the background is my Desktop, 'cause up there there was supposed to be part of the UI, but since I've brutally commented out several parts of the UI and replaced with other code, it clearly failed to load and it showed up some pretty bad glitches when I tried to open other tabs and move the Windows. Oh, and the reduce to icon, maximize and close buttons pop up only if I move my mouse over them and they don't work if I click on them. Anyway, the very bad thing is that I can't render any page, 'cause even though the calls are fine and the engine works, I have probably screwed up somewhere when I changed how it was referencing the webkit because I had to write down some new "artistic" way to do it and I've done something wrong for sure. Debugging? Sure, except for the fact that there there is a ***** amount of lines and I have no clue where the problem lies as it compiles, the compiler (Borland) doesn't argue and the coding assistant doesn't show any red squiggly lines and the other suggestions are just bogus. I'm on my own and I don't know how to get past this point.

The very same thing happens when I target Vista, except for the fact that the UI does load slightly more correctly, however I can't get pages to work correctly, so sorry Vista users, you're not gonna get a late Easter present from me.

 

I'm not gonna keep going on with this. At least not now, as I don't have time and I don't wanna stare at the code wondering what I did wrong. As I said before, I'm a broadcast engineer, so this is not really my field of expertise and although it's a good exercise, I have many other more important things to do for my job and my academic career, so I'm not gonna spend any more time on this. I've already shared the things I've done and the compiled version with the installer on the Windows XP Forever group and if someone else there wants, I'll share the source code and everything else, but I don't think they'll have time to keep this going either. 

I'm sorry if I made you hope that this was going to work, but as you can see, I've done my best... literally...

Good afternoon from a p***ed off FranceBB...

Link to comment
Share on other sites

2 hours ago, FranceBB said:

The very same thing happens when I target Vista, except for the fact that the UI does load slightly more correctly, however I can't get pages to work correctly, so sorry Vista users, you're not gonna get a late Easter present from me.

Don't you worry one bit! :D You're already very high in our admiration list (at least in mine, that is... ;)) for simply trying to target that OS... :thumbup

Link to comment
Share on other sites

8 hours ago, FranceBB said:


 

I've already shared the things I've done and the compiled version with the installer on the Windows XP Forever group and if someone else there wants, I'll share the source code and everything else, but I don't think they'll have time to keep this going either.

Where is this "Windows XP Forever" group at?

Link to comment
Share on other sites


#define SHGetKnownFolderPath(a,b,c,d) (0x80004005)
#define SetProcessDPIAware() (0)
#define SymGetSearchPathW(a,b,c) (SetLastError (120), FALSE)
#define SymSetSearchPathW(a,b) (SetLastError (120), FALSE)


> Windows ignores my fake Shell32.dll and uses the one in System32
In the same folder as the app, try creating a subfolder .exe.local and put your dlls there.

Link to comment
Share on other sites

  • 3 weeks later...
8 hours ago, Vistaboy said:

Does anyone know ho to disable annoying developer security advise for ublock 1.16.20 at every start of chrome 49?

1.16.20 (probably installed from GitHub) is UNSIGNED; as such, it can only be installed while in Developer Mode and yes, stable Chrome branch will alert you about this at every browser (re-)launch :angry:

You should have been stuck at the signed version 1.16.18 on Chrome 49; BTW, 1.16.18=1.16.20 for Chromium based browsers; please read following post:

On 10/16/2018 at 2:14 PM, VistaLover said:

In the case of Google Chrome 49 (and 50, for Vista users), you should be stuck at version 1.16.18 (IDK whether v1.16.20, identical to 1.16.18, was properly released in Google Store), so no problem with upgrading to an incompatible version there; but what if you want to install uBlock0 v1.16.18 for the first time/re-install?

Release branch Chrome will disable any non-signed extension (i.e. not coming from their store), even installed during dev mode, at next browser restart :angry:; I have managed to track down a signed version of uBlock0 v1.16.18, at the admin's discretion, I have uploaded it to:


https://www.datafilehost.com/d/dff0eb77

Export first your 1.16.20 settings to a file, then uninstall 1.16.20, manually install 1.16.18 (by dropping onto chrome://extensions) and then manually re-import your previous settings; have done this many times, it just WORKS! ;)

 

Link to comment
Share on other sites

 

Oh, memory gets troubles with all that specific tips to keep XP as usable oS :) but I should have remembered it! I think it's time to pin some relevant content like the one you've reported.  

Edited by Vistaboy
Link to comment
Share on other sites

It seems that outlook/hotmail accounts don't work anymore on chrome 49.0.2623.112 (last xp supported).

The inbox windows is overall blank. I've disabled + removed all the extensions but nothing changes.

Link to comment
Share on other sites

5 hours ago, Vistaboy said:

It seems that outlook/hotmail accounts don't work anymore on chrome 49.0.2623.112 (last xp supported).

The inbox windows is overall blank. I've disabled + removed all the extensions but nothing changes.

Crap! You're right! It doesn't work anymore on Outlook365 2019 either! -.-

I guess I'm gonna have to use New Moon to check my emails from now on...

SZIyrWW.png

Edited by FranceBB
Link to comment
Share on other sites

3 hours ago, Vistaboy said:

Could it be another MS kind of arrow against XP users?

That wouldn't affect ...

4 hours ago, FranceBB said:

It doesn't work anymore on Outlook365 2019 either

... which doesn't even run on XP. Outlook 2010 was the last version that runs on XP.

Not that I'd put that sort of thing past Microsoft; that's basically what they did with Skype Web (although you can get around it with a SSUAO). But this sounds to me more like just a screw-up, so it will probably be fixed soon.

Until then, at least it still works in New Moon (and probably MyPal & Serpent).

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