On December 11, 2002 09:20 pm, Alexandre Julliard wrote:
Removed the -noimport flag in spec files.
Alexandre, mind if you explain in a few words the rationale for this one? Not that I have a problem with it, but I like to know where you're going... :)
TIA, Dimi.
"Dimitrie O. Paun" dpaun@rogers.com writes:
Alexandre, mind if you explain in a few words the rationale for this one? Not that I have a problem with it, but I like to know where you're going... :)
This is for import libraries; basically the import libs (actually the .def files) need to contain all functions, even the ones we don't want to import from ELF libraries, because the same files are used for the Windows libraries. So the check is now done at the time we import the library, not at the time we generate the import lib.
On Thursday 12 December 2002 10:34 am, Alexandre Julliard wrote:
"Dimitrie O. Paun" dpaun@rogers.com writes:
Alexandre, mind if you explain in a few words the rationale for this one? Not that I have a problem with it, but I like to know where you're going... :)
This is for import libraries; basically the import libs (actually the .def files) need to contain all functions, even the ones we don't want to import from ELF libraries, because the same files are used for the Windows libraries. So the check is now done at the time we import the library, not at the time we generate the import lib.
Wow, it's like a whole new wine now! This wave of changes seems to be going over my head a bit, and your explanation doesn't seem to clear the fog for me... perhaps it's time I read some of the "scary parts" of the wine source and got a clue about how the wine compile/link/load sequence actually works?
(I should note that, so far, ignorance of these parts of wine has been fine for me; presumably, this wave of changes doesn't make such knowledge any more necessary, but it does pique my curiosity.)
For those of us who still don't "get it," could you provide a bit more explanation here? (i.e.: "as if to a child" ;) ) By the above, do you mean, in some sense, that some symbols get resolved at run-time instead of at compile time? What are the expected consequences/benefits of this change?
I'm sure it's all quite evident to you and the other old-timers around here, so sorry to be slow! Also, if I'm asking you to write a novel, just let me know what I need to read up on. Thanks!!
Greg Turner gmturner007@ameritech.net writes:
I'm sure it's all quite evident to you and the other old-timers around here, so sorry to be slow! Also, if I'm asking you to write a novel, just let me know what I need to read up on. Thanks!!
The idea is to mimic the way import libraries work under Windows, so that's what you should look into. Basically the Microsoft linker doesn't know how to link directly against a dll, so to use a dll you have to link against a "stub" static library that contains just a list of the functions exported by the dll. Under Unix the linker knows how to link against the same .so files that the dynamic loader uses at run time, so there is no need for separate import libraries.
The benefit of import libraries is that it reduces dependencies in the build process, because you can generate all the import libraries first and then build the dlls in the order you like, since they no longer depend on each other. This also allows circular dependencies between dlls, a misfeature that Microsoft uses unfortunately.
The main drawback is of course that it's easy for the dll and its import library to get out of sync and then you are in trouble, because the functions that you found at link time in the import lib do not exist at load time in the actual dll. The Unix way of having a single library is much cleaner, but of course we don't expect Microsoft to do things the clean way <g>
The actual implementation is a bit different between Windows and Wine: under Windows the import library has to be in the standard library file format that the linker understands (xxx.lib, or libxxx.a for gcc), and it is generated from the dll .def file. Under Wine we don't need a real library since everything is done inside winebuild without involving the Unix linker, so we use the .def file directly and skip the intermediate step of building a library object file.
Hope this helps...
The actual implementation is a bit different between Windows and Wine: under Windows the import library has to be in the standard library file format that the linker understands (xxx.lib, or libxxx.a for gcc), and it is generated from the dll .def file. Under Wine we don't need a real library since everything is done inside winebuild without involving the Unix linker, so we use the .def file directly and skip the intermediate step of building a library object file.
So are we going to move away from using the *.spec files at some point and just use def's by themselves? I dont think this would work because of the stubs functions and I'm sure there is more about the .spec system I dont understand.
Thanks Steven
__________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Steven Edwards steven_ed4153@yahoo.com writes:
So are we going to move away from using the *.spec files at some point and just use def's by themselves? I dont think this would work because of the stubs functions and I'm sure there is more about the .spec system I dont understand.
Right, it wouldn't work because of the stubs and the relay debugging support. What I'm thinking of doing at some point is to allow using a .def as alternative to a .spec, for cases where you don't need the extra features, like when porting an existing dll to Winelib. But for Wine itself we'll probably stick to .spec for the time being.
Alexandre Julliard wrote:
Right, it wouldn't work because of the stubs and the relay debugging support. What I'm thinking of doing at some point is to allow using a .def as alternative to a .spec, for cases where you don't need the extra features, like when porting an existing dll to Winelib. But for Wine itself we'll probably stick to .spec for the time being.
If wer'e on the subject, maybe we can enhance the stub files to contain, for each function, the versions of windows for which it is exported?
Right now we have a slight anomality where even if we define the windows version as win95, we still export functions only available under Windows NT.
Shachar
On Fri, 13 Dec 2002, Shachar Shemesh wrote: [...]
If wer'e on the subject, maybe we can enhance the stub files to contain, for each function, the versions of windows for which it is exported?
Right now we have a slight anomality where even if we define the windows version as win95, we still export functions only available under Windows NT.
We won't do that. In short it brings a lot of complication and no visible benefit. Besides from the obvious work it represents, for a number of libraries the version of the OS may not be as important as the version of IE that is installed. Furthermore, not exporting certain APIs is just one aspect. Win95 still exports most of the Unicode APIs but all they do is return 'error not implemented'. So 'perfect' emulation would require that we cause these functions to fail in the same way. It would also require that we remove support for various flags like the WAVE_FORMAT_DIRECT flag in winmm, the security related options, 16/32bit coordinates, and adjust countless other details.
So this would be pretty complex and it's very doubtful that applications rely on such things. If they did they would not work on NT/200/XP for one thing. And in the many years I have been reading wine-devel, I don't remember anyone hitting this problem.
Right, it wouldn't work because of the stubs and the relay debugging support. What I'm thinking of doing at some point is to allow using a .def as alternative to a .spec, for cases where you don't need the extra features, like when porting an existing dll to Winelib. But for Wine itself we'll probably stick to .spec for the time being.
Cool and Thanks for the info. I will try and test the new stuff tonight on mingw and send a patch or two as I see where some of the new code includes wait.h and will bomb.
Thanks Steven
__________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
wow, I got a novel after all! Thanks for the helpful info.
On Thursday 12 December 2002 07:38 pm, Alexandre Julliard wrote:
The main drawback is of course that it's easy for the dll and its import library to get out of sync and then you are in trouble, because the functions that you found at link time in the import lib do not exist at load time in the actual dll. The Unix way of having a single library is much cleaner, but of course we don't expect Microsoft to do things the clean way <g>
perhaps not... but now I understand how somebody can link a win32 app and run it on all the pseudo-incompatible windows platforms.
The actual implementation is a bit different between Windows and Wine: under Windows the import library has to be in the standard library file format that the linker understands (xxx.lib, or libxxx.a for gcc), and it is generated from the dll .def file. Under Wine we don't need a real library since everything is done inside winebuild without involving the Unix linker, so we use the .def file directly and skip the intermediate step of building a library object file.
Hope this helps...
Indeed it has, thanks. I'll definitely check out some of the source for this -- in particular, the parts that got patched recently, if only to skim and get the overall process memorized, so I don't feel like I'm breaking things everytime I touch the makefiles (and, of course, I will look into those .lib file's, which I've been ignoring for as long as I can remember ;) )
-
Alexandre Julliard -
Dimitrie O. Paun -
Francois Gouget -
Greg Turner -
Shachar Shemesh -
Steven Edwards