Folks, I'm working with Dan Kegel on the idea of a winecfg/control panel merger; I did a .cpl or two a few days ago, but it seems I didn't quite understand the rules of the dev on wine/ or on linux for that matter :( I need someone to show me the ropes... Basically, The Toolbox. Question 1: I need to mess about with winecfg. I want to compile only winecfg.exe so I can immediately see when I made a mistake /rather than trying to build the entire source of wine/. What's the console command(s) I need to execute in order to get a winecfg.exe or any other single file, executable or otherwise out of the source /preferably not overwriting the real one in use/? Question 2: The cpls/any additional executables that have to be added to wine have to be in source form (duh!). Any particular quirks I should know about? Say, example.exe has to be created when wine is built; it goes into "c: \windows\system32". Is there anything special (some obscure settings?) that needs to be done in order for "./tools/wineinstall" and then "wineprefixcreate" to create "c:\windows\system32\example.exe" out of the source located in "<winesource>/programs/example"? Sorry if the questions appear newbie-ish :(
but it seems I didn't quite understand the rules of the dev on wine/ or on linux for that matter :( I need someone to show me the ropes... Basically, The Toolbox.
Last year THAT was my biggest initial problem as well. There are really a few caveats you will most probably hit (seems to me I hit ALL of them at some point *g) so if you do just drop me a message and I'll try and help, so is anyone on winehackers and this mailing list.
Question 1: I need to mess about with winecfg. I want to compile only winecfg.exe so I can immediately see when I made a mistake /rather than trying to build the entire source of wine/. What's the console command(s) I need to execute in order to get a winecfg.exe or any other single file, executable or otherwise out of the source /preferably not overwriting the real one in use/?
Build Wine once, then cd into the directory (i.e. programs/winecfg) and issue a 'make' everytime you changed source files, make will only rebuilt those object files and link to the rest of the build. Then run wine with LD_LIBRARY_PATH=/pathtoyourwinetree/libs /pathtoyourwinetree/wine something.exe... here's an example from a shell script I used during development: make; WINEDEBUG=loaddll,all,snoop,eng LD_LIBRARY_PATH=/home/google-soc/wine-git/libs \ /home/google-soc/wine-git/wine printfile.exe "Canon PIXMA iP3000" &> printfile.log
Question 2: The cpls/any additional executables that have to be added to wine have to be in source form (duh!). Any particular quirks I should know about? Say, example.exe has to be created when wine is built; it goes into "c: \windows\system32". Is there anything special (some obscure settings?) that needs to be done in order for "./tools/wineinstall" and
I have no clue about that, but here's a hint: the gnu tools are your friends. Study the grep manual page.. f.e. grep -nIErC3 'foo[1-9]*' . will recursively (-r) search all non-binary (-I) files within the current directory (.) and output any matches like foo42 with three lines of context (-C3) and line number (-n). Very very handy working with wine. Also if you have the KDE libs installed, try kscope, an incredible useful tool for C-development.
last but not least, compiler messages in quotes fed into a search engine often results in useful hints but you may have to dig a bit.. :) regards, marcel.
On Thu, Mar 20, 2008 at 9:13 AM, Marcel Partap mpartap@gmx.net wrote:
but it seems I didn't quite understand the rules of the dev on wine/ or on linux for that matter :( I need someone to show me the ropes... Basically, The Toolbox.
Last year THAT was my biggest initial problem as well. There are really a few caveats you will most probably hit (seems to me I hit ALL of them at some point *g) so if you do just drop me a message and I'll try and help, so is anyone on winehackers and this mailing list.
Can you be more specific on what the issues are here? Just curious.
Can you be more specific on what the issues are here? Just curious.
Well.. basically everything that goes beyond compiling small one-file programs not using the win32api :) I have to add that i didn't start hacking wine as first step but built an exe file outside of wine, so everything that is managed by the wine build system I had to find out by trial and error approach.. cross compiling linker flags, win32isms, pointer stuff, c macro syntax, grasping the nt printing subsystem.. it really was a tough way from start to.. well the finish line has yet to be crossed. Jesse and me will have to cooperate on getting our work merged into wine 1.1. I haven't worked on my code for more then three months and first have to check out a current git and look into the changes that went into x11drv and what that means for the eventual implementation of a git engine. Having said that it was a very difficult thing to do and I am nowhere near personal satisfaction about my outcome, it was a great experience and VERY VERY valuable to me. After first being introduced to 'real' (complex) programs during the SoC time I am now starting to feel comfortable coding and will commit some small code changes to various FOSS projects (wine, kde, vlc, drupal..) in the next few months. And wearing that shirt just totally rulez. :D sincerely, marcel
On Thursday 20 March 2008, Marcel Partap wrote:
Then run wine with LD_LIBRARY_PATH=/pathtoyourwinetree/libs /pathtoyourwinetree/wine something.exe...
I'm pretty sure you don't need to set LD_LIBRARY_PATH there, at least I've never needed to (and the wine script appears to do that).
- Neil
Am Donnerstag, 20. März 2008 16:05:51 schrieb pure_evil@mail.bg:
Question 1: I need to mess about with winecfg. I want to compile only winecfg.exe so I can immediately see when I made a mistake /rather than trying to build the entire source of wine/. What's the console command(s) I need to execute in order to get a winecfg.exe or any other single file, executable or otherwise out of the source /preferably not overwriting the real one in use/?
I use it mainly as a mesure of saving compile time, so I am not quite sure if it does what you want. But you can compile just the programs/winecfg subdirectory in the wine source, and run wine via /path/to/winesrc/wine winecfg, and it will run your new winecfg program. This saves you the time of make checking all directories, as well as the "make install" time.
Question 2: The cpls/any additional executables that have to be added to wine have to be in source form (duh!). Any particular quirks I should know about? Say, example.exe has to be created when wine is built; it goes into "c: \windows\system32". Is there anything special (some obscure settings?) that needs to be done in order for "./tools/wineinstall" and then "wineprefixcreate" to create "c:\windows\system32\example.exe" out of the source located in "<winesource>/programs/example"?
I think that's done in wine.inf, but I am not sure. Wine itself does not need anything in C:\windows\system32, this is mainly done for Windows applications that check if the file is present and check the version. You do not have to put fake DLLs in there for wine-private things.
-
Lei Zhang -
Marcel Partap -
Neil Skrypuch -
pure_evil＠mail.bg -
Stefan Dösinger