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

[RFC] io.h & friends

by Dimitrie O. Paun

Folks, Just as I thought 'fine, I'll add the #ifdef, and get it over with', this thing comes back to haunt me. For the record, I've delete the previous thread, _and_ the io.h patch from my tree, thinking the issue was put to rest. As you can probably guess, I have the io.h problems in wxWindows, simply because this is what I work on right now. Let me state the problem again: -- When you compile with winegcc, you get these macros: __WINE__, __WIN32__, __UNIX__ -- You want your source to compile with the native libc and/or msvcrt -- You want it portable between Wine/MinGW/Cygwin. So, let's say I do: #ifndef __UNIX__ #include <io.h> #endif Well, this will not work if I want to compile with msvcrt, because __UNIX__ will be defined anyway. So what do I have to test for? I have to define a new symbol (USE_MSVCRT) and test for it #if !defined(__UNIX__) || defined(USE_MSVCRT) #include <io.h> #endif But this is not all! For example, wxWindows includes stuff like this: #include <sys/unistd.h> #include <sys/stat.h> Since they are available in mingw, and cygwin, and in UNIX, but if I want to use msvcrt they conflit with stuff from there! It's a mess. As you can see, the defines alone can make a grown man cry, and this is for a simple include. And I don't even know I've covered all the basis! Problem is that there are already 5 platforms: UNIX, Wine, Cygwin, MinGW, MS. And complexity grows exponentially with the number of platforms and combinations you have to test for. This way lays madness. It is now clear to me why the Cygwin people included io.h. It's so that you can compile with or without the -mno-cygwin switch, and have everything work. The only way for that to happen without ungodly defines and tests, is to have a flat space of include files: a union of MS & Unix files. Even if they are empty! This way you can simply do: #include <unistd.h> #include <io.h> and you make sure you get the access() definition regardless if you use the msvcrt of the libc. I'm not sure what to do. I was hoping to get a include/cygwin and/or a include/mingw directory so we can deal with these problems. I didn't know mingw had Unix headers as well, this complicates matters. Any fresh ideas in this matter are highly appreciated. -- Dimi.

Jan. 9, 2003

Re: wrc: -v, --[no-]use-temp-file

by Dimitrie O. Paun

On January 8, 2003 11:59 pm, Dimitrie O. Paun wrote: > ChangeLog > Added windres compatibility switches: -v, --[no-]use-temp-file. > Updated documentation, minor option parsing cleanup. My apologies, I changed my mind: I decided to do a bigger patch that will obsolete this one. Initially I thought they are disjunct, but the new patch touches 50% of the lines in this one, so I might as well collapse them together. It's in the works. -- Dimi.

Jan. 9, 2003

Re: DIB sync bug fix

by Tony Lambregts

Duane Clark wrote: > In the bitblt functions, if the source and destination DCs are the > same DC, the call: > X11DRV_UnlockDIBSection( physDevSrc, FALSE ); > caused the DC to be labeled as "InSync" without committing the changes > resulting from the bitblt. > > This fixes bug 885. > > Changelog: > If bit/stretchblt source and destination DCs are the same, > make sure the changes are committed before unlocking. Yup Fixes up bug 885 real slick With this patch Riven is (almost) Gold. I tried it out on bug 911and it improves the display but there is still some problems with this program (vast improvement but not perfect) <hint>if you want to look at it its free to download</hint> Bug 1095 might benefit from this patch I asked the reporter to try it. -- Tony Lambregts

Jan. 9, 2003

Re: Registering DLL's

by Alexandre Julliard

"John K. Hohm" <jhohm(a)acm.org> writes: > Alexandre, feel free to disapprove of this interface also; most of my > experience writing interfaces to library pieces has either been big, complex > Automation stuff to support VB database apps, or object-oriented C++. That's much better than the previous one. I'm not convinced you really need to build a static list, you might as well have a function to register a single interface and call it a number of times. > I would also like suggestions on whether an interface like this should > be exported via a static library like libwine_unicode.a (can that work > when I call advapi32 exports?), via a new wine-specific dll in src/dlls, > or simply by copying the implementation around to all the COM server dlls > (my least favorite option). I'm afraid copying it is the best choice; I don't think we want a new dll for just a couple of routines. It's not very elegant to duplicate it, but it shouldn't be a lot of code anyway. -- Alexandre Julliard julliard(a)winehq.com

Jan. 9, 2003

Re: wxWindows: it's official!

by Francois Gouget

On Wed, 8 Jan 2003, Dimitrie O. Paun wrote: > 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? Actually I got things reversed: * get_osfhandle() takes a C library file descriptor (fd) and returns a Win32 file handle (HANDLE). * open_osfhandle() is the one that takes the Win32 file handle (HANDLE) and returns a C library file descriptor (fd). I always get those two confused. Both are implemented in Wine's msvcrt library which is where they belong since the C library file handle is specific to msvcrt, i.e. if you get an fd from msvcrt and give it to open from the glibc bad things will happen (error in the best case, reading/writing to the wrong file in the worst case). There is similar functionality in Wine for Unix file descriptors which is provided by: wine_server_fd_to_handle and wine_server_handle_to_fd. But these work differently from the msvcrt ones. > As for semode(), it can > work both ways. A simple > > #define setmode() do {} while(0) > > seems to be a good first order approximation... Sure it's a hack that will let you compile the application. It will even run as long as it doesn't rely on that feature. > Do we do the awful CR/LF conversion in msvcrt? Nope, it's a stub in msvcrt for now. However it will print a trace if called with a parameter it does not support, and unlike header hacks it can actually be made to work. The better question is whether cygwin really implements setmode()... If no then the above hack is sufficient. Otherwise you will eventually need to: * implement a cygwin compatible C library and link cygwin applications with it * or link cygwin applications with the msvcrt (after improving it). This is quite likely to work * or modify the application during the port so that it does not rely on this functionality -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ "Utilisateur" (nom commun) : Mot utilisé par les informaticiens en lieu et place d'"idiot".

Jan. 9, 2003

Re: widl patch

by Ove Kaaven

On Wed, 8 Jan 2003, Greg Turner wrote: > On Wednesday 08 January 2003 02:53 pm, Ove Kaaven wrote: > > > 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. > > I'll look at my books when I get home and tell you if I find anything > about that. OK, great. I'll probably look around a bit myself, too. > > > 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) > > sure, I'll provide this. You can also see examples in my patch. But > rather than expect you to fish around for the info, I'll come up with > some concise specification of what I need and forward it to you (will > take some time, but the point is, I'll get to it sooner or later, so > you don't need to go fishing for it). OK. > > > 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? > > I am not sure (quite possibly there are command-line options to do the > same). This seems to change a number of things. For example, > excluding the .acf changes which API's are called by the stub to ones > unimplemented by wine! The whole AutoBindHandle mess is a bit of a > mystery to me ATM; but, from the perspective of the .h file, it is just > one line of code, an extern variable declaration. Perhaps, this is > asking too much of widl in the short run, and I should just provide it > myself for now. > > Once I get a better patch together I'll document such deficiencies more > carefully so you can refer to the source when you get around to .acf > parsing. OK. I haven't even looked into acf files yet, perhaps I need to soon then. > > 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). > > yep, that's more-or-less what I had. Should we publish these awful > exception handling hacks somewhere "special" in include/ ? They are > simply too evil to go into their "proper" home in the SDK headers IMHO > -- the consumer of such junk-food should be forced to specifically ask > for such a thing before we serve it to him as though it were a healthy, > well-balanced meal. I don't see why it can't be there if we do something like #ifdef HAVE_SNAZZY_COMPILER #define RpcTryExcept __try ... #else #define RpcTryExcept if (1) ... #endif People compiling Windows apps under Winelib would usually need to use a compiler with a lot of extensions anyway, and people needing to compile RPC/DCOM marshalling code should either use such a compiler, know what they're doing, or (when it becomes possible) use widl to generate such code. > > 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. > > hehe, that is a deliciously evil idea, one that has occured to me as > well... but, it sure does create some compiler dependencies... Wine depends on gcc in a lot of ways already. But my idea is that each compiler should have a way, and we can define __try to the way of the currently used compiler, and to a no-op (like that if(1) thing) if the compiler can't do it. > OTOH, since VC supports these natively as a "language extension", and > gcc has the nested functions, dependency-wise, I guess it's not all > that bad. Anybody know how long gcc has had support for nested fn's in > pure C? I'm pretty sure at least gcc 2.7.2 had them (I remember seeing it in its docs). > There are other issues, of course, like how to generate unique (but > preferably not /too/ unique) function names on-the-fly... If we need that, I suppose using __LINE__ might be good enough. > Quip: Thank god they never got around to implementing interface > inheritance and garbage collection for COM! Just imagine the mess... Who? What?

Jan. 8, 2003

Re: widl patch

by Greg Turner

On Wednesday 08 January 2003 02:53 pm, Ove Kaaven wrote: > 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. I'll look at my books when I get home and tell you if I find anything about that. > > 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) sure, I'll provide this. You can also see examples in my patch. But rather than expect you to fish around for the info, I'll come up with some concise specification of what I need and forward it to you (will take some time, but the point is, I'll get to it sooner or later, so you don't need to go fishing for 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? I am not sure (quite possibly there are command-line options to do the same). This seems to change a number of things. For example, excluding the .acf changes which API's are called by the stub to ones unimplemented by wine! The whole AutoBindHandle mess is a bit of a mystery to me ATM; but, from the perspective of the .h file, it is just one line of code, an extern variable declaration. Perhaps, this is asking too much of widl in the short run, and I should just provide it myself for now. Once I get a better patch together I'll document such deficiencies more carefully so you can refer to the source when you get around to .acf parsing. > > 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). yep, that's more-or-less what I had. Should we publish these awful exception handling hacks somewhere "special" in include/ ? They are simply too evil to go into their "proper" home in the SDK headers IMHO -- the consumer of such junk-food should be forced to specifically ask for such a thing before we serve it to him as though it were a healthy, well-balanced meal. > 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. hehe, that is a deliciously evil idea, one that has occured to me as well... but, it sure does create some compiler dependencies... OTOH, since VC supports these natively as a "language extension", and gcc has the nested functions, dependency-wise, I guess it's not all that bad. Anybody know how long gcc has had support for nested fn's in pure C? Or anything bad about using them? Perhaps, wine already does use them and therefore it's "A-OK"? There are other issues, of course, like how to generate unique (but preferably not /too/ unique) function names on-the-fly... but since the lexical scope is only that of the enclosing function, this also is probably not a show-stopper. Even in the best-case scenario, it will not look too pretty in the debugger. But exceptions never do anyhow... I dunno, I can't think of a compelling reason this couldn't work. It's probably worth at least the infamous "college try" (apparently universities try harder than people or something? WTF is a "college try" anyhow?) Quip: Thank god they never got around to implementing interface inheritance and garbage collection for COM! Just imagine the mess... -- gmt "It does not take a majority to prevail ... but rather an irate, tireless minority, keen on setting brushfires of freedom in the minds of men." --Samuel Adams, Patriot

Jan. 8, 2003

Re: distcc and wine

by Martin Pool

On 8 Jan 2003, Dan Kegel <dank(a)kegel.com> wrote: > 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 think the scheduler doesn't handle the case of heterogenous machines as well as it might. I'm going to try to fix that. You should make sure that the fastest machines are listed first in DISTCC_HOSTS. > Thanks for working on distcc et al! BTW, is gecc ready for prime > time yet? My impression is that it is still experimental, but I don't work on it so I can't really say. > Presumably it would be a win over either ccache or distcc? Integrated distributed caching and compilation is probably best in the long term. My approach was to get "small sharp" tools really solid first before tackling integration -- correctness is more important than speed. I've discovered a number of interesting gcc "behaviours" along the way and they might have been harder to isolate with a more complex tool. -- Martin

Jan. 8, 2003

Re: distcc and wine

by Martin Pool

On 8 Jan 2003, Paul Millar <paulm(a)astro.gla.ac.uk> wrote: > Hi Martin, > > On a similar note, I've been investigating OpenMOSIX on and off (mostly > off) for doing distributed compiling. In general, I've found it not > particularly stable (although its improving) and the performance not > particularly great -- although I've not had time to investigate the causes > of these problems. Besides, compiling code is quite a tricky task for it > to schedule/migrate. I haven't tried it myself but I would have expected the short, intense jobs generated by compilation to be a problem. > A reduction in compilation time by a factor of 2.6 (for three machines) > isn't bad at all! > > If you have the time, could you repeat this with different values for the > -j option? Timing how long it takes with -j2 (and perhaps -j3 and -j4) > would be interesting. Yes, I've been meaning to add that to the benchmark tool. I'll let you know. > Also, repeat the compilation several times for each value of -j and taking > the mean and standard deviation would be interesting too. In informal measurements it seems to be quite reproducible. The sd is typically only a few percent of the overall time. But that might be an interesting option to add too. -- Martin

Jan. 8, 2003

Re: widl patch

by Dimitrie O. Paun

On January 8, 2003 06:47 pm, Ove Kaaven wrote: > Wine depends on gcc in a lot of ways already. But my idea is that each > compiler should have a way, and we can define __try to the way of the > currently used compiler, and to a no-op (like that if(1) thing) if the > compiler can't do it. I think having such support would be _extremely_ cool! Most people use gcc anyway, so 99.9% of people would benefit, and it's one of the outstanding things for Winelib we don't yet have a decent solution for. > > OTOH, since VC supports these natively as a "language extension", and > > gcc has the nested functions, dependency-wise, I guess it's not all > > that bad. Anybody know how long gcc has had support for nested fn's in > > pure C? > > I'm pretty sure at least gcc 2.7.2 had them (I remember seeing it in its > docs). Yeah, they've been in there for as long as I can remember. But this is academic anyway, you need a new compiler (preferably >= 3.2) for anything non-trivial anyway, so... -- Dimi.

Jan. 8, 2003