Hi everyone, I forget who's advice it was I took, but I went out and bought a few books on windows programming. And I plan to get started trying to help out with the wine project by trying to get the sample applications from the books to run under wine. If nothing else I guess I can let everyone know what it is I can't get working under wine (hopefully everyone welcomes that sort of input). So what I'm wondering now is what I should be using to compile my applications on windows. One of the books I have says all I need is the win32 sdk and I can compile apps. The closest thing I can find on msdn is the microsoft platform sdk, or perhaps the .net sdk. I've installed the microsoft platform sdk core but it doesn't seem to contain nmake.exe like the book I have talks about. So maybe I just need more pieces of the sdk? Or maybe I've installed the wrong thing entirely? I know of some other things I could use like borland's compiler or the bloodshed ide, that uses mingw I believe, but I was thinking it might be better if I stuck with microsoft development apps so everything happens the microsoft way in my programs. So maybe I just need to take one for the team and go out and buy visual studio? Thanks in advance, Glen
On January 7, 2003 03:03 am, Glen Kaukola wrote:
So what I'm wondering now is what I should be using to compile my applications on windows. One of the books I have says all I need is the win32 sdk and I can compile apps. The closest thing I can find on msdn is the microsoft platform sdk, or perhaps the .net sdk. I've installed the microsoft platform sdk core but it doesn't seem to contain nmake.exe like the book I have talks about. So maybe I just need more pieces of the sdk? Or maybe I've installed the wrong thing entirely?
Compiling under the SDK using MS tools gives us little value. We already know that works. If you don't want to spend the cash on MSVC (and not make MS any richer :)), and are willing to invest some time into it, I suggest the following path: 1. Get the latest mingw 2.0 distribution from http://www.mingw.org 2. Modify the makefiles that come in the book to work with GNU make, and the mingw tool chain. Make sure you use forward slashes (/)! :) 3. Build on Windows with your newly created Makefiles, and verify that everthing runs under Windows just fine. 4. If you feel like it, document what steps you took to convert the makefiles. Maybe we'll put that on the Winelib page, to help others in the future. 5. Take the exact same Makefiles you used under Windows, change 3 lines in them (CC=winegcc, CXX=wineg++, WINDRES=wrc), and try to compile under Linux. Use the latest Wine tree, and you should have native Linux apps. If you get errors in this step, they are Wine error, please report them, and let's try to fix them. This is the real value of this exercise. 6. Once everything builds, run the apps, and make sure they run fine. If they have problems, and you feel brave, let the debugging begin! Welcome to the team! -- Dimi.
On Tue, 7 Jan 2003, Dimitrie O. Paun wrote: [...]
Compiling under the SDK using MS tools gives us little value. We already know that works. If you don't want to spend the cash on MSVC (and not make MS any richer :)), and are willing to invest some time into it, I suggest the following path: 1. Get the latest mingw 2.0 distribution from http://www.mingw.org 2. Modify the makefiles that come in the book to work with GNU make, and the mingw tool chain. Make sure you use forward slashes (/)! :) 3. Build on Windows with your newly created Makefiles, and verify that everthing runs under Windows just fine. 4. If you feel like it, document what steps you took to convert the makefiles. Maybe we'll put that on the Winelib page, to help others in the future. 5. Take the exact same Makefiles you used under Windows, change 3 lines in them (CC=winegcc, CXX=wineg++, WINDRES=wrc), and try to compile under Linux. Use the latest Wine tree, and you should have native Linux apps. If you get errors in this step, they are Wine error, please report them, and let's try to fix them. This is the real value of this exercise. 6. Once everything builds, run the apps, and make sure they run fine. If they have problems, and you feel brave, let the debugging begin!
Or: 1. get the sources to a Linux machine 2. run winemaker on the sources to generate Makefiles 3. use the Makefiles to compile the examples using Winelib In this step you may find that winemaker made some mistakes about how to generate the Makefiles. You can either fix the makefiles (the simplest option), or try to improve winemaker. I bet the examples come with .dsp and .dsw files and improving winemaker to understand these would greatly improve its accuracy. 4. fix the compilation and link errors thus improving Winelib. 5. once everything, builds run the apps, and make sure they run fine. If they have problems, and you feel brave, let the debugging begin! This is pretty much what I have done with three programming books. However I have not had time to work on this for a long time and the Winelib compilation procedure has changed so much that probably nothing compiles anymore... But you are welcome to have a look at what I did and see if there is something salvageable: http://fgouget.free.fr/wine/booktesting-en.shtml
Welcome to the team!
Yep. The more the merrier. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux.
On January 7, 2003 03:39 am, Francois Gouget wrote:
1. get the sources to a Linux machine 2. run winemaker on the sources to generate Makefiles
We should modify winemaker to use winegcc. There's now a lot of (bad) duplication between winemaker, and winegcc, like wrapper support, linking, etc. Moreover, having winegcc handle the linking details automatically, we (1) shield the users from all that nastiness, and (2) retain more freedom on changing things in the build process. More importantly, we should generate Makefiles that work as is on mingw as well. This would increase their usefulness considerably. My Perl knowledge approaches zero asymptotically, so I can't quite do this myself, but I am willing to help on it with what's needed. -- Dimi.
On Tue, 7 Jan 2003, Dimitrie O. Paun wrote:
On January 7, 2003 03:39 am, Francois Gouget wrote:
1. get the sources to a Linux machine 2. run winemaker on the sources to generate Makefiles
We should modify winemaker to use winegcc. There's now a lot of (bad) duplication between winemaker, and winegcc, like wrapper support, linking, etc.
Actually there is not all that much duplication and I think winemaker and winegcc have different purposes: * winegcc & co The assumption is that the user already has Mingw makefiles that work. So their goal is simply to emulate the tools that come with the Mingw environment. * winemaker The assumption is that you have a Windows application (complete with CR/LF), most likely based on Visual C++ and thus with no suitable makefiles. So winemaker's goal is to quickly generate suitable Makefiles that will build Winelib applications/dlls from what it's given and fix the simple issues in the source (CR/LF, #pragmas). The backend is somewhat secondary. Currently the Makefiles are modelled after the Makefiles used to build the programs in Wine. From there we can go into two directions for the backend: 1. make the Makefiles more similar to those of the Wine programs. Alexandre told me he wanted the winemaker Makefiles to match and reuse more stuff from Wine. Part of this goal was to move lots of autoconf stuff to a .m4 file and to use that in both Wine and Winemaker generated stuff. There is some work to do there to make this feasible because Winemaker has to deal with the possibility that there may be multiple .exe/.dlls to build from a single Makefile (so you cannot define a single 'MODULE=' variable at the top of the Makefile) whereas this is never the case in Wine. 2. we can modify Winemaker to generate Mingw makefiles (does that rule out using autoconf?) and assume that a 3 line change will turn them into Winelib makefiles (or the other way around). Actually, has anyone written a .dsp to Mingw makefile converter? Potentially we could do both: * modify the makefiles in programs/* to use winegcc & co * turn these Makefiles into Mingw makefiles * make it so as much of this as possible can be shared with Winemaker * have Winemaker generate Mingw compatible makefiles based on the model above
Moreover, having winegcc handle the linking details automatically, we (1) shield the users from all that nastiness, and (2) retain more freedom on changing things in the build process.
The user is already somewhat shielded from these issues since he does not have to write the Makefiles. However each time the build process changes the Makefiles break so if winegcc & co can help with that it would be nice. [...]
My Perl knowledge approaches zero asymptotically, so I can't quite do this myself, but I am willing to help on it with what's needed.
The problem for me is time :-( -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...
On January 7, 2003 02:25 pm, Francois Gouget wrote:
* winemaker The assumption is that you have a Windows application (complete with CR/LF), most likely based on Visual C++ and thus with no suitable makefiles. So winemaker's goal is to quickly generate suitable Makefiles that will build Winelib applications/dlls from what it's given and fix the simple issues in the source (CR/LF, #pragmas). The backend is somewhat secondary.
This touches on an issue that I'd like to avoid discussing now -- it deserves a separate thread. But just to note that the things you've mentioned are not mutually exclusive: -- winemaker has a one-time fixup mode as you mention, for Window specific things that are non portable. This is something good that should stay in winemaker. -- Yes, I agree we want to share more of the build system between Wine and Winelib apps. But my proposal is not counter to this: we should use winegcc in Wine as well. -- Having the make files portable between Wine/Linux/MinGW can only be a good thing, right? What I'm saying is that winemaker right now generates a lot of the linking/compiling code 'inline' inside the Makefile. All this stuff is now formalized in winegcc/winewrap, so it just makes sense to use those. We avoid duplication, and repeated breakage whenever we change something in the build. It's a win-win IMO. -- Dimi.
On Tue, 7 Jan 2003, Dimitrie O. Paun wrote:
On January 7, 2003 02:25 pm, Francois Gouget wrote:
* winemaker The assumption is that you have a Windows application (complete with CR/LF), most likely based on Visual C++ and thus with no suitable makefiles. So winemaker's goal is to quickly generate suitable Makefiles that will build Winelib applications/dlls from what it's given and fix the simple issues in the source (CR/LF, #pragmas). The backend is somewhat secondary.
This touches on an issue that I'd like to avoid discussing now -- it deserves a separate thread. But just to note that the things you've mentioned are not mutually exclusive: [...] -- Having the make files portable between Wine/Linux/MinGW can only be a good thing, right?
I think our views are not incompatible and even that we basically agree. However there is a difference in emphasis. I'm more interested in improving the front-end, especially by adding support for dsp file which I think would improve the usefulness of winemaker tremendously (so that's what I would work on if I had time). You are more interested in the backend and in making it compatible with MinGW. However since I probably won't have time to make significant changes to winemaker in the near future my preferences are moot. Call for help: Please if you are interested in working on either aspect let us know (me or Dimitrie) and we will try to help you each with the part we are more familiar with. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ "Utilisateur" (nom commun) : Mot utilisé par les informaticiens en lieu et place d'"idiot".
Francois Gouget wrote:
On Tue, 7 Jan 2003, Dimitrie O. Paun wrote:
On January 7, 2003 02:25 pm, Francois Gouget wrote:
* winemaker The assumption is that you have a Windows application (complete with CR/LF), most likely based on Visual C++ and thus with no suitable makefiles. So winemaker's goal is to quickly generate suitable Makefiles that will build Winelib applications/dlls from what it's given and fix the simple issues in the source (CR/LF, #pragmas). The backend is somewhat secondary.
This touches on an issue that I'd like to avoid discussing now -- it deserves a separate thread. But just to note that the things you've mentioned are not mutually exclusive:
[...]
-- Having the make files portable between Wine/Linux/MinGW can only be a good thing, right?
I think our views are not incompatible and even that we basically agree. However there is a difference in emphasis. I'm more interested in improving the front-end, especially by adding support for dsp file which I think would improve the usefulness of winemaker tremendously (so that's what I would work on if I had time). You are more interested in the backend and in making it compatible with MinGW.
However since I probably won't have time to make significant changes to winemaker in the near future my preferences are moot.
Call for help:
Please if you are interested in working on either aspect let us know (me or Dimitrie) and we will try to help you each with the part we are more familiar with.
Me! Do we have a task list for this? David
Francois Gouget wrote:
2. we can modify Winemaker to generate Mingw makefiles (does that rule out using autoconf?) and assume that a 3 line change will turn them into Winelib makefiles (or the other way around). Actually, has anyone written a .dsp to Mingw makefile converter?
http://lnxscene.org/jylam/dsp2make/ Details: GPL, written in C, at version 0.3 (May 2002) Seems very simple and would need quit some work but I ran it on some of my projects and seemed to produce something reasonably sensible. Maybe we could take this and develop it. Alternative would be to do it in Perl etc. I don't know Perl. bother.
participants (4)
-
David Fraser -
Dimitrie O. Paun -
Francois Gouget -
Glen Kaukola