I have Visual C++ 6.0 running under Crossover Office 4.1, which of course means it's running under Wine. For one of the examples in the Wine/Winelib book, I decided to take the code produced by the VC++ Win32 "Hello World" wizard and see how to port it to Wine.
Turns out, it's almost trivial. Create an empty directory, copy the *.c, *.rc, *.h, and *.ico files to it. VC++ produces tons of other files, but they're either used to maintain the Visual Studio environment, or are intermediate compilation files that aren't needed. Then run:
$ winemaker .
The Makefile that Winemaker generates _almost_ works. You need to delete the references to the mfc library and mfc.dll. After doing that, running make generates the .so file. Wine runs it flawlessly.
I got to thinking - can I convert the code from the MFC application as easily? Seems like it's doable, because the generated code runs in VC++/Crossover Office 4.1. I tried the same steps as before, with Winemaker, but I couldn't figure out what Makefile modifications were needed.
All of this got me to thinking - could Wine running Visual C++ be a viable IDE for porting? Maybe just linking VC++ with the Winelib libraries would do it. Maybe after tweaking Winemaker and publishing a HOWTO we could show that this is a viable path? It's certainly easier than for Visual Studio developers and could help attract them to Wine.
Another benefit - we could use the Visual C++ sample programs as tests for Wine. The programs might exercise areas that haven't been tested thoroughly.
What do you think?
Ira
On Wed, Mar 02, 2005 at 05:22:24AM -0800, Ira Krakow wrote:
The Makefile that Winemaker generates _almost_ works. You need to delete the references to the mfc library and mfc.dll. After doing that, running make generates the .so file. Wine runs it flawlessly.
Nice!
I got to thinking - can I convert the code from the MFC application as easily? Seems like it's doable, because the generated code runs in VC++/Crossover Office 4.1. I tried the same steps as before, with Winemaker, but I couldn't figure out what Makefile modifications were needed.
For MFC apps, I think you need to recompile MFC with Wine first.
All of this got me to thinking - could Wine running Visual C++ be a viable IDE for porting? Maybe just linking VC++ with the Winelib libraries would do it.
This can't be done, we don't have VC++ sources. And besides, you don't get any additional benefits as compared to just running the native PE.
Ira Krakow wrote:
I have Visual C++ 6.0 running under Crossover Office 4.1, which of course means it's running under Wine.
1.5 years ago I had 3 problems with this. 1. It did not install. But that was not so bad because also on windows, VC6, if you copy an Installed directory and run it. Will work with some minor functionality missing. So it did load on wine. 2. When compiling, the std output was not redirected back to the IDE. 3. When debugging, it would Just do a Baaa and quit.
Has any of these problems changed? Can you set a break point and run under the debugger?
For one of the examples in the Wine/Winelib book, I decided to take the code produced by the VC++ Win32 "Hello World" wizard and see how to port it to Wine.
Turns out, it's almost trivial. Create an empty directory, copy the *.c, *.rc, *.h, and *.ico files to it. VC++ produces tons of other files, but they're either used to maintain the Visual Studio environment, or are intermediate compilation files that aren't needed. Then run:
$ winemaker .
The Makefile that Winemaker generates _almost_ works. You need to delete the references to the mfc library and mfc.dll. After doing that, running make generates the .so file. Wine runs it flawlessly.
There are 2 easier ways that I know of to do this. 1. Use dev-c++ from www.bloodshed.net/devcpp.html. It will Just open your DSP file and make a very good, very simple MinGW makefile for you. It will add all your -D and -I and all this nightmare in big projects. Both the result makefile and dev-c++ itself can be used with wine. It has a native Linux port has well. One thing to try is debugging. It uses gdb for windows. Does gdb for windows runs under wine??
2. Grab the DSW2MAKE util from MinGW. Written in Perl. The output makefile is very good for Winelib. Also keeps your -D(s), -I(s), and -l(s) and tries to convert other switchs as well. Better for very big projects.
I got to thinking - can I convert the code from the MFC application as easily? Seems like it's doable, because the generated code runs in VC++/Crossover Office 4.1. I tried the same steps as before, with Winemaker, but I couldn't figure out what Makefile modifications were needed.
MFC/ATL itself is not so simple...
All of this got me to thinking - could Wine running Visual C++ be a viable IDE for porting? Maybe just linking VC++ with the Winelib libraries would do it. Maybe after tweaking Winemaker and publishing a HOWTO we could show that this is a viable path? It's certainly easier than for Visual Studio developers and could help attract them to Wine.
If and when the VC++ Debugger can run under wine. (Even remotely) that will be the turning point for all the windows developers out there.
Another benefit - we could use the Visual C++ sample programs as tests for Wine. The programs might exercise areas that haven't been tested thoroughly.
Go grab CodeGuru.com & CodeProjet.com . There is your exercise of Win32API. But from what I talked to Jeremy once, he said that from their experience, having the PE source code doesn't really change anything in the way you debug the app. All you need is the relay-trace anyway. So why not Just grab a real live App and have that run.
What do you think?
Ira
Free Life Boaz
Boaz,
Has any of these problems changed? Can you set a break point and run under the debugger?
You can set a break point, the debugger runs, and stops at the break point. You can inspect and change variables.
However, Step Into, Step Over, doesn't work. If you try this after reaching the breakpoint, the debugging options are greyed out and the debugger ceases to function.
So I guess it's some progress, but it's not totally there yet.
There are 2 easier ways that I know of to do this.
- Use dev-c++ from www.bloodshed.net/devcpp.html.
It will Just open your DSP file and make a very good, very simple MinGW makefile for you. It will add all your -D and -I and all this nightmare in big projects. Both the result makefile and dev-c++ itself can be used with wine. It has a native Linux port has well. One thing to try is debugging. It uses gdb for windows. Does gdb for windows runs under wine??
I installed dev-c++ and really like it! The DSP import looks very promising - this is definitely an avenue I will pursue. I also like the Visual Studio-like look, and the fact that it creates makefiles for DLLs (static and dynamic), console apps, and Windows GUI apps.
Haven't tried gdb for Windows under Wine. Also looks like a good idea.
- Grab the DSW2MAKE util from MinGW. Written in
Perl.
These are all great suggestions. My next chapter will be to convert a "real world" app, which leans heavily on good debugging techniques. I want to define a good converstion path. You have helped me a lot. Thanks.
Ira
Ira Krakow wrote:
You can set a break point, the debugger runs, and stops at the break point. You can inspect and change variables.
This is amazing news. You should submit a little section about it for the Winelib hackers guide. And also for the user guides as it is an alternative to winedbg. One some people will like better. Eric, Mike 21 thumbs up :-}
I get it from the lack of an answer that MSDEV installs the regular way, and that it is able to compile a project with output redirected into the IDE so you can double click on errors and stuff?
However, Step Into, Step Over, doesn't work. If you try this after reaching the breakpoint, the debugging options are greyed out and the debugger ceases to function.
So I guess it's some progress, but it's not totally there yet.
Eric, Mike can you check this out? Does pe-gdb have the same problem with next/nexti?
I installed dev-c++ and really like it! The DSP import looks very promising - this is definitely an avenue I will pursue. I also like the Visual Studio-like look, and the fact that it creates makefiles for DLLs (static and dynamic), console apps, and Windows GUI apps.
Haven't tried gdb for Windows under Wine. Also looks like a good idea.
Use it under dev-c++. Just make an hello word application put a break point and press debug. Please do this for me I must know ...
- Grab the DSW2MAKE util from MinGW. Written in
Perl.
These are all great suggestions. My next chapter will be to convert a "real world" app, which leans heavily on good debugging techniques. I want to define a good converstion path. You have helped me a lot. Thanks.
Ira
This is my first post in an attempt to help/clarify, so dont bash me too bad for format :) Boaz has been helping me offline quite a bit in the last few days. Thanks to Boaz, I have gotten about a half a million lines of code to compile, and Ive almost gotten them to link. It is looking VERY hopeful for my presentation on Monday, but I digress...
At 12:01 PM 3/2/2005, Boaz Harrosh wrote:
<snip>
However, Step Into, Step Over, doesn't work. If you try this after reaching the breakpoint, the debugging options are greyed out and the debugger ceases to function.
So I guess it's some progress, but it's not totally there yet.
Are the buttons greyed out or does it misbehave when you click on the step into/over buttons? MSVC 6 running on Win2000 occasionally has the buttons greyed out when it lands on a breakpoint, but clicking on a source file ungreys them and then works fine.
<snip>
On Wed, 02 Mar 2005 21:01:22 +0200, you wrote:
I get it from the lack of an answer that MSDEV installs the regular way, and that it is able to compile a project with output redirected into the IDE so you can double click on errors and stuff?
Yes you can, console windows pop-up where they should stay invisible is the remaining thing. There is a submitted, but not yes committed to cvs, patch that makes the scrollbars paint correctly. That includes the side bar with icons for breakpoint, markers and so. Look for "Fix for scrollbar painting problem in Visual Studio" in the patches list.
Rein.
-
Boaz Harrosh -
Dimitrie O. Paun -
Ira Krakow -
Rein Klazes -
Rob D