January 2003 - Wine-Devel - list.winehq.org

Re: wxWindows: it's official!

by Dimitrie O. Paun

On January 8, 2003 02:08 pm, Francois Gouget wrote: > I can see how get_osfhandle() can be useful for interoperability in > Cygwin. setmode() seems of a more dubious value though (especially since > it means they must have implemented the awful CR/LF conversion across > their C library API (unless setmode() is nothing but a stub)). get_osfhandle() seems useful in Wine as well, no? As for semode(), it can work both ways. A simple #define setmode() do {} while(0) seems to be a good first order approximation... Do we do the awful CR/LF conversion in msvcrt? -- Dimi.

Jan. 8, 2003

Re: Re[2]: wxWindows: it's now official (almost)

by Dimitrie O. Paun

On January 8, 2003 05:01 pm, Nerijus Baliunas wrote: > But these are linux .a libs? Is it possible to get .so ones? It's more complicated than that. Let's first get things working with the .a libs, and then we can worry about using shared libs, don't you think? > > Does it have a mingw port? If it builds under mingw 2.0, > > Not yet, but it would be no big deal to create one. It almost > compiles on cygwin using configure script, only c-client should > be patched a little. Let's make a deal: you do the mingw port, get it into the official Mahogany tree, then I'll try to do the Wine port. Really, there's little point in trying to port to Wine before completing the mingw port. As for compiling under cygwin, that's cool, if it compiles with -mno-cygwin it's even better. > If I compile wxwin libs with winegcc, can I compile Mahogany > with gcc, and link to winegcc made wxwin? Yes, of course you can. But the simplest thing is to compile Mahogany with winegcc is well. Mind you, winegcc just uses the native gcc, so there's no problem using it. -- Dimi.

Jan. 8, 2003

Re: _wine_ldt_copy can not be auto-imported when building under cygwin

by Jeroen Janssen

Dimitrie O. Paun wrote: >On January 8, 2003 02:33 am, Jeroen Janssen wrote: > > >>The attached patch fixes the following problem: >> >>'_wine_ldt_copy' can't be auto-imported" when building under cygwin >> >> > >Jeroen, >Can you please test if the attach patch work? > > No, it doesn't work (there was an 'endif' missing). Attached is the fixed patch. --- Jeroen Janssen Index: include/wine/library.h =================================================================== RCS file: /home/wine/wine/include/wine/library.h,v retrieving revision 1.17 diff -u -p -r1.17 library.h --- include/wine/library.h 3 Jan 2003 03:12:58 -0000 1.17 +++ include/wine/library.h 8 Jan 2003 21:49:45 -0000 @@ -72,7 +72,17 @@ extern void wine_ldt_get_entry( unsigned extern int wine_ldt_set_entry( unsigned short sel, const LDT_ENTRY *entry ); /* the local copy of the LDT */ -extern struct __wine_ldt_copy +#ifdef __CYGWIN__ +# ifdef WINE_EXPORT_LDT_COPY +# define WINE_LDT_EXTERN __declspec(dllexport) +# else +# define WINE_LDT_EXTERN __declspec(dllimport) +# endif +#else +# define WINE_LDT_EXTERN extern +#endif + +WINE_LDT_EXTERN struct __wine_ldt_copy { void *base[8192]; /* base address or 0 if entry is free */ unsigned long limit[8192]; /* limit in bytes or 0 if entry is free */ Index: library/ldt.c =================================================================== RCS file: /home/wine/wine/library/ldt.c,v retrieving revision 1.5 diff -u -p -r1.5 ldt.c --- library/ldt.c 14 Aug 2002 21:10:50 -0000 1.5 +++ library/ldt.c 8 Jan 2003 21:49:48 -0000 @@ -28,6 +28,7 @@ #include <errno.h> #include "winbase.h" +#define WINE_EXPORT_LDT_COPY #include "wine/library.h" #ifdef __i386__

Jan. 8, 2003

Re[2]: wxWindows: it's now official (almost)

by Nerijus Baliunas

On Wed, 8 Jan 2003 15:33:41 -0500 "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > On January 8, 2003 03:09 pm, Nerijus Baliunas wrote: > > What do you get - windows .dll or linux .so? > > For what? The wxwin libs? I get .a files, that get > statically linked in. But these are linux .a libs? Is it possible to get .so ones? > > If the latter, I could > > try to compile Mahogany with it, it would be cool! > > Does it have a mingw port? If it builds under mingw 2.0, Not yet, but it would be no big deal to create one. It almost compiles on cygwin using configure script, only c-client should be patched a little. > it should build under Wine, no problem. I can give you a > hand if you need help. A good addition to the Winelib page: > http://www.dssd.ca/wine/Winelib-Apps.html If I compile wxwin libs with winegcc, can I compile Mahogany with gcc, and link to winegcc made wxwin? Regards, Nerijus

Jan. 8, 2003

Re: Help with /?? stuff

by Shachar Shemesh

Hi, I'll clarify my specific predicament. It seems that when MoveFileEx is called with "MOVEFILE_DELAY_UNTIL_REBOOT" flag, an entry is written into the registry with the file names to rename. Windows being what it is, a MULTI_SZ entry is used in a way that is totally and utterly incopatible with the MULTI_SZ definition, but we'll leave that rant to another time. The thing more interesting is that Windows, and as a result Wine, add "\??\" at the begining of the file name. This means that if I wanted to reanem C:\hello to C:\goodbye, the registry will get \??\C:\hello and \??\C:\goodbye. I tried passing this string directly into CreateFile, and no go (in other words, these are not valid file names, at least as far as Wine is concerned). My question is whether anyone is familiar enough with the API to tell whether these are valid path names that are simply not understood by Windows, or whether I am supposed to strip them away, whether on Windows or on Wine? Shachar Uwe Bonnes wrote: >>>>>>"Shachar" == Shachar Shemesh <arabeyes(a)sun.consumer.org.il> writes: >>>>>> >>>>>> > > Shachar> Hi list, Can someone please give me a good place to RTFM what > Shachar> the !$&!% to do with paths that have /?? in them? Can I just > Shachar> give them over to win32 functions, or do I need to do something > Shachar> with them first? > > Shachar> Also, does anyone have any docs on "runonce.exe"? I have a very > Shachar> vauge knowledge of what it does, and I could find -q -b > Shachar> mentioned as command lines. > >Every function using the wine implementation of CreateFile should cope with >a wide range of ways of writing the file path. So what did you do and what >is your problem? > >Bye > > >

Jan. 8, 2003

Re: wine 20021219 install patch : registry installation failed

by Thai Dang

Ooops Ok, I'll do a make clean next time Sorry. On Wed, 8 Jan 2003, Dimitrie O. Paun wrote: > On January 8, 2003 09:18 am, Thai Dang wrote: > > if you have troubles during installation (especially with registry > > installation failed) > > > > patch -p1 -l < patchwine-20021219.diff > > Thai, > > You've sent a 190K email for a patch that changes 3 lines! > Please, if you don't use CVS, at least use the -x switch for diff: > > diff -u -x "*.o" ... > > Or do a make clean before creating the patch. Or delete the garbage > by hand. Any of these are OK, as long as you send in _just_ the patch, > without the 99% extraneous garbage. > >

Jan. 8, 2003

Re: distcc and wine

by Dan Kegel

Martin Pool wrote: > I saw (reading my referrer logs :-) people were interested in distcc > with Wine, so I thought I would add it to distcc's performance > benchmark. > > Across three machines I saw a 2.58x speedup -- details are attached. > The machines were all 1GB, 1700MHz Pentium IV with a 100Mbps switched > connection. Building on just one took 22m57s, and across all three > took 8m53s. There is probably still some scheduling inefficiency > here, which I hope to reduce over the next few months. Cool! > I'm not sure what was happening with the person who saw little change. > Perhaps they had distcc misconfigured, or perhaps they hit a bug. > Either way I would be interested in hearing the details > ($DISTCC_HOSTS, etc) and seeing if I can help fix it. I think the issue was that I did not have three identical machines; the speedup from distributing to three hosts was minimal compared to just building on the fast machine. > I hope you find ccache and distcc useful. Wine is a cool project. Thanks for working on distcc et al! BTW, is gecc ready for prime time yet? Presumably it would be a win over either ccache or distcc? - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Jan. 8, 2003

Re: widl patch

by Ove Kaaven

On Wed, 8 Jan 2003, Greg Turner wrote: > On Wednesday 08 January 2003 12:31 pm, Ove Kaaven wrote: > > Feel free to recompile the .idl files after applying this patch... > > it's not necessary, but sooner or later someone is going to try what > > I'm currently trying... to compile MIDL-generated proxy/stub code > > with Wine headers. > > Indeed, I am doing this now with my RPC test. I'm not sure we are > targeting the same stuff, however. You can see my work-in-progress in > the K patchseries, which only has one (rejected) "official" patch: K01. > > Actually, what I'm really trying to do is mix and match. I want the .h > header to be generated by widl, and the _s.c and _c.c stubs to be > generated by MIDL. Well, that's pretty much what I'm doing, except I'm working on DCOM, not plain RPC, so I'm trying to compile _p.c. But that means that I haven't investigated everything widl needs to do to support plain RPC. > wire_marshall should be a barrel of laughs ;) Maybe after I get this > batch working I'll whip up some tests for 'ya that use it. Maybe. Unfortunately I'm still not entirely sure what implementations of UserMarshal is supposed to look like when the wire_marshal type contains embedded pointers. Is this supposed to be left to the NDR engine or does the UserMarshal routines have to marshal embedded pointers manually? Hmm... perhaps I should see if MS has some sample code somewhere. > o widl doesn't generate forward declarations for MIDL_user_allocate > and MIDL_user_free, should be trivial to fix. I could probably do so if you could show me what it's supposed to look like and when it's supposed to be generated (otherwise it might take a while before I get around to looking into it) > o widl doesn't parse the implicit_handle stuff in the .acf, > which cause MIDL to put an extern declaration in for the handle. Right, widl doesn't handle .acf files yet. Can it be done without it? > o RpcTry/Except/etc. Ugh, what a $&^@$*% train wreck. More-or-less > unfixable, and not widl's fault anyhow. ATM I may hack around this > using some evil, incorrect, and, frankly, downright offensive macros. > Long term, of course, I'm interested in seeing exception handling > souce-compatibility in wine... perhaps, winegcc, or some cousin, could > parse VC++ __try & family and generate wine-compatible __TRY & family > to match? Given the freedom to parse/generate, regardless of the > implementation specifics, it becomes a surmountable problem IMO. Currently I'm doing this: /* ignore exception handling for now */ #define RpcTryExcept if (1) { #define RpcExcept(expr) } else { #define RpcEndExcept } #define RpcTryFinally #define RpcFinally #define RpcEndFinally #define RpcExceptionCode() 0 which, along with a few more definitions in the RPC headers (which I planned to submit sometime soonish), make my MIDL-generated _p.c files compile almost without modification (I just need to add an #undef __WINE__ at the top). Though I've been wondering if perhaps MSVC-type __try/__except support can be done on gcc by taking advantage of gcc's support for nested functions. > Any chance either of the first two points will be fixed soon? Well, I can always try fix stuff like that if you let me know what needs to be done. Since we're working on slightly different interfaces, I haven't always looked too hard at the problems you'll face, so it helps if you explain exactly what should happen.

Jan. 8, 2003

Re: wine 20021219 install patch : registry installation failed

by Dimitrie O. Paun

On January 8, 2003 09:18 am, Thai Dang wrote: > if you have troubles during installation (especially with registry > installation failed) > > patch -p1 -l < patchwine-20021219.diff Thai, You've sent a 190K email for a patch that changes 3 lines! Please, if you don't use CVS, at least use the -x switch for diff: diff -u -x "*.o" ... Or do a make clean before creating the patch. Or delete the garbage by hand. Any of these are OK, as long as you send in _just_ the patch, without the 99% extraneous garbage. -- Dimi.

Jan. 8, 2003

Re: Mac OS X/Darwin port of Wine

by Francois Gouget

On Wed, 8 Jan 2003, Michael F. March wrote: [...] > > Once you can run Linux/x86 application like Mozilla with acceptable > > performance in Bochs on MacOS X you should be able to run applications > > such as Word in Wine with similar performance. Similarly, once Linux/x86 > > Gimp runs with acceptable performance in Bochs on MacOS X you can run > > Photoshop in Wine with similar performance (well, once it runs in Wine > > that is). > > Wine should be able to achieve greater performance than Bochs on > the same system configuration. IIRC, WABI sent only 25% of its cycles > emulating X86 instructions, the rest of the API calls were implemented > and executed in native mode. In Bochs case, it spends 100% of its time > emulating X86 instructions. Not really. My understanding of it is that the system libraries (C library, X libraries, etc.) would be native MacOS X libraries (or at least PPC libraries). Thus even running Wine in Bochs would execute native PPC code something like 50% of the time. By converting Wine's libraries so they are native PPC libraries you can save the extra 25% or so but only at the cost of tremendously increased complexity. I think it would be much harder than improvinig the performance of Bochs by implementing things such as just-in0time compiling (note I don't know exactly what optimisations Bochs already has). Furthermore this is all assuming that your application spends most of its time executing code in Wine dlls or system libraries. This is most likely to be wrong for applications such as Photoshop, all games, and even to some extent Access or Excel (depends how you use these). Thus, IMHO, improving the performance of Bochs and sticking to running Windows applications in Wine in Bochs is the best approach for now. Once Bochs is highly optimized, then it will be worth considering integrating it in Wine as a way to squeeze a few extra percents of performance... if it proves necessary. Plus, making it possible to run any Linux/x86 application on MacOS X has benefits beyond Wine that should not be neglected. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service

Jan. 8, 2003