Just wanted to let people know. And share this happy moment with my fellow workman
I have successfully Beta released a WinLib port of a, 1 million lines of code, windows program. QA will Install a first Linux Machine and will start to bang on it tomorrow. (Well more like an advanced Alfa I guess)
Technologies successfully compiled and running in the Project:
- Windows GUI & API (wrapped in an Old C++ lib, ZAFF).
- ODBC under CRecordSet from MFC - I use the MSSQL drivers, SQLing data from a neighboring WinXP-SQL Server. I used an mdac.exe installation application from Microsoft. With ODBC32 native DLL.
- General MFC contains, Strings, OleDispatch OleVariant OleBSTR... and even some GUI. - Actually to manage that I had an MSVC++ wizard generated MFC MDI Application with ODBC access and forms. Which helped me debug the MFC library. So MFC is pretty much covered.
- ATL/WTL OCX hosting and General ATL use for anything COM. - Here too a WTL app-wizard generated MDI application with IE and other OCXes on Forms help me verify the ATL subsystem. Including support for "uuidof", "#pragma property" and more. Hosting and Events work fine. ( actually ActiveX controls compile too, but TLB problem must be resolved.)
- A solution for Linking with C++ shared libraries that in-turn also use windows API. (I call them C++ fake DLLs.)
- C++ STL from STLPort ported to Wine to compile using msvcrt (and MFC)
And more stuff I cannot remember now.
By far the biggest problem was the msvcrt vs STL. and other native C++. This caused a big Linking problem where STL would bypass msvcrt but other application code would not. This proved to be fatal. From circular linking to allocators not matching to Libraries not able to load. Since MFC and ATL would not even think to compile with out msvcrt Headers and lib the issue had to be resolved. The only way I managed to solve it all is by directly linking msvcrt GCC style into STLPort and into every module there of. Now that would make some conflicts with OCX's like IE6 that can only run with native msvcrt.dll, so I also had to change it's name. One of the thing I would like to eventually do is Make a static msvcrt library using same source code but having different make files to be used in such situations where it has to be directly linked.
Tomorrow I will start synchronization with wine current tree. Once I have it synced (2 days max). I will need someone to help me and guide me on how to send it all in. Dimi, will that be you?
So I guess the scores are:
Wine vs Windows 1:1 World vs Microsoft 3:10 (we are making progress, wait for the last round) Boaz vs GCC 7:4 Good vs Evil (I better not say)
Happy new Year to all Free Life Boaz
On December 29, 2003 01:36 am, Boaz Harrosh wrote:
I have successfully Beta released a WinLib port of a, 1 millionlines of code, windows program. QA will Install a first Linux Machine and will start to bang on it tomorrow. (Well more like an advanced Alfa I guess)
Congratulations indeed!
Tomorrow I will start synchronization with wine current tree. Once I have it synced (2 days max). I will need someone to help me and guide me on how to send it all in. Dimi, will that be you?
Sure, why not. The best way I think is to post them to wine-patches (if you're fairly sure about the patches), and people will comment. If you are unsure, post to wine-devel first, we'll refine the patches there before they go to wine-patches.
Thanks OK lets start with an oldy Just to see if I get the tools right:
<patch> see attachment </patch>
should I embed or attach?
some explanations: The original Idea was proposed by Ove Kaaven (see __declspec(selectany) thread in wine-devel) The original Idea did not go so well because in lots of places these __declspecs would be again #defined by code and that #define 3-level indirection would confuse the compiler. Also this way one can see what is supported and what is not. I am afraid that I only checked that code compiles but did not write test cases where these constructs are usefully. (Also pretty_com.h & uuidof.h will come soon)
IMPORTANT the above and other patches I will submit later are all, let's call them: Microsoft Extensions to the C/C++ compiler. they are currently scattered in a few headers here and also in msvcrt. (like wchar_t). I think WINE headers should, presuppose, and stay clean of "Microsoft Extensions" functionality and stay close to MS-headers as possible. All "Microsoft Extensions" should go into a special header and be included where needed like here. (windef.h)
What do people think? should I go and collect all extensions to one header and remove them from where they currently are? This is also good for when one would need to compile with a compiler other than gcc.
Dimitrie O. Paun wrote:
On December 29, 2003 01:36 am, Boaz Harrosh wrote:
I have successfully Beta released a WinLib port of a, 1 million lines of code, windows program. QA will Install a first Linux Machine and will start to bang on it tomorrow. (Well more like an advanced Alfa I guess)
Congratulations indeed!
Tomorrow I will start synchronization with wine current tree. Once I have it synced (2 days max). I will need someone to help me and guide me on how to send it all in. Dimi, will that be you?
Sure, why not. The best way I think is to post them to wine-patches (if you're fairly sure about the patches), and people will comment. If you are unsure, post to wine-devel first, we'll refine the patches there before they go to wine-patches.
? windef.diff ? wine.kdevelop Index: include/windef.h =================================================================== RCS file: /home/wine/wine/include/windef.h,v retrieving revision 1.89 diff -u -r1.89 windef.h --- include/windef.h 24 Sep 2003 05:26:00 -0000 1.89 +++ include/windef.h 31 Dec 2003 08:04:32 -0000 @@ -113,14 +113,44 @@ #define FAR __ONLY_IN_WINELIB() #endif
+ #ifndef _MSC_VER + +// works well. Some times the exact placing veries with in the statment +#define __declspec_selectany __attribute__((weak)) +// ignored by GCC and is warned (supported by MinGW) +#define __declspec_dllexport __attribute__((dllexport)) +// ignored by GCC and is warned (supported by MinGW) +#define __declspec_dllimport __attribute__((dllimport)) +// works +#define __declspec_noreturn __attribute__ ((noreturn)) +// works +#define __declspec_nothrow __attribute__ ((nothrow)) +// works ?? +#define __declspec_naked __attribute__ ((naked)) + +// GCC is more restrictive about placing. look for TLS in gcc & msdn documentation +#define __declspec_thread __thread +// no paralle defined to nothing +#define __declspec_novtable +// Gcc only suports code ?? +#define __declspec_allocate(segname) __attribute__ (( section(segname) )) + +// property is supported thrugh the file pretty_com.h +// property( get=get_func_name|, put=put_func_name ) + +// _declspec( uuid() ) and __uuidof are supported with code changes +// see uuidof.h +#define __declspec_uuid(ComObjectGUID) error_SEE__uuidof_h__for_use_of_uuid + # ifndef _declspec -# define _declspec(x) __ONLY_IN_WINELIB() +# define _declspec(x) __declspec_##x # endif # ifndef __declspec -# define __declspec(x) __ONLY_IN_WINELIB() +# define __declspec(x) __declspec_##x # endif -#endif + +#endif //_MSC_VER
#define CALLBACK __stdcall #define WINAPI __stdcall
On December 31, 2003 03:33 am, Boaz Harrosh wrote:
Thanks OK lets start with an oldy Just to see if I get the tools right:
<patch> see attachment </patch>
should I embed or attach?
Please embed if you can, it makes it so much easier to comment on the code.
A few comments: -- please don't use C++ comments (//...), use C comments instead (/* ... */)
-- these things are defined by winegcc as well, we should protect them with #ifndef, otherwise we'll get a lot of warnings when building with winegcc
-- these things should not be available while building Wine, we should use the __ONLY_IN_WINELIB() like so: # define __declspec(x) __ONLY_IN_WINELIB(__declspec_##x)
Dimitrie O. Paun wrote:
Please embed if you can, it makes it so much easier to comment on the code.
And let the mozzila spell-check code comments :)
A few comments: -- please don't use C++ comments (//...), use C comments instead (/* ... */)
Done
-- these things are defined by winegcc as well, we should protect them with #ifndef, otherwise we'll get a lot of warnings when building with winegcc
they were/are protected, but I think it should be removed from winegcc because they don't do the Job. If you accept my proposal of ms-extensions.h collecting all these, and cleaning up wine headers, than winegcc could do: "-include ms-extensions.h" to take care of all extensions in one command line switch. (It can also give people using winegcc the freedom of what is defined). What is your opinion of an ms-extensions.h file? you didn't say.
-- these things should not be available while building Wine, we should use the __ONLY_IN_WINELIB() like so: # define __declspec(x) __ONLY_IN_WINELIB(__declspec_##x)
Please don't do: # define __declspec(x) __ONLY_IN_WINELIB(__declspec_##x) it will break things. See if my fix is good enough if not we can do an #else
<patch>
? windef.diff ? wine.kdevelop Index: include/windef.h =================================================================== RCS file: /home/wine/wine/include/windef.h,v retrieving revision 1.89 diff -u -r1.89 windef.h --- include/windef.h 24 Sep 2003 05:26:00 -0000 1.89 +++ include/windef.h 31 Dec 2003 09:15:15 -0000 @@ -113,14 +113,44 @@ #define FAR __ONLY_IN_WINELIB() #endif
+ #ifndef _MSC_VER -# ifndef _declspec -# define _declspec(x) __ONLY_IN_WINELIB() + +/* works well. Some times the exact placing varies with in the statement */ +#define __declspec_selectany __attribute__((weak)) +/* ignored by GCC and is warned (supported by MinGW) */ +#define __declspec_dllexport __attribute__((dllexport)) +/* ignored by GCC and is warned (supported by MinGW) */ +#define __declspec_dllimport __attribute__((dllimport)) +/* works */ +#define __declspec_noreturn __attribute__ ((noreturn)) +/* works */ +#define __declspec_nothrow __attribute__ ((nothrow)) +/* works ?? */ +#define __declspec_naked __attribute__ ((naked)) + +/* GCC is more restrictive about placing. look for TLS in gcc & msdn documentation */ +#define __declspec_thread __thread +/* no parallel defined to nothing */ +#define __declspec_novtable +/* Gcc only supports code ?? */ +#define __declspec_allocate(segname) __attribute__ (( section(segname) )) + +/* property is supported through the file pretty_com.h */ +/* property( get=get_func_name|, put=put_func_name ) */ + +/* _declspec( uuid() ) and __uuidof are supported with code changes */ +/* see uuidof.h */ +#define __declspec_uuid(ComObjectGUID) error_SEE__uuidof_h__for_use_of_uuid + +# if !defined(_declspec) && !defined (__WINESRC__) +# define _declspec(x) __declspec_##x # endif -# ifndef __declspec -# define __declspec(x) __ONLY_IN_WINELIB() +# if !defined(_declspec) && !defined (__WINESRC__) +# define __declspec(x) __declspec_##x # endif -#endif + +#endif //_MSC_VER
#define CALLBACK __stdcall #define WINAPI __stdcall
</patch>
Free Life Boaz
On December 31, 2003 04:38 am, Boaz Harrosh wrote:
they were/are protected, but I think it should be removed from winegcc because they don't do the Job.
Maybe, I'm not sure. I'll let Alexandre comment on the ms-extensions.h idea. In general, he does not like non-standard headers...
Please don't do: # define __declspec(x) __ONLY_IN_WINELIB(__declspec_##x) it will break things. See if my fix is good enough if not we can do an #else
What you have now is OK me thinks.
<patch>
? windef.diff ? wine.kdevelop
Are you using KDevelop to work on Wine? Is it OK? I'm a vim guy myself, and I've never used KDevelop, but I could maybe use some autocompletion :)
"Dimitrie O. Paun" dpaun@rogers.com writes:
On December 31, 2003 04:38 am, Boaz Harrosh wrote:
they were/are protected, but I think it should be removed from winegcc because they don't do the Job.
Maybe, I'm not sure. I'll let Alexandre comment on the ms-extensions.h idea. In general, he does not like non-standard headers...
No, I don't. Boaz, could you please explain a bit more why the definitions in winegcc don't work for you?
Alexandre Julliard wrote:
"Dimitrie O. Paun" dpaun@rogers.com writes:
On December 31, 2003 04:38 am, Boaz Harrosh wrote:
they were/are protected, but I think it should be removed from winegcc because they don't do the Job.
Maybe, I'm not sure. I'll let Alexandre comment on the ms-extensions.h idea. In general, he does not like non-standard headers...
No, I don't. Boaz, could you please explain a bit more why the definitions in winegcc don't work for you?
In short __declspec( selectany ) && __declspec( thread )
It has been discussed before. Lots of reasons
- Why header ? why not command line? 1. It is best if defines are in a header file and not on an hard-coded command-line. One would like to have the freedom to override default defines. For example: a windows dll project will have ten tons of dllimport/dllexport directives. The GCC will warn about it (I have 3.3.1). If in a header, one can nullify this directive and have clean compilation instead of tunning off warnings and miss on Fatal warnings (there are some warning in GCC that should be errors and make your program fly :( ). 2. If you inspect my patch you see that it is not that small. putting it all on a command line is not practical. 3. In an header you can do things that a command line can't. For example current code will do an __ONLY_IN_WINELIB(). Now winegcc will override that. Which means winegcc can not be used for wine compilation. And that makes it harder for a, one day, have MinGW/Wine set of Makefiles. (See ReactOS) (If you think about it, many wine dll's could be compiled as PE with MinGW and make no difference)
Conclusion: winegcc should stick to command-line switches and translations of options. like include directories, extra libs and so on. All code related and defines should go to an header file. If you don't like the ms-extensions.h name than it can be winegcc.h.
- What's new in the patch? 1. The main 2 things that are currently missing for me are: a) selectany vs weak and b) __declspec( thread ) vs __thread. These completely break under current implementation. The only way to go is with Ove's solution of mapping all options to defines and than overriding as necessary. (hard to do on a command line) 2. Please have a quick look on my current patch. I have done quite a comprehensive mappings of all __declspec's to GCC options. it should not be missed by winegcc users.
- Conclusion: I do not like current proposed solution (windef.diff). These things do not belong in windef.h - proof of that they are absent from M$ windef.h. They belong in a special header that mediates between different compilers. (like msvc vs gcc in our case). One could use ComuC++ or borlandC++ or even Intel, to compile wine and also to compile his WineLib application. These compilers have their own partial support for Microsoft extensions. And could actually make a WineLib user's life a bit easier because of other gcc peculiarities that forces them to change perfectly good code. What I propose is to go and collect all these msvc'ism into one header and clean that mess away from pure wine headers. I promise to not save any efforts in doing so. (One does at most what one can do :) )
And before we decide about all that, please accept my current patch it will not touch winegcc users only make them miss some of the fun.
Free life Boaz
On January 1, 2004 07:42 am, Boaz Harrosh wrote:
In short __declspec( selectany ) && __declspec( thread )
These are supported just fine by winegcc, what's wrong with it? AFACT, it's supported exactly the same way as in your patch...
Yes it does! exactly the same. Sorry! I checked, and double checked, by diffing against Last CVS. But I didn't realize winegcc went such a long way.
In any way I wish it would be an header. dllimport/dllexport gives me a warning even with -fms-extensions. In an header I could turn that off. Also later today I will submit "uuidof" and "declspec ( property () )". These must go in an header, but they can be on the side and manually included by those who needs them. Should I submit them to MinGW they might have use for them too.
Dimitrie O. Paun wrote:
On January 1, 2004 07:42 am, Boaz Harrosh wrote:
In short __declspec( selectany ) && __declspec( thread )
These are supported just fine by winegcc, what's wrong with it? AFACT, it's supported exactly the same way as in your patch...
Boaz Harrosh boaz@hishome.net writes:
Conclusion: winegcc should stick to command-line switches and translations of options. like include directories, extra libs and so on. All code related and defines should go to an header file. If you don't like the ms-extensions.h name than it can be winegcc.h.
It's not the name, it's the fact that we add a header that doesn't exist on Windows. You still haven't answered the real question: why wouldn't it work to have them in winegcc?
On January 1, 2004 08:43 pm, Alexandre Julliard wrote:
You still haven't answered the real question: why wouldn't it work to have them in winegcc?
There's no reason it shouldn't work. However, if we have a lot of defines, it becomes a bit hard to maintain them embedded in winegcc. Also, it would allow people to use gcc directly instead of winegcc (for whatever reason). It would be a wine/ header, and to be honest, I can't see any fundamental reason why we can't have a few well defined wine/ private headers. I'm on the fence on this issue, I don't need the header myself, but I can see a decent argument why you'd want to externalize these things out of winegcc...
"Dimitrie O. Paun" dpaun@rogers.com writes:
There's no reason it shouldn't work. However, if we have a lot of defines, it becomes a bit hard to maintain them embedded in winegcc. Also, it would allow people to use gcc directly instead of winegcc (for whatever reason). It would be a wine/ header, and to be honest, I can't see any fundamental reason why we can't have a few well defined wine/ private headers. I'm on the fence on this issue, I don't need the header myself, but I can see a decent argument why you'd want to externalize these things out of winegcc...
Sure, there are good arguments for both approaches. I was under the impression that Boaz was saying that the current way didn't work at all, in which case of course it needs to be changed. But otherwise it's just a winegcc implementation detail, and I see no compelling reason for changing it now, especially since winegcc is still going to need quite a bit of work.
On Wed, 2003-12-31 at 17:26, Dimitrie O. Paun wrote:
Are you using KDevelop to work on Wine? Is it OK? I'm a vim guy myself, and I've never used KDevelop, but I could maybe use some autocompletion :)
If vim has something like emacs tag completion then you could use that - I know etags works pretty well for me. I'm not saying you should use emacs obviously, but I expect there is an equivalent or vimscript you can use.
Briefly, you can do "make etags" in the wine source root, wait a bit, then two very useful features are available:
M-. (find-tag) lets you locate any definition in the wine source tree complete-tag lets you perform completion based upon those same tags.
I typically just use dabbrev-expand though which searches files you have open in the background for expansions.
Mike Hearn wrote:
On Wed, 2003-12-31 at 17:26, Dimitrie O. Paun wrote:
Are you using KDevelop to work on Wine? Is it OK? I'm a vim guy myself, and I've never used KDevelop, but I could maybe use some autocompletion :)
If vim has something like emacs tag completion then you could use that - I know etags works pretty well for me. I'm not saying you should use emacs obviously, but I expect there is an equivalent or vimscript you can use.
Briefly, you can do "make etags" in the wine source root, wait a bit, then two very useful features are available:
M-. (find-tag) lets you locate any definition in the wine source tree complete-tag lets you perform completion based upon those same tags.
I typically just use dabbrev-expand though which searches files you have open in the background for expansions.
Personally I use KDevelop for the debugger. Nothing like it save across the border at windows MSVC++. Well I guess I like the other stuff too.
I'm originally a Macintosh person so anything GUI for me. KDevelop will let you feel more at home if you come from windows. You cannot use KDevelop 2.1 release with wine. Too many files to deep. It will crash trying to import that project. (After 10 minuets of a progress bar) here you have been warned. KDevelop 3 beta does not do any of that. It Just runs the makefile no Q asked. 3 seconds done. But be careful do not use the official beta release (or RPMs or DEBs) use only the latest snapshot. You'll have to compile it from source.
and thanks for the "make etags" KDevelop likes that too ...
Mike Hearn wrote:
On Wed, 2003-12-31 at 17:26, Dimitrie O. Paun wrote:
Are you using KDevelop to work on Wine? Is it OK? I'm a vim guy myself, and I've never used KDevelop, but I could maybe use some autocompletion :)
If vim has something like emacs tag completion then you could use that - I know etags works pretty well for me. I'm not saying you should use emacs obviously, but I expect there is an equivalent or vimscript you can use.
Briefly, you can do "make etags" in the wine source root, wait a bit, then two very useful features are available:
M-. (find-tag) lets you locate any definition in the wine source tree complete-tag lets you perform completion based upon those same tags.
I typically just use dabbrev-expand though which searches files you have open in the background for expansions.
Personally I use KDevelop for the debugger. Nothing like it save across the border at windows MSVC++. Well I guess I like the other stuff too.
I'm originally a Macintosh person so anything GUI for me. KDevelop will let you feel more at home if you come from windows. You cannot use KDevelop 2.1 release with wine. Too many files to deep. It will crash trying to import that project. (After 10 minuets of a progress bar) here you have been warned. KDevelop 3 beta does not do any of that. It Just runs the makefile no Q asked. 3 seconds done. But be careful do not use the official beta release (or RPMs or DEBs) use only the latest snapshot. You'll have to compile it from source.
and thanks for the "make etags" KDevelop likes that too ...
On Thursday 01 January 2004 16:52, Mike Hearn wrote:
On Wed, 2003-12-31 at 17:26, Dimitrie O. Paun wrote:
Are you using KDevelop to work on Wine? Is it OK? I'm a vim guy myself, and I've never used KDevelop, but I could maybe use some autocompletion :)
If vim has something like emacs tag completion then you could use that - I know etags works pretty well for me. I'm not saying you should use emacs obviously, but I expect there is an equivalent or vimscript you can use.
Briefly, you can do "make etags" in the wine source root, wait a bit, then two very useful features are available:
M-. (find-tag) lets you locate any definition in the wine source tree complete-tag lets you perform completion based upon those same tags.
Mike, I'm not going to begin another flamewar, just decided to mention that vim too has all this features.
In short you type 'CTRL-P' in insert mode to call autocomplete and :ta ... or 'CTRL-]' to locate a tag in source tree.
Interested reader is refered to ":help i_CTRL-P" and ":help 'complete' "
-- Kirill.
-
Alexandre Julliard -
Boaz Harrosh -
Dimitrie O. Paun -
Kirill Smelkov -
Mike Hearn