February 2002 - Wine-devel - list.winehq.org

Favor: I need examples of un or poorly documented APIs
by Jeremy White 06 Feb '02

06 Feb '02

I'm working with someone involved in the Microsoft trial, and they are looking for some information from the Wine team. Specifically, they need clear examples of Windows APIs that are not documented, or cases where the actual working of an API is substantially different from the documented behavior. I've asked around CodeWeavers, and we had a few examples, but we're in a bit of a time crunch (48 hours), and I was hoping to ask a broader audience to pitch in. In an effort to keep this off topic traffic down, please reply just to me; if you like, I can post a summary of the results. Thanks, Jeremy

2 1

flaky regression(?) - patch.py?id=1012510895681951425038278
by lawson_whitney＠juno.com 06 Feb '02

06 Feb '02

Good day! Something in this patch makes my app set This->bigBlockSize of its inbox to zero when it gets a big batch of mail. Of course, the app (and my laola-based mailbox reader) is then unable to read the file. AFAICT, that is the only byte that is damaged, and it can be fixed after, but it is annoying. The app never did this before the patch, and hasn't since I reverted it yesterday. I will work on refining my observations, and I expect I will find and fix the error eventually. I'm just writing this in case it may be some help to anyone. Lawson

3 9

RE: (FWD) Announcing wineconf 2002
by Patrik Stridvall 06 Feb '02

06 Feb '02

> I received this today... it seems Lindows seem to want to host a Wine > conference. I noticed that they misspelled Alexandre's name and email > address, though they claim to work with him. Well, I'm not suprised. I'm not 100% sure how his last name is spelled. I usually cut and paste or more often, only use his first name. :-) > Since this is > supposed to be > an open conference anyway, and it's not a secret (most of the > mail is just > a straight dump of the webpage they link to anyway), I > decided to forward > it to wine-devel (but without the HTML). Hmm. I noticed people on the special invitition list (that get air transportion payed) must register by 13th February, 2002. It is only a week until then, they could have given us some more time to consider it, I think. Anyway, I'm slightly intrested in coming. Providing of course that at least a few of the Wine people will come. I'm not particularly intrested in travelling at least 12 hours by air to only talk to the Lindows.com people. Anybody else interested? PS. Does anybody know if a VISA to the US is required for citizens of the European Union countries (like Sweden)?

6 6

Re: Some more MSVC fixes
by David Laight 06 Feb '02

06 Feb '02

Alexandre Julliard wrote: > > David Laight <david(a)l8s.co.uk> writes: > > > This is the standard behaviour for C includes. It is actually usually > > best to use <> not "" for all header files - unless you explicitely want > > the file included from the current directory. > > The problem is our makedep uses the "" to determine which headers to > include in the dependency list, so this would have to be changed. Sounds like your makedep is broken! It needs to recognise <> and "" and treat them differently! David

1 0

RE: Some more MSVC fixes
by Patrik Stridvall 06 Feb '02

06 Feb '02

> On Wed, 6 Feb 2002, Patrik Stridvall wrote: > > > Well. If you do as I did and just add just create > > a Visual Studio Project (.dsp) for each DLL using the > > MS headers is the default. I had to add "..\..\include" > > to the include path to get it to use the Wine header. > > Sorry Patrik if my questions are sometimes naive, but I don't have a > Windows partition, let alone MSVC. So, here goes the question: > > MSVC must have a command line version of the compiler. Yes, MS Visual Studio always calls the command line version to compile. It is called "cl.exe". > Wouldn't it be > easier to use our Makefile system under cygwin to compile > Wine with MSVC? Possible. However I don't know exactly cygwin works. I try to avoid Windows as much as possible. I know how MSVS project files work though so I tryed with them first. Personally I think that the ultimate solution would be to automatically generate the .dsp files from Makefile.in or otherwise. There is a huge advantage of using the Microsoft format since Visual Studio can read them and you can for example just point and click on the files of each DLL to open them inside Visual Studio. The .dsp format is not very difficult to generate. It is just some sort of glorified Makefile. > > As to how good it works with MS header: > > Well, the problem is that if you don't add the path the > > Wine header files like debugtools.h doesn't > > exists so it doesn't compile very well and if > > you do the Wine headers take priority. > > That's why all our private headers must reside in > include/wine. That needs > to be fixed, eventually. Hmm. Well, I gave the MS headers one more try and discovered a few not so nice things. If you have a Wine specific include like below in a file: #include "heap.h" and this file heap.h in turn has a #include "winbase.h" it will include the Wine version of the file instead of the MS version. This is probably because with "" files in the same directory has priority IIRC. This is solvable by doing #include <winbase.h> but this requires changes in almost all .h files but it is just a simple search and replace. Hmm. I wonder if doing this will cause any bad effect with GNU C or other compilers? > > Of course you could add the MS header for inclusion one > > more time after the Wine headers, but where they > > are under Windows are installation dependent and not > > very portable. :-( > > Yeah, but that could be determined by configure. True. > > Additionally windef.h must be included first. > > > > #include "winbase.h" > > #include "windef.h" > > > > doesn't work. You have to do > > Of course. I was thinking would be nice to have a > > #include "wine/prologue.h" > <whatever includes you have> > #include "wine/epilogue.h" > > > #include "windef.h" > > #include "winbase.h" > > > > This is a minor issue though. > > Which should be fixed, I think. Yes. It will investigate some more. > > I also so got some other strange error with PCONTEXT > > in winnt.h which in didn't understand. > > > > In short it was a terrible mess so I primarily tested > > it with the Wine headers. > > It would be sooo nice if we could compile with other headers > as well. Just > compiling would be great, running the resulting executable would be > fantastic! Yes. :-)

4 3

RE: Some more MSVC fixes
by Patrik Stridvall 06 Feb '02

06 Feb '02

> > Personally I think that the ultimate solution would be to > > automatically generate the .dsp files from Makefile.in or otherwise. > > May not be easy but you are pretty good with perl so if anyone can > pull it off it's you :-) I don't think it is that difficult even for somebody less comfortable with Perl. The problem is getting all the details right and that will take some time, but allmost all details are quite easy, I think. > Once you have all the .dsp files, make a big .dsw file in the > top-level directory that references all the other .dsp files. That way > you can double-click on the .dsw, and then pick which dll you want to > build, build them all at once, etc. I guess you already know > about them > (and they are really simple to generate). Yes, I have it that way right now. But I only have a .dsp for a of few DLLs since doing it manually is quite boring. It would be quite nice to have all non core DLL compiling and working and with winetest ported. Then you could just run winetest through the debugger and be able to set breakpoint and step through the code in Visual Studio in order to get all to tests to run properly. :-) > > Hmm. Well, I gave the MS headers one more try and discovered > > a few not so nice things. > > > > If you have a Wine specific include like below in a file: > > #include "heap.h" > > and this file heap.h in turn has a > > #include "winbase.h" > > it will include the Wine version of the file instead of the > > MS version. This is probably because with "" files in the > > same directory has priority IIRC. > > No, that's because we use '-I .', which is a questionable practice. > Unfortunately I believe there is something that makes it hard to avoid > in Wine's case. I cannot remember what though. No, I don't think so. First of all -I. means current directory that is the directory of the current .c file. I was refering to that the #include "winbase.h" in file heap.h in wine/include perfered the winbase.h in wine/include rather than the MS variant. This is propably because #include "" with MSC always chooses the include from the same dir first rather the Microsoft dir that was EARLIER in the -I path (or rather the MSC equivalent). In the .c file #include "winbase.h" correctly included the MS variant. I haven't tested if GNU C have the same behavior but it might. > > > > Of course you could add the MS header for inclusion one > > > > more time after the Wine headers, but where they > > > > are under Windows are installation dependent and not > > > > very portable. :-( > > > > > > Yeah, but that could be determined by configure. > > > > True. > > But you would have to run configure on Windows, no? Since configure > is a shell script this means you need something like cygwin to compile > the source :-/ Or did you mean to run configure on Unix to > generate just > the right Makefiles for use on Windows? I didn't nessisarily mean configure but rather a Perl script that generates the .dsp files. Just install Perl and double click on configure.pl and all the .dsp was generated. Then double click on wine.dsw and you are ready to go.

1 0

compiling .obj with wine
by Ricardo 06 Feb '02

06 Feb '02

hi, Is it possible to compile/linkedit .obj, not the source, with wine libs? thanks Ricardo.

2 1

RE: Some more MSVC fixes
by Patrik Stridvall 06 Feb '02

06 Feb '02

> On Wed, 6 Feb 2002, Patrik Stridvall wrote: > [...] > > I also so got some other strange error with PCONTEXT > > in winnt.h which in didn't understand. > > You must define _X86_ before including 'winnt.h'. > Otherwise it won't > known on which architecture it's being compile and it won't define > CONTEXT. Yes, I realized that slighty after sending the mail. _M_IX86 is defined by the complier but _X86_ is defined by windows.h iif _M_IX86 is defined. > And you must also include 'windef.h'. Otherwise CONST is > not getting > defined and again, errors ensue. > > #define _X86_ > #include <windef.h> > #include <winnt.h> > > > Defining _X86_ is done in 'windows.h' which means that it is > virtually impossible to use these headers without including the big > beast itself. Yes. I have noticed that. However it is not that bad. #include "windef.h" #include "winnt.h" #include "stdarg.h" #include "winbase.h" Seems to do the trick. Another thing. It seems that all files will need to include "config.h" anyway because of issues like MSC doesn't support inline only __inline so a #define inline __inline is needed for anything reasonable to work anyway. Adding #include "config.h" at the top of each .c files is not that bad and things like #define _X86_ from windows.h could be there as well.

1 0

RE: Some more MSVC fixes
by Patrik Stridvall 06 Feb '02

06 Feb '02

> On Tue, 5 Feb 2002, Patrik Stridvall wrote: > > > I have finally tried to compile Wine with MSVC. > > Eventhough I had to do some hack on the whole > > it compiled quite well. > > Great. On a slightly related note, is it possible that we compile Wine > with the MS headers? What would it take to do that? Well. If you do as I did and just add just create a Visual Studio Project (.dsp) for each DLL using the MS headers is the default. I had to add "..\..\include" to the include path to get it to use the Wine header. As to how good it works with MS header: Well, the problem is that if you don't add the path the Wine header files like debugtools.h doesn't exists so it doesn't compile very well and if you do the Wine headers take priority. Of course you could add the MS header for inclusion one more time after the Wine headers, but where they are under Windows are installation dependent and not very portable. :-( Additionally windef.h must be included first. #include "winbase.h" #include "windef.h" doesn't work. You have to do #include "windef.h" #include "winbase.h" This is a minor issue though. I also so got some other strange error with PCONTEXT in winnt.h which in didn't understand. In short it was a terrible mess so I primarily tested it with the Wine headers. I have only tested a few DLL since doing .dsp files for each them was some work. I might do a script to automatically generate .dsp files for MSVC some day. > If we > could, we would > have one more degree of freedom: > > Platform Compilers BinFmt Headers > -------- --------- ------ ------- > Linux gcc ELF Wine > *BSD MSVC PE MS > Solaris Borland ReactOS(?) > Cygwin > > Esentially, most of the above possible cobinations should > work (except, of > course Windows-base compilers and ELF). Well. I think GNU C chokes on the MS headers so that won't work either. > If we get this level of portability, would be nice to set an automatic > compile farm which tries all the possible combinations, and reports > problems early, so they get fixed. Yes, that would probably be a good idea.

3 2

RE: (FWD) Announcing wineconf 2002
by Patrik Stridvall 06 Feb '02

06 Feb '02

> For those coming internationally, just hope that Microsoft > isn't waiting > at the airport with a bunch of DCMA lawyers to arrest you :) > > Mind you, M$ wouldn't do that because they don't like to > admit that Linux, > Wine, or anything else actually exists. I don't think Wine does anything DMCA related right now. However it will be much fun when we will get to the DRM parts of Windows. Dialog from the future: "Oh, no, this is not a circumvention device, we are just trying to implement copy protection to protect the intrests of RIAA and MPAA." "But what about the function FooIsAuthorized?" "What about it? It is just a stub that nobody for some reason have gotten around to implement. :-)" BOOL WINAPI FooIsAuthorized(...) { FIXME("(...): stub\n"); return TRUE; /* Information wants to be free */ }

1 0