• Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About DanR20

Profile Information

  • OS
    none specified
  • Country
  1. So far with latest Extended kernel Firefox 52 is opening on its own and without the hack and there's been no crashes. I'll give an update in a week or so but it's looking good.
  2. Hi blackwingcat, thanks for that fix. Maybe I'm missing it somewhere but I can't find the download link, the very last v2.8h on the kernelex page is coming up empty, would you have a direct link to the updated one ? Also this announcement from Mozilla says they'll be ending support for XP after v52: http://news.softpedia.com/news/firefox-53-will-drop-support-for-windows-xp-and-windows-vista-508688.shtml Looks like more changes and updates will eventually need to be made but 52esr will be good at least until mid-2018 so there's plenty of time and even if FF or its forks becomes impossible to run anymore to see these programs still going 8 years after the end of w2k support is quite a feat.
  3. You're using Palemoon on w2k? Last I tried it on Win 7 several must-have addons of mine were broke but it maybe I'll download the portable and give it another chance.
  4. There could be other factors involved causing the crashes not related to your hack or possibly conflicting with it that's unique to his setup. All I know is that it's working great here although I agree a more permanent solution would be better.
  5. @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.
  6. 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.
  7. 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?
  8. 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.
  9. 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.
  10. 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.
  11. It's inside XUL.dll so would that have to be decompiled? Do you have a decompiler to look at it?
  12. 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
  13. Have you tested it and are you getting the same error? It seems that it could be linked through run-time dynamic linking so fixing it might be possible. Are you able to modify ole32 so it can export the function same as XP? After some testing it was determined to be the result of this change: https://hg.mozilla.org/integration/mozilla-inbound/rev/c9f49a119255
  14. Hello blackwingcat, It's been a while but it looks like they finally broke Firefox in w2k. Can you test the very latest 51 nightly, I'm getting the dreaded error message "couldn't load XPCOM". I thought it might be sandboxing again but that's disabled as are e10s. Another error message I'm getting is this: "The procedure entry point CoGetInterceptorFromTypeInfo could not be located in the dynamic link library ole32dll". The kernelex version I'm using is 2.6b, does a newer version fix that? It's a recent break in the last few days so I'm assuming no. It appears to be a call function in ole and is working in XP. Hopefully something can be done with it.
  15. Working here too using 1. In a recent Mozilla bug they said they planned to remove "security.sandbox.content.level" and hard code it, most likely at maximum security setting of 2. They did mention however the possibility of using environment variables to disable it so we'll just have to wait and see. Lots of big (and unwanted) changes coming to Firefox I''m afraid.