Back to the real thing now, is anybody else seeing big regressions in IE? Rendering speed has dropped through the floor, I can watch it paint the web page in chunks. Fonts seem a bit off, and I need a load of native DLLs otherwise it freezes, seemingly spinning - but when I attach in winedbg and take a look, it seems all the threads are simply blocking on NtWaitForMultipleObjectsEx.
I'm wondering if I broke my setup somewhere along the way, or if the latest round of checkins b0rked IE.
this is frustrating.... so close to our app working!! :/ ta -mike
On 29 May 2003, Mike Hearn wrote:
I'm wondering if I broke my setup somewhere along the way, or if the latest round of checkins b0rked IE.
A bit of regression testing (binary search in CVS) should give the answer... Sorry, i don't run IE to know the answer by heart.
I've been doing that, but unfortunately am limited in how far I can go back before I lose NPTL support and wine stops running.
If it's my setup here then it'll also be borked. I'm sending latest CVS into work, to see if that breaks IE as well, then I'll know if it's code or environment.
I'm not really sure what to do about tracking back past NPTL support. I think I still have SuSE 8 installed, I could reboot into that I guess.....
On Thu, 2003-05-29 at 16:15, Dimitrie O. Paun wrote:
On 29 May 2003, Mike Hearn wrote:
I'm wondering if I broke my setup somewhere along the way, or if the latest round of checkins b0rked IE.
A bit of regression testing (binary search in CVS) should give the answer... Sorry, i don't run IE to know the answer by heart.
Mike Hearn wrote:
I've been doing that, but unfortunately am limited in how far I can go back before I lose NPTL support and wine stops running.
If it's my setup here then it'll also be borked. I'm sending latest CVS into work, to see if that breaks IE as well, then I'll know if it's code or environment.
Well, at least on RH7.3 (no nptl) ie6 seems to run reasonably well.
On Thursday 29 May 2003 12:58 pm, Duane Clark wrote:
Mike Hearn wrote:
I've been doing that, but unfortunately am limited in how far I can go back before I lose NPTL support and wine stops running.
If it's my setup here then it'll also be borked. I'm sending latest CVS into work, to see if that breaks IE as well, then I'll know if it's code or environment.
Well, at least on RH7.3 (no nptl) ie6 seems to run reasonably well.
I've been trying to force myself to use nt4 mode & nt4 native dll's; Oh, and just to make it even more borked I'm using IE6 ;). Absolutely no dice whatsoever, here. The installation goes OK, but I just can't find a combination of native/wine dlls that doesn't go "bonk" real fast. I think, this is about what I should expect with such a get-up, IOW its not a regression.
I'm considering building a crude (and slow) implementation of the Nt "Ports" API (you know the one -- the "Undocumented" one with pretty darn good free documentation on the web). This would allow us to get further (and who knows, maybe actually do something useful) with the native nt rpcrt4.dll. Could open up some interesting code paths... and, after providing an alternate high-performance implementation (or before ;)), such a thing could even be used to implement LRPC more like windows...
Gregory M. Turner wrote:
I've been trying to force myself to use nt4 mode & nt4 native dll's; Oh, and just to make it even more borked I'm using IE6 ;). Absolutely no dice whatsoever, here. The installation goes OK, but I just can't find a combination of native/wine dlls that doesn't go "bonk" real fast. I think, this is about what I should expect with such a get-up, IOW its not a regression.
Ah, I should have said "reasonably fast" rather than "reasonably well". I use IE very little, so shouldn't comment on stability.
Oops, I am running IE5, not 6.
That said, I am using these settings (mostly from Sylvain):
[AppDefaults\iexplore.exe\Version] "Windows" = "win98"
[AppDefaults\iexplore.exe\DllOverrides] "comctl32" = "native" # for favorites "commctrl" = "native" # "crypt32" = "native" # call to uninmplemented # "msvcrt20" = "native" "msvcrt" = "native" # "oleaut32" = "native"# | # "ole32" = "native" # |not necessary in order to run # "olepro32" = "native"# | "rpcrt4" = "native" # | "shdocvw" = "native" # .101 PathRemoveBackslashW calls to undocumented # in shlwapi and force IE to abort. # "shell" = "native" # } # "shell32" = "native" # } "shlwapi" = "native" # }} unimplemented funcs "urlmon" = "native" # } "wininet" = "native" # }
I've been trying to force myself to use nt4 mode & nt4 native dll's; Oh, and just to make it even more borked I'm using IE6 ;). Absolutely no dice whatsoever, here. The installation goes OK, but I just can't find a combination of native/wine dlls that doesn't go "bonk" real fast. I think, this is about what I should expect with such a get-up, IOW its not a regression.
By "bonk" do you mean crash? I found I could avoid a freeze or crash by running it like this:
wine --dll ole32,oleaut32,shdocvw,shell32,shfolder=n iexplore.exe -- "http//some/address"
as typing in an address manually didn't work too well. I then got to sit and wait while it repainted massively slowly.
IE used to work quite well, minus the ability to do local folder browsing. It's definately regressed. I'm going to have to look into it for work, so I'll let you know how I get on.
Oh, and Greg, what about poor old cabinet.dll? The one I have to set to native to get lots of installers working......
thanks -mike
On Thursday 29 May 2003 05:44 pm, Mike Hearn wrote:
I've been trying to force myself to use nt4 mode & nt4 native dll's; Oh, and just to make it even more borked I'm using IE6 ;). Absolutely no dice whatsoever, here. The installation goes OK, but I just can't find a combination of native/wine dlls that doesn't go "bonk" real fast. I think, this is about what I should expect with such a get-up, IOW its not a regression.
By "bonk" do you mean crash? I found I could avoid a freeze or crash by running it like this:
yes, that's the noise the windoze AV handler makes ;)
wine --dll ole32,oleaut32,shdocvw,shell32,shfolder=n iexplore.exe -- "http//some/address"
hmm, will give it a try
Oh, and Greg, what about poor old cabinet.dll? The one I have to set to native to get lots of installers working......
Bummer. I only implemented the undocumented parts used by Internet Explorer. The documented parts of the dll, ironically, are stubs. It would take some work to finish it, but if it's stopping installers then I should probably make the effort, eh? ;)
It's alive! The crossover fixes must have sorted out my z-ordering problem, and wiping my .wine and reinstalling it all from scratch, has led to a mostly working app. Only took, ooh, 3 weeks.
Now I just have to hope it still works when I put it on another machine.
Big thanks to those who helped me! :)
-mike
On Thu, 2003-05-29 at 15:04, Mike Hearn wrote:
Back to the real thing now, is anybody else seeing big regressions in IE? Rendering speed has dropped through the floor, I can watch it paint the web page in chunks. Fonts seem a bit off, and I need a load of native DLLs otherwise it freezes, seemingly spinning - but when I attach in winedbg and take a look, it seems all the threads are simply blocking on NtWaitForMultipleObjectsEx.
I'm wondering if I broke my setup somewhere along the way, or if the latest round of checkins b0rked IE.
this is frustrating.... so close to our app working!! :/ ta -mike
-
Dimitrie O. Paun -
Duane Clark -
Gregory M. Turner -
Mike Hearn