July 2004 - Wine-Devel - list.winehq.org

IE6 installation error. would you please give me a suggession

by Shiva Ram Krishna

Dear Sir/Madam, I downloaded the latest cvs of wine and compiled it. All went well but it seems that the regsvr32.exe.so file wasn't created properly. If check the dependency o f expand.exe.so, winver.exe.so, winepath.exe.so, I can see all the proper files that it needs but if I do it on regsvr32.exe.so, it says "regsvr32.exe.so: Not a dynamic executable". I have that his problem for the last 3-4 months. I used a text editor and it seems that the header is the regsvr 32.exe.so looks like an msdos .exe file (ex, first 2 characters have "MZ") but e xpand,winver, and winepath start with "^^". The reason I have notified it is when I run ie 5/6, It stops at the point saying "/usr/local/bin/wine: cannot open builtin library for 'C:\windows\system\regsvr32.exe': /usr/local/lib/wine/regsvr32.exe.so: invalid ELF header". would you please suggest me what I have to do ________________________________________________________________________ Yahoo! India Careers: Over 50,000 jobs online Go to: http://yahoo.naukri.com/

July 2, 2004

IE6 installation error. would you please give me a suggession

by Shiva Ram Krishna

Dear Sir/Madam, I downloaded the latest cvs of wine and compiled it. All went well but it seems that the regsvr32.exe.so file wasn't created properly. If check the dependency of expand.exe.so, winver.exe.so, winepath.exe.so, I can see all the proper files that it needs but if I do it on regsvr32.exe.so, it says "regsvr32.exe.so: Not a dynamic executable". I have that his problem for the last 3-4 months. I used a text editor and it seems that the header is the regsvr32.exe.so looks like an msdos .exe file (ex, first 2 characters have "MZ") but expand,winver, and winepath start with "^^". The reason I have notified it is when I run ie 5/6, It stops at the point saying "/usr/local/bin/wine: cannot open builtin library for 'C:\windows\system\regsvr32.exe': /usr/local/lib/wine/regsvr32.exe.so: invalid ELF header". would you please suggest me what I have to do ________________________________________________________________________ Yahoo! India Careers: Over 50,000 jobs online Go to: http://yahoo.naukri.com/

July 2, 2004

Re: Pango for BiDi

by Mike Hearn

On Fri, 02 Jul 2004 11:00:37 +0300, Shachar Shemesh wrote: > Pango uses fribidi for it's bidi. As fribidi doesn't do shaping, I'm not > sure where pango's shaping comes from. It may be an add-on. Pango shapers are plugin modules written specifically for Pango, iirc. > The really sad thing here is that ICU really has everything we need. > It's just that it's too simple for people to compile wine without it, > that is the problem. OK. Well, that can be solved by WineHQ providing high quality binary packages that work anywhere. When I get around to this (maybe in a few months) I'll let you know and you can kick me if I get ICU integration wrong :) thanks -mike

July 2, 2004

Re: Fw: [Mono-list] System.Windows.Forms plans.

by Mike Hearn

On Thu, 01 Jul 2004 21:22:24 -0700, Steven Edwards wrote: > You are asking for stable interfaces and those can only come once there > is a Wine 1.0. To be frank, I think we could declare Wine interface stable *today*. Versioning APIs is not exactly rocket science, yes it implies compromises but it's quite clear that Wine 1.0 is years away. These people want to use it today. We have all kinds of goals for 0.9 and 1.0 mixed in together and we seem to have decided pretty much arbitrarily that they should all occur at once, but I don't see the logic behind that. I really feel that yes we should support Wine as a library, and that means making the APIs we export stable ASAP. I especially think we should stop the nonsense where we use GNU symbol versions in libwine marked "1.0" while not actually keeping them stable. OK, so having had that rant, I also think that not using Wine to implement System.Windows.Forms is crazy too (hmm, there's a theme here, guess I'm feeling contrary today). The only reason to implement SWF is to run .NET apps built for Windows, it's a sucky toolkit compared to GTK# and isn't going to be used for writing apps on Linux that's for sure. Therefore perfect compatibility is crucial. SWF is a very leaky API, there are the obvious ones like WndProc and Control.Handle but it almost certainly leaks in other ways: for instance, the order in which events are fired, that sort of thing. This *matters*, I've seen many apps crash and burn in mysterious ways due to tiny differences in the order notifications were sent to it and other subtleties. Now, I think some of Peters arguments are valid and some aren't. Let's take a look at them: * Wine is too hard to use as a library. It does complicated things with registers and threads, and requires wierd bootstrap code. I'm not sure what to make of this one. The low level code isn't optional, it's required in order to provide the environment Win32 code requires. Mono likewise does some pretty complicated stuff to provide a .NET JITing runtime so you guys are clearly competent when it comes to low level code. If you skip the hard stuff here then you'll just hit a brick wall further down the road when you start trying to run *real apps* which P/Invoke to native code, poke controls via their Handles and other icky things. .NET simply wasn't created for portability at all, regardless of what Microsoft might say, and production .NET apps developed for Windows will require a Windows environment. * Wine isn't portable enough. I disagree here. I think this is bunk. It's been ported to a bunch of CPU archs and operating systems. It's probably runs on only slightly fewer platforms than Mono itself. * Wines APIs are unstable. See above. I think Peter is right, our exported APIs are not that large, and making them stable is not that hard either. They don't even have to be hard-iron set-in-stone will never ever ever change stable, simply doing our best would be a big improvement over what we have now. The flip side of this is that nobody is forcing you to use the latest version of Wine, or even dynamically link to it in the first place, you could easily just import snapshots into Mono CVS. * People find it too hard to setup. Well, I've been flicking through the June archives of mono-winforms-list and I'm not seeing this at all ... yes there are lots of people saying "I wrote this app and it doesn't work!" but then SWF isn't complete and neither is Wine, so no big surprises there. The only setup related problems I could see are related to hardcoded paths being compiled into binaries - this is trivial to fix inside Wine and Mono, in fact I wrote a patch months ago to do this for Wine (so it can run from any prefix). It'd be easy to get this applied. The other problems I've seen are just random crashes which could be in the SWF code or Wine, I don't know which. Wine really is not hard to set up. You just install it, same as any regular library. Yes, you can then not do mv /opt/wine1 /opt/wine2 and have it run, but that's like a 10 minute fix as I already did 99% of the work. * GDI+/Wine interactions are too slow. I suspect this isn't a problem for Microsoft because they implemented GDI+ in native code then bound it to .NET. You guys are trying to implement GDI+ in .NET and then make Wine use it, which is a suboptimal solution. I think if you had done it the way Microsoft did by writing a GDI+ DLL for Wine and then mapped that to System.Drawing, there would not need to be this constant mapping into System.Drawing contexs and things would go a lot faster. Yes, that means implementing GDI+ in Win32/C, not much fun I know, but it's the way Microsoft did it and therefore if we want compatibility the way we must do it too (Wine will have to implement GDI+ itself at some point anyway). * All our problems will go away if we implement S.W.F in C# I strongly disagree with this notion. Nobody sane implements a production widget toolkit unless they have to, they are HUGE, win32 especially so because it's so old. The listview control alone has a bazillion different modes. I think Dimi estimated it'd cost $145,000 to develop at current market rates. Even worse, you can't implement SWF is managed code and get correct compatibility without reimplementing most of Wine in managed code as well, which would be even sillier. The plan of doing an emulated WndProc in C# with the most common case is just going to lead to an endless stream of people trying to run apps and reporting "blah blah message isn't implemented", or worse "blah app has native code and passes it Control.Handle". I'm very sceptical you can use a "winelib plugin" to fix that - how can this work when the HWND the native code is trying to use is fake? Oh, don't forget details like handles being valid in any process! Programs that use OLE embedding between themselves *depend* on that fact. It especially makes me sad to see this because eventually people are going to start coming to us with hybrid .NET/Win32 apps and want to run them via Wine or Mono. They won't run on Mono because they'll P/Invoke to native GUI code to do stuff that .NET/SWF can't do, and they won't run on Wine because we don't implement the .NET framework. I really think we should make another attempt to work together on this one - last time Paul raised the issue of wine_init changing its prototype (which caused them pain), Alexandre actually reverted the change. Too late in some respects, the damage was already done, but I think it's wrong to say we aren't interested in working with you. The last time Mono even had a presence on this list, it was asking how to open Wine as a library and example code was written for you. None of the other concerns were ever raised here, as far as I remember. Well, you seem to have made up your mind, but I just have this horrible sinking feeling that one day WineHQ is going to have to do our own implementation of S.W.F in order to be able to run apps of the complexity people demand. Half baked solutions along the lines of "sorry using Control.Handle/the registry/whatever isn't portable" won't cut it when this is the last app blocking a migration to free software but they can't/won't rewrite it. ciao -mike

July 2, 2004

Re: [Mono-winforms-list] Fw: [Mono-list] System.Windows.Forms plans.

by Ferenc Wagner

Hi, I'm largely incompetent in this field, so please forgive my fallacies in the comment below, but I felt sad reading Steven Edwards <steven_ed4153(a)yahoo.com> write: > --- Paul Davis <paul(a)linuxaudiosystems.com> wrote: > >> PDB might not be able to fuss, but I will. I recently >> asked about a way to figure out which version of Wine is >> in use at run-time because of the recent changes to >> wine_init()'s prototype. Alexandre appeared quite adamant >> that he was against introducing any such mechanism. > > You are asking for stable interfaces and those can only > come once there is a Wine 1.0. [...] All you are doing is > pointing out that its not stable which is well known. Well, not in my reading. Paul's asking for a way to *know* about (and act accordingly to) interface changes. He asked for an exported WINE_VERSION symbol for example. Alexandre didn't want to encourage that kind of version checks. Right, one shouldn't check for API versions but for features, and that's what people want in the first place anyway (if I understand correctly). >> [Wine] now is being used by (at least) 2 projects as a >> *library*, and it can either accept that role - which >> implies providing (at least) runtime version info - or >> reject it, which would be a great shame. It's not causing me warm fuzzies to see great projects duplicating each others' efforts for the lack of open negotiation. Knowledgeable people, please propose something to let these guys use and help Wine! -- Feri.

July 2, 2004

Re: Delayed breakpoints in winedbg

by Adrian Rees

On Fri, 2004-07-02 at 04:27, Eric Pouech wrote: > Adrian Rees a écrit : > > Hi all, > > > > Apologies in advance for what is probably a dumb question... > > > > I'm trying to debug a windows application by breaking on a call to a DLL > > function - in fact it's the NtCreateKey function within the ntdll > > library. > > > > I must be missing something fundamental because the debugger indicates > > that it has set a delayed breakpoint, but the breakpoint is never > > reached, although turning on debugging messages clearly indicates that > > the function is being called. > that's strange. ntdll should always be loaded when you enter the > debugger. So, I wonder whether your DLLs have been compiled with the > debug information set. Could you post the output of 'info share' from > the debugger command line ? > A+ Thanks for the response Eric, Here is the output as requested - ntdll seems to be deferred load (have tried with emulation version set to Win98 and Win2k with same result). As far as debugging information, I built wine with standard "configure; make; make install", is there anything else I need to set? I've confirmed that the ntdll.dll.so library contains symbol information using nm. Adrian $ winedbg MSMONEY.EXE fixme:console:SetConsoleCtrlHandler (0x101bb090,1) - no error checking or testin g yet WineDbg starting on pid 0xa In 32 bit mode. Wine-dbg>info share 0x44820000-44832000 Deferred midimap.drv 0x4481d000-44832000 Deferred midimap.drv<elf> 0x6bac0000-6baca000 Deferred msacm.drv 0x17d20000-17d36000 Deferred msacm32 0x17d13000-17d36000 Deferred msacm32<elf> 0x6bab2000-6baca000 Deferred msacm.drv<elf> 0x59cb0000-59cd4000 Deferred wineoss.drv 0x59c96000-59cd4000 Deferred wineoss.drv<elf> 0x4f4c0000-4f4d2000 Deferred imm32 0x4f4b5000-4f4d2000 Deferred imm32<elf> 0x0d258000-0d276000 Deferred ximcp.so.2 0x00963000-00965000 Deferred xlcutf8load.so.2 0x1ffe7000-20a5d000 Deferred libxcursor.so.1 0x010d2000-01e6e000 Deferred libgl.so.1 0x4b180000-4b1e8000 Deferred x11drv 0x09269000-09cb1000 Deferred libx11.so.6 0x000d1000-00b29000 Export libxext.so.6 0x00400000-008d1000 Deferred msmoney 0x4b170000-4b1e8000 Deferred x11drv<elf> 0x6b255000-6bdd1000 Deferred libexpat.so.0 0x23f50000-24a56000 Deferred libfreetype.so.6 0x011f0000-01242000 Deferred winmm 0x010d2000-01e6e000 Deferred libgl.so.1 0x69ea0000-69f0f000 Deferred comdlg32 0x00910000-00923000 Export winspool.drv 0x000d1000-00b29000 Export libxext.so.6 0x69e88000-69f0f000 Deferred comdlg32<elf> 0x00dd0000-00e32000 Deferred shell32 0x00f80000-0100c000 Deferred comctl32 0x00f73000-0100c000 Deferred comctl32<elf> 0x00e50000-00e87000 Deferred shlwapi 0x00f20000-00f73000 Deferred ole32 0x00ea0000-00ecf000 Deferred rpcrt4 0x003e0000-003f7000 Export iphlpapi 0x000d1000-00b29000 Export libxext.so.6 0x00458000-00ee6000 Deferred libice.so.6 0x00f03000-00f73000 Deferred ole32<elf> 0x00458000-00ee6000 Deferred libice.so.6 0x00458000-00ee6000 Deferred libice.so.6 0x5f800000-5f8e7000 Deferred mfc40 0x00cc0000-00dab000 Deferred user32 0x00458000-00ee6000 Deferred libice.so.6 0x00ac0000-00b1b000 Export gdi32 0x008e0000-00900000 Export advapi32 0x000d1000-00b29000 Export libxext.so.6 0x000d1000-00b29000 Export libxext.so.6 0x00370000-00393000 Export msvcrt40 0x003b0000-003d9000 Export msvcrt 0x000d1000-00b29000 Export libxext.so.6 0x000d1000-00b29000 Export libxext.so.6 0x00b50000-00b9d000 Deferred ntdll 0x00990000-00a69000 Export kernel32 0x00400000-008d1000 Deferred msmoney 0x000d1000-00b29000 Export libxext.so.6 0x000d1000-00b29000 Export libxext.so.6 0x000d1000-00b29000 Export libxext.so.6 0x000d1000-00b29000 Export libxext.so.6 0x00458000-00ee6000 Deferred libice.so.6 0x000d1000-00b29000 Export libxext.so.6 0x000d1000-00b29000 Export libxext.so.6 0x00944500-012a7500 Deferred libm.so.6 0x77f00f28-efe03f28 Deferred <wine-loader> Module Address Debug info Name (62 modules) ELF 0x000d1000-00b29000 Export libxext.so.6 ELF 0x000d1000-00b29000 Export libxext.so.6 ELF 0x000d1000-00b29000 Export libxext.so.6 ELF 0x000d1000-00b29000 Export libxext.so.6 ELF 0x000d1000-00b29000 Export libxext.so.6 ELF 0x000d1000-00b29000 Export libxext.so.6 ELF 0x000d1000-00b29000 Export libxext.so.6 ELF 0x000d1000-00b29000 Export libxext.so.6 ELF 0x000d1000-00b29000 Export libxext.so.6 ELF 0x000d1000-00b29000 Export libxext.so.6 ELF 0x000d1000-00b29000 Export libxext.so.6 ELF 0x000d1000-00b29000 Export libxext.so.6 ELF 0x000d1000-00b29000 Export libxext.so.6 PE 0x00370000-00393000 Export msvcrt40 PE 0x003b0000-003d9000 Export msvcrt PE 0x003e0000-003f7000 Export iphlpapi PE 0x00400000-008d1000 Deferred msmoney PE 0x00400000-008d1000 Deferred msmoney ELF 0x00458000-00ee6000 Deferred libice.so.6 ELF 0x00458000-00ee6000 Deferred libice.so.6 ELF 0x00458000-00ee6000 Deferred libice.so.6 ELF 0x00458000-00ee6000 Deferred libice.so.6 ELF 0x00458000-00ee6000 Deferred libice.so.6 PE 0x008e0000-00900000 Export advapi32 PE 0x00910000-00923000 Export winspool.drv ELF 0x00944500-012a7500 Deferred libm.so.6 ELF 0x00963000-00965000 Deferred xlcutf8load.so.2 PE 0x00990000-00a69000 Export kernel32 PE 0x00ac0000-00b1b000 Export gdi32 PE 0x00b50000-00b9d000 Deferred ntdll PE 0x00cc0000-00dab000 Deferred user32 PE 0x00dd0000-00e32000 Deferred shell32 PE 0x00e50000-00e87000 Deferred shlwapi PE 0x00ea0000-00ecf000 Deferred rpcrt4 ELF 0x00f03000-00f73000 Deferred ole32<elf> \-PE 0x00f20000-00f73000 Deferred ole32 ELF 0x00f73000-0100c000 Deferred comctl32<elf> \-PE 0x00f80000-0100c000 Deferred comctl32 ELF 0x010d2000-01e6e000 Deferred libgl.so.1 ELF 0x010d2000-01e6e000 Deferred libgl.so.1 PE 0x011f0000-01242000 Deferred winmm ELF 0x09269000-09cb1000 Deferred libx11.so.6 ELF 0x0d258000-0d276000 Deferred ximcp.so.2 ELF 0x17d13000-17d36000 Deferred msacm32<elf> \-PE 0x17d20000-17d36000 Deferred msacm32 ELF 0x1ffe7000-20a5d000 Deferred libxcursor.so.1 ELF 0x23f50000-24a56000 Deferred libfreetype.so.6 ELF 0x4481d000-44832000 Deferred midimap.drv<elf> \-PE 0x44820000-44832000 Deferred midimap.drv ELF 0x4b170000-4b1e8000 Deferred x11drv<elf> \-PE 0x4b180000-4b1e8000 Deferred x11drv ELF 0x4f4b5000-4f4d2000 Deferred imm32<elf> \-PE 0x4f4c0000-4f4d2000 Deferred imm32 ELF 0x59c96000-59cd4000 Deferred wineoss.drv<elf> \-PE 0x59cb0000-59cd4000 Deferred wineoss.drv PE 0x5f800000-5f8e7000 Deferred mfc40 ELF 0x69e88000-69f0f000 Deferred comdlg32<elf> \-PE 0x69ea0000-69f0f000 Deferred comdlg32 ELF 0x6b255000-6bdd1000 Deferred libexpat.so.0 ELF 0x6bab2000-6baca000 Deferred msacm.drv<elf> \-PE 0x6bac0000-6baca000 Deferred msacm.drv ELF 0x77f00f28-efe03f28 Deferred <wine-loader> Wine-dbg>

July 2, 2004

Re: Pango for BiDi

by Shachar Shemesh

Mike Hearn wrote: >Hi Shachar, > >I am reading your interview and a few words jumped out at me, mostly >"BiDi", "shaping" and "unicode" - very vague I know, but if I >understand correctly Pango is a library with advanced support for shaping >and laying out all kinds of different scripts. Only stopper I can think of >would be that it uses UTF-8 not UTF-16. > > Pango uses fribidi for it's bidi. As fribidi doesn't do shaping, I'm not sure where pango's shaping comes from. It may be an add-on. In any case, I'm hoping that if/when fribidi starts to support UTF-16, pango will follow. Last time I looked at it, we were too far off from needing what pango had to offer. Getting a bidi edit control (sigh) is much higher on my todo (for which I have no time :-( ) >Have you looked at this, or am I talking smack? > > The really sad thing here is that ICU really has everything we need. It's just that it's too simple for people to compile wine without it, that is the problem. >thanks -mike > > Shachar

July 2, 2004

Re: collation tables

by Dmitry Timoshkov

"Vitaly Lipatov" <lav(a)altlinux.ru> wrote: > > What app is it? In which way it depends on the collation table > > being MS compatible? > It is 1C, an accounting system, widely used in Russia. > It keep a copy "right" collation table in exe file and compare it > with gotten from system. > > > Crossover Office has a patched version > > libs/unicode/collation.c, could you try it with your > > aplication? > If I have not Crossover Office, how I can try it? There is a Wine tar ball somewhere on the Codeweavers site which is used in the CX Office. It's freely available, since Wine is LGPL'ed. > > > Does anyone knows what is the better way to fix this tables, > > > in which place? Can I fix libs/unicode/cpmap.pl for it? > > > > Yes, that was an idea. > I see it idea is implemented in CrossOver Office already? No, nothing has been done yet, just a bit of thoughts. -- Dmitry.

July 2, 2004

Re: [Mono-winforms-list] Fw: [Mono-list] System.Windows.Forms plans.

by Peter Dennis Bartok

>You are asking for stable interfaces and those can only come once there >is a Wine 1.0. Its not here and dont get me wrong I think the Wine TODO >list is way to long and things should be close to frozen by now but >thats not the case. All you are doing is pointing out that its not >stable which is well known. I wish it was stable now but its not and >until the TODO is done its not going to be. Paul's message was very specific, asking about a versioning interface (which I would have loved to have, too, instead of trying to guess in code what version of Wine I might be dealing with). If very reasonable API requests are being refused while it is still under heavy development why would those be granted once 1.0 is reached? And, thus, how is working down the TODO going to help his request? With SWF we luckily have a choice whether or not use use Wine, we tried with and it didn't quite work out, so now we're gonna try without. Paul isn't as lucky, his code is dependent on the Win32 API. I would have thought that Alexandre is exited that his code is being put to new, cool uses even he never imagined... With that I should probably stop participating in this thread, since it's really not contributing to SWF development :-) Regards, Peter

July 2, 2004

Re: [Mono-winforms-list] Fw: [Mono-list] System.Windows.Forms plans.

by Steven Edwards

Paul, --- Paul Davis <paul(a)linuxaudiosystems.com> wrote: > PDB might not be able to fuss, but I will. I recently asked about a > way to figure out which version of Wine is in use at run-time because > of the recent changes to wine_init()'s prototype. Alexandre appeared > quite adamant that he was against introducing any such mechanism. > > Wine has a bit of a problem with the Mono project and our much > smaller > FST project to support VST win32/x86 plugins on linux. It has > previously been a self-contained project that did not provide > libraries, and whose internal API was not accessed by anyone or > anything outside of Wine itself. It now is being used by (at least) 2 > projects as a *library*, and it can either accept that role - which > implies providing (at least) runtime version info - or reject it, > which would be a great shame. You are asking for stable interfaces and those can only come once there is a Wine 1.0. Its not here and dont get me wrong I think the Wine TODO list is way to long and things should be close to frozen by now but thats not the case. All you are doing is pointing out that its not stable which is well known. I wish it was stable now but its not and until the TODO is done its not going to be. Thanks Steven __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail

July 2, 2004