Alexandre,
Why don't we take the following directives: name, heap, init out of the .spec file, and put them in the Makefile (transfered to winebuild through command line args)?
Some of them are supported in .DEF file as well, but all of them are supported as arguments to LINK. I think it will gain us flexibility if we also support them as command line arguments.
With that in mind, it would be neat if we could specify a flag at configure time to build most of Wine as PE with a cross mingw. It would be way cool if I could take the same comctl32.dll I have on Linux, copy it on my Windows machine, and test it out...
Anyway, what about a patch to at least support all of this as command line options as well?
"Dimitrie O. Paun" dpaun@rogers.com writes:
Why don't we take the following directives: name, heap, init out of the .spec file, and put them in the Makefile (transfered to winebuild through command line args)?
Well, 'name' is no longer really used, and 'heap' is used for 16-bit dlls, where specifying it in the makefile would be inconvenient. And I'm hoping to make 'init' default to DllMain one day... So I'm not sure we would use these command line options at all. But if you want to add them anyway I don't mind.
With that in mind, it would be neat if we could specify a flag at configure time to build most of Wine as PE with a cross mingw. It would be way cool if I could take the same comctl32.dll I have on Linux, copy it on my Windows machine, and test it out...
Note that you can do that today, you just need two separate build trees so it's a bit inconvenient. I'm planning to make it possible to build everything inside the same tree one of these days.
On September 10, 2002 12:42 pm, you wrote:
"Dimitrie O. Paun" dpaun@rogers.com writes:
Why don't we take the following directives: name, heap, init out of the .spec file, and put them in the Makefile (transfered to winebuild through command line args)?
Well, 'name' is no longer really used, and 'heap' is used for 16-bit dlls, where specifying it in the makefile would be inconvenient. And I'm hoping to make 'init' default to DllMain one day... So I'm not sure we would use these command line options at all. But if you want to add them anyway I don't mind.
I see. Apart from functions and 'init', this is what we have in .spec files today: heap 65520 rsrc version16.res name kernel rsrc version16.res rsrc version16.res rsrc resources/display.res rsrc resources/mouse.res heap 65520 rsrc resources/version16.res mode guiexe
I was hoping to get rid of them, along with init. Once we do that, it's gonna be very easy to extract the .spec files from the .c files, and be done with it. I was thinking we can add empty macros for __export (16-bit) and __declspec(dllexport). When compiling in PE, we can directly use them, if not, we can scan for them and generate a .spec file. Moreover, we should support natively .DEF files, for stuff that can not be specified inside the .c files. And so we will have:
PE build ELF build .c .DEF(opt) .c .c | \ | | v v v .DEF (opt) .o .spec .o \ / | | \ / v / \ / .o / \ / \ / LINK LINK | | v v .DLL .DLL
BTW, what does it take to default 'init' to DllMain?
With that in mind, it would be neat if we could specify a flag at configure time to build most of Wine as PE with a cross mingw. It would be way cool if I could take the same comctl32.dll I have on Linux, copy it on my Windows machine, and test it out...
Note that you can do that today, you just need two separate build trees so it's a bit inconvenient. I'm planning to make it possible to build everything inside the same tree one of these days.
Yay!!! Hip, hip, hurray for Alexandre!!!
-- Dimi.
"Dimitrie O. Paun" dimi@bigfoot.com writes:
I was hoping to get rid of them, along with init. Once we do that, it's gonna be very easy to extract the .spec files from the .c files, and be done with it. I was thinking we can add empty macros for __export (16-bit) and __declspec(dllexport). When compiling in PE, we can directly use them, if not, we can scan for them and generate a .spec file. Moreover, we should support natively .DEF files, for stuff that can not be specified inside the .c files.
Well, the problem is that the __declspec stuff is usually inside macros, so you have to run the code through the C preprocessor to find them. It can be done, but it's not that trivial. Also one thing you need to extract is the relay debugging information (and for 16-bit code information for the relay routines), and this requires a C parser (or some of Patrik's magic Perl stuff).
A related idea I had is to store the relay debugging independently from the .spec file; you could then use it in other cases, notably with snoop debugging of native dlls. And then you no longer need a .spec, you can use a .def or directly extract the __declspecs, at least for Win32. This would also potentially allow more intelligent relay routines, maybe even per-dll relay code that knows about the dll internal data structures; and hopefully also relay debugging of COM interfaces.
BTW, what does it take to default 'init' to DllMain?
Some linker magic, but mostly it requires dll separation so that all dlls can be linked the same way. This will simplify many things.
On September 10, 2002 02:15 pm, Alexandre Julliard wrote:
Well, the problem is that the __declspec stuff is usually inside macros, so you have to run the code through the C preprocessor to find them. It can be done, but it's not that trivial. Also one thing you need to extract is the relay debugging information (and for 16-bit code information for the relay routines), and this requires a C parser (or some of Patrik's magic Perl stuff).
I'm sure if we have the political will at the top, we'll find a solution... :) Patrik, care to help us extract the required stuff directly out of the source file?
A related idea I had is to store the relay debugging independently from the .spec file; you could then use it in other cases, notably with snoop debugging of native dlls. And then you no longer need a .spec, you can use a .def or directly extract the __declspecs, at least for Win32. This would also potentially allow more intelligent relay routines, maybe even per-dll relay code that knows about the dll internal data structures; and hopefully also relay debugging of COM interfaces.
Exactly! That's where I was driving at. But this depends on getting stuff automatically out of .c file, because this way we can retain the type information, which we now lose (except for strings). Once we have the type information, the sky's the limit... But most imprtantly, we eliminate (1) a potential source of mistakes, (2) a barrier for new commers (which are likely to be from the Windows world), and (3) avoid maintenaning the 700KB of .specs!!!
BTW, what does it take to default 'init' to DllMain?
Some linker magic, but mostly it requires dll separation so that all dlls can be linked the same way. This will simplify many things.
But now with the hack you've put in, aren't we there already? I know, kernel is the one exception, do we need to get rid of it as well?
On Wed, 11 Sep 2002, Dimitrie O. Paun wrote: [...]
Exactly! That's where I was driving at. But this depends on getting stuff automatically out of .c file, because this way we can retain the type information, which we now lose (except for strings). Once we have the type information, the sky's the limit...
Hmm, for strings the spec files currently distinguish between input strings (str) and output strings (ptr). This cannot be extracted from the source files... unless we start using IN/OUT macros everywhere?
Anyway, where it would be most useful is for Winelib applications. So if we can support these then it would be great. But it wouldn't it be easier to hack the compiler?
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ $live{free} || die "";
On September 11, 2002 05:48 am, Francois Gouget wrote:
Hmm, for strings the spec files currently distinguish between input strings (str) and output strings (ptr). This cannot be extracted from the source files... unless we start using IN/OUT macros everywhere?
It's all in the types, dude...
LPCSTR/LPCWSTR = IN, LPSTR/LPWSTR=IN/OUT.
"Dimitrie O. Paun" dpaun@rogers.com writes:
But now with the hack you've put in, aren't we there already? I know, kernel is the one exception, do we need to get rid of it as well?
Yes we still have to fix kernel. I'm hoping to hack something to make that work soon.
-
Alexandre Julliard -
Dimitrie O. Paun -
Dimitrie O. Paun -
Francois Gouget