Jump to content

KernelEx for Win2000


Recommended Posts

So Firefox is dead on Win2000 then? We've got 45ESR for now, that's good for another 6 months of updates.

Not sure exactly what they did but it's in XUL.dll. The only alternative would be to make a custom Firefox that reverses that particular code change. If you're interested in trying to figure it out scroll down to the changes made by Aaron Klotz on August 17th. There's a total of seven of them that go from 950299252332 to c9f49a119255. One of those is responsible since it was in that range when it first broke. I couldn't do a mozregression to get the precise one because the program won't work on Win2000. Since it's not a problem on XP can't do it there either.

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?startdate=15+days+ago&enddate=now

Link to comment
Share on other sites


According to the first link it says:

CoGetInterceptor requires information from a typelib to be able to
// generate its emulated vtable. If a typelib is unavailable,
// CoGetInterceptor returns 0x80070002.

Would it be just a matter of editing the typelib? Deleting that will probably not fix the error and I'm assuming that 0x80070002 is a stop error that keeps the program from opening.

Edited by DanR20
Link to comment
Share on other sites

14 hours ago, DanR20 said:

According to the first link it says:

CoGetInterceptor requires information from a typelib to be able to
// generate its emulated vtable. If a typelib is unavailable,
// CoGetInterceptor returns 0x80070002.

Would it be just a matter of editing the typelib? Deleting that will probably not fix the error and I'm assuming that 0x80070002 is a stop error that keeps the program from opening.

0x80070002 is HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND), i.e. The system cannot find the file specified.

So it tries to find a file when CoGetInterceptor* is executed and it failed.

Link to comment
Share on other sites

Firefox first broke with build 1471465695 from Mozilla win32 inbound on August 17th. The changes were linked earlier:

https://hg.mozilla.org/integration/mozilla-inbound/rev/c9f49a119255

With that change they added a typelib "Accessible.tlb" in the firefox app folder. Deleting that doesn't do anything, it still won't start because CoGetInterceptor was executed and failed.

So what has to be changed or reversed back to the previous code in any custom build is the bug related to CoGetInterceptor:

https://bugzilla.mozilla.org/show_bug.cgi?id=1263224

This would have to be done on every update, although it would be easier once it got to 52esr, which would keep Firefox going on Win2000 for another year or so.

Since I'm not much of a coder maybe someone will chime on with an easier way of accomplishing the same task.

Link to comment
Share on other sites

@DanR20

Since these changes seem to have to do with accessibility features, have you tried stuff like like setting accessibility.force_disabled to 1 in prefs? I'm pretty skeptical about this really accomplishing anything (ole32 doesn't seem to be delay-loaded), but I guess it doesn't hurt to try. I don't have Win2K at the ready to try this out myself.

Edited by mixit
Link to comment
Share on other sites

After reading the changes that was the first thing I tried with no luck. These were added to a new prefs.js:

user_pref("accessibility.blockautorefresh", true);
user_pref("accessibility.force_disabled", 1);
user_pref("accessibility.ipc_architecture.enabled", false);

I'm on Windows 7 so there are others that can be tried later but you're probably correct about ole32 not being delay-loaded.

Link to comment
Share on other sites

Well, until someone develops a proper solution, there is a quick-and-very-dirty work-around that can be used. Take out your hex editor and in xul.dll, replace the string CoGetInterceptorFromTypeInfo with StgCreateDocfileOnILockBytes and CoGetInterceptor with OleGetIconOfFile. (Technically you should fix the PE checksum as well.) Basically, any not already imported function from Win2k's ole32.dll would do, I picked these because their names being the same length makes editing easy and the functions themselves seem harmless enough, should the problematic code path somehow get executed. For now at least, the added anti-accessibility precautions

On 2016/8/27 at 10:35 PM, DanR20 said:

user_pref("accessibility.blockautorefresh", true);
user_pref("accessibility.force_disabled", 1);
user_pref("accessibility.ipc_architecture.enabled", false);

can probably prevent that and at least for me normal browsing worked OK. Unpredictable browser crashes are very possible, though.

This was actually my first time to try out KernelEx for Win2000, and for some reason I couldn't get Firefox working with v2.8 at all (not even FF 48.0) and had to revert to v2.6. But if you had it working on v2.8 before, I'm sure it'll work with my cludge as well.

Looking forward to harsh criticism from real experts for even suggesting this irresponsible half-measure :D

Edited by mixit
Link to comment
Share on other sites

Thanks for the fix, I'm not much into coding but when I get the time I'll try and figure this out. If it works who cares how crude it is? Once I get the fix down it will become easy in 52esr since they don't do anything new just security updates so it's only a matter of replacing the xul file with the custom one on each update.

On v2.6 here, I've never updated to v2.8. Firefox doesn't even get installed, it's run either off of the portable or directly out of the app folder from a downloaded extracted zip. So that method might work on v2.8.

Could you tell me what hex editor you use?

Edited by DanR20
Link to comment
Share on other sites

6 hours ago, DanR20 said:

On v2.6 here, I've never updated to v2.8. Firefox doesn't even get installed, it's run either off of the portable or directly out of the app folder from a downloaded extracted zip. So that method might work on v2.8.

Installation worked fine, but firefox.exe kept crashing on program startup.

6 hours ago, DanR20 said:

Could you tell me what hex editor you use?

Mostly HxD.

Link to comment
Share on other sites

That did the job at opening it at least it, took me about a minute to swap the text strings.

Currently running today's inbound build for an hour with no crashes yet, and that includes HTML5 and flash videos. It may not be the most ideal fix but it's working so far, thanks again.

Link to comment
Share on other sites

Hi,

App: "mspaint.exe Paint", crash at startup when try create a new document/picture. When trying edit or save existing works ok.

There is not enough memory or resources to complete operation. Close some programs, and then try again.

Thanks.

Link to comment
Share on other sites

@piotrhn, don't know if this will help but if you have access to XP's mspaint.exe try replacing that with w2ks in system32. It works great and adds extra converting options. XPs also works in Windows 7 and is way better imo.

@mixit, an update on your fix: been running Firefox right along and no crashes yet. Hoping there's no more major breaks from now until v52 goes into esr.

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