http://forum.ubuntuusers.de/topic/softmaker-office-2008--eine-alternative--v... has a review of an office suite named Softmaker Office 2008, available for Windows and now also Linux. The review says in part
"Irritiert hat uns, daß die Windows-Version von Office 2008, die von Stick gestartet werden kann, unter Wine besser, schneller und stabiler läuft, wie die native Office 2008 für Linux. Wer also die Windows-Version legal erworben hat, kann hier Geld sparen."
("It irritated us that the Windows version runs better on Wine than the native Linux version. If you have the Windows version already, save your money and run it on Wine.")
That's praise of sorts... although I hope it doesn't dissuade other vendors from doing native ports. - Dan
On Wednesday 10 September 2008 03:53:12 Dan Kegel wrote:
That's praise of sorts... although I hope it doesn't dissuade other vendors from doing native ports.
It'd be interesting to know who wrote this. Grammar errors like in the sentence you quoted aside, this article leaves me wondering about the author's background. It's also unclear what "better, faster and more stable" means in respect to the software running in Wine. E.g. it wouldn't surprise me if the Wine printer integration was better than what the office software has, according to the article.
Cheers, Kai
Dan Kegel wrote:
http://forum.ubuntuusers.de/topic/softmaker-office-2008--eine-alternative--v... has a review of an office suite named Softmaker Office 2008, available for Windows and now also Linux. The review says in part
"Irritiert hat uns, daß die Windows-Version von Office 2008, die von Stick gestartet werden kann, unter Wine besser, schneller und stabiler läuft, wie die native Office 2008 für Linux. Wer also die Windows-Version legal erworben hat, kann hier Geld sparen."
("It irritated us that the Windows version runs better on Wine than the native Linux version. If you have the Windows version already, save your money and run it on Wine.")
That's praise of sorts... although I hope it doesn't dissuade other vendors from doing native ports.
- Dan
I noticed the same type of thing when I was playing with DVD Shrink a couple days ago. Ripping speed in DVD Shrink via Wine was significantly faster than on Windows. What usually is a 2.5 hour process was about 1.5-1.75 hour process.
I agree though, hopefully the software vendors will do native ports :).
-Zac
Dan / All, I think what the guy was asking on improving winedbg is to have some sort of visual debugger much like VC/C++ , Eclipse, Borland C++ or the like... Where you can step through the code (seeing the whole thing like any visual debugger).? Then when looking at stacks you? click on a variable or stack and it either winds it back or display's it.?
Below is my thoughts on what would be a nice to have in some form of Debugger / Gui Debugger for Wine
So my wish list would be: 1) Some form of a Standard Gui Debugger 2) A way to select? the debug flags used with an explanation of what each is for... +sed is for this +relay does that...etc....?? 3) When you do +relay you could open separate output windows for each thread 4) The ability to turn each of the +relay wine thread output on or off... 4) Currently Wading through a relay log is a real pain and in some cases it prevents the problem from occuring. ??? Time outs because of too much data being collected and then having to wade through and determine what to and not to turn off. ??? So a note or best practice somewhere showing the heavy hitters in a +relay log? and turn them off by default.? However, note ??? somewhere saying? if +relay doesnt give enough information then turn on just these flags and run. That way we are not managing ??? flag lists when trying to figure out whats going wrong in an application. IMHO +relay is too unweldly and turning each flag on ??? individually is as well, so there needs to be some sort of happy medium somewhere. 5) A window with a list of the important wine structures or resources that can be watched as the application runs. 6) Source code debugging in the GUI with step through, break points, etc..( not like now in winedbg but more like one of the GUI's mentioned before) 7) Loading of application from gui debugger and run it 8) Ability to look at a stack and backtrace in the GUI 9) Value Watches within the GUI. 10) Code Checking ????? Some sort of bounds checking... ????? Uninitialized variable checking.... ????? Unreachable Code Checking 11) Use the GUI to help enforce the Wine Coding standard.. most modern GUI environments let you specify a style of coding. This would help the new people understand and follow the coding standards set up... instead of guessing like they do now. 12) Online help / Context help...? point to the IC in the wiki... lots of good stuff there... just hard to find sometimes.... 13) Integration with bugzilla... they find a bug... they create it in the GUI.. dump out the screen, stack and the like... so some of the base information is collected instead of wasting time back and forth and having so many invalid bugs. Again this format can be enforced through coding style templates... you want to submit a bug here is what you do... check boxes to include things... like I said screen shots... logs, traces, variables, hardware config, etc... 14) Integration with GIT... check and see if there is a new tree out there.. if so... flag it and git it... 15) Link to whats fixed in the new GIT tree... or a list of it... 16) Link to Dan's patchwatcher status... (kinda a workflow sort of thing) to know whats good and bad... 17) Generation of the GIT patch and then mail it to the list through a button... 18) GIT integration
You have to remember guy's alot of the new people coming in are not old timers like some of us who grew up in a non-gui world.. Like it or not? they are used to doing things in certain ways and I think we could get alot more people looking at bugs and helping fix them if we started thinking of something along these lines. This of course is not a complete list... And I am sure this is going to start a flame war or something close to it.. But I think this might be a good next step for something like the summer of code people to do.. or whomever maintains the wine debugger to think seriously about.
Most of these things I think could be implemented using the current wine debugger with some form of pipe between it and the GUI. That way the 'purists' can still debug using winedebug like now and the new people who choose to can use the GUI?
Thoughts????????????????????????????????
Problems I have noticed when debugging... If I kill (press the X button or close it from the task bar) the wine application, Wine does not clean up from itself... it leaves the wine mount daemon running. so I have to kill all the wine processes before I can restart wine. Otherwise any windows application which loads another application fails to start IE a game with a loader which then starts the game (I have found this in alot of MMO's where you have some form of login screen / loader which then loads in the actual game) (and no you cant always just call the main exe)
Question : Why does wine have to allocate all its memory at startup? re... the issue that is causing the ATI drivers to have such a fuss....? why not just allocate as needed? or have the ability (if its not there already) to specify the total amount of memory which is available to the wine process and limit wine to just that ammount of memory (kind of like the way most VM machines have the option of setting the maximum amount of memory which is available).
You can attach any debugger to a Win32 process running in Wine. This includes Linux debuggers like gdb, or any graphical frontends, as well as Windows debuggers like visual studio. If you built wine from source, the Linux debuggers will see the Wine source. Probably they can also read the Windows apps source if you have it. I'm not sure if Windows debuggers can access the Wine source, but maybe dbghelp.dll can do that
From: wine-devel-bounces@winehq.org [mailto:wine-devel-bounces@winehq.org] On Behalf Of celticht32@aol.com Sent: Wednesday, September 10, 2008 10:17 AM To: dank@kegel.com Cc: wine-devel@winehq.org Subject: Debugging Wine thoughts
Dan / All, I think what the guy was asking on improving winedbg is to have some sort of visual debugger much like VC/C++ , Eclipse, Borland C++ or the like... Where you can step through the code (seeing the whole thing like any visual debugger). Then when looking at stacks you click on a variable or stack and it either winds it back or display's it.
Below is my thoughts on what would be a nice to have in some form of Debugger / Gui Debugger for Wine
So my wish list would be: 1) Some form of a Standard Gui Debugger 2) A way to select the debug flags used with an explanation of what each is for... +sed is for this +relay does that...etc.... 3) When you do +relay you could open separate output windows for each thread
4) The ability to turn each of the +relay wine thread output on or off... 4) Currently Wading through a relay log is a real pain and in some cases it prevents the problem from occuring. Time outs because of too much data being collected and then having to wade through and determine what to and not to turn off. So a note or best practice somewhere showing the heavy hitters in a +relay log and turn them off by default. However, note somewhere saying if +relay doesnt give enough information then turn on just these flags and run. That way we are not managing flag lists when trying to figure out whats going wrong in an application. IMHO +relay is too unweldly and turning each flag on individually is as well, so there needs to be some sort of happy medium somewhere. 5) A window with a list of the important wine structures or resources that can be watched as the application runs. 6) Source code debugging in the GUI with step through, break points, etc..( not like now in winedbg but more like one of the GUI's mentioned before) 7) Loading of application from gui debugger and run it 8) Ability to look at a stack and backtrace in the GUI 9) Value Watches within the GUI. 10) Code Checking Some sort of bounds checking... Uninitialized variable checking.... Unreachable Code Checking 11) Use the GUI to help enforce the Wine Coding standard.. most modern GUI environments let you specify a style of coding. This would help the new people understand and follow the coding standards set up... instead of guessing like they do now. 12) Online help / Context help... point to the IC in the wiki... lots of good stuff there... just hard to find sometimes.... 13) Integration with bugzilla... they find a bug... they create it in the GUI.. dump out the screen, stack and the like... so some of the base information is collected instead of wasting time back and forth and having so many invalid bugs. Again this format can be enforced through coding style templates... you want to submit a bug here is what you do... check boxes to include things... like I said screen shots... logs, traces, variables, hardware config, etc... 14) Integration with GIT... check and see if there is a new tree out there.. if so... flag it and git it... 15) Link to whats fixed in the new GIT tree... or a list of it... 16) Link to Dan's patchwatcher status... (kinda a workflow sort of thing) to know whats good and bad... 17) Generation of the GIT patch and then mail it to the list through a button... 18) GIT integration
You have to remember guy's alot of the new people coming in are not old timers like some of us who grew up in a non-gui world.. Like it or not they are used to doing things in certain ways and I think we could get alot more people looking at bugs and helping fix them if we started thinking of something along these lines. This of course is not a complete list... And I am sure this is going to start a flame war or something close to it.. But I think this might be a good next step for something like the summer of code people to do.. or whomever maintains the wine debugger to think seriously about.
Most of these things I think could be implemented using the current wine debugger with some form of pipe between it and the GUI. That way the 'purists' can still debug using winedebug like now and the new people who choose to can use the GUI?
Thoughts????????????????????????????????
Problems I have noticed when debugging... If I kill (press the X button or close it from the task bar) the wine application, Wine does not clean up from itself... it leaves the wine mount daemon running. so I have to kill all the wine processes before I can restart wine. Otherwise any windows application which loads another application fails to start IE a game with a loader which then starts the game (I have found this in alot of MMO's where you have some form of login screen / loader which then loads in the actual game) (and no you cant always just call the main exe)
Question : Why does wine have to allocate all its memory at startup? re... the issue that is causing the ATI drivers to have such a fuss.... why not just allocate as needed? or have the ability (if its not there already) to specify the total amount of memory which is available to the wine process and limit wine to just that ammount of memory (kind of like the way most VM machines have the option of setting the maximum amount of memory which is available).
_____
Looking for spoilers and reviews on the new TV season? Get http://television.aol.com/feature/fall_tv?ncid=aoletv00050000000037 AOL's ultimate guide to fall TV.
Is there any documentation on the wine site how to set this up stefan??? It may be a start to what I am thinking.....
chris
-----Original Message----- From: Stefan Dösinger stefan@codeweavers.com To: celticht32@aol.com Cc: wine-devel@winehq.org Sent: Wed, 10 Sep 2008 11:32 am Subject: RE: Debugging Wine thoughts
You can attach any debugger to a Win32 process running in Wine. This includes Linux debuggers like gdb, or any graphical frontends, as well as Windows debuggers like visual studio. If you built wine from source, the Linux debuggers will see the Wine source. Probably they can also read the Windows apps source if you have it. I'm not sure if Windows debuggers can access the Wine source, but maybe dbghelp.dll can do that
From: wine-devel-bounces@winehq.org [mailto:wine-devel-bounces@winehq.org] On Behalf Of celticht32@aol.com
Sent: Wednesday, September 10, 2008 10:17 AM
To: dank@kegel.com
Cc: wine-devel@winehq.org
Subject: Debugging Wine thoughts
Dan / All,
I think what the guy was asking on improving winedbg is to have some sort of visual debugger much like VC/C++ , Eclipse,
Borland C++ or the like... Where you can step through the code (seeing the whole thing like any visual debugger).
Then when looking at stacks you click on a variable or stack and it either winds it back or display's it.
Below is my thoughts on what would be a nice to have in some form of Debugger / Gui Debugger for Wine
So my wish list would be:
1) Some form of a Standard Gui Debugger
2) A way to select the debug flags used with an explanation of what each is for... +sed is for this +relay does that...etc....
3) When you do +relay you could open separate output windows for each thread
4) The ability to turn each of the +relay wine thread output on or off...
4) Currently Wading through a relay log is a real pain and in some cases it prevents the problem from occuring.
Time outs because of too much data being collected and then having to wade through and determine what to and not to turn off.
So a note or best practice somewhere showing the heavy hitters in a +relay log and turn them off by default. However, note
somewhere saying if +relay doesnt give enough information then turn on just these flags and run. That way we are not managing
flag lists when trying to figure out whats going wrong in an application. IMHO +relay is too unweldly and turning each flag on
individually is as well, so there needs to be some sort of happy medium somewhere.
5) A window with a list of the important wine structures or resources that can be watched as the application runs.
6) Source code debugging in the GUI with step through, break points, etc..( not like no w in winedbg but more like one of the GUI's mentioned before)
7) Loading of application from gui debugger and run it
8) Ability to look at a stack and backtrace in the GUI
9) Value Watches within the GUI.
10) Code Checking
Some sort of bounds checking...
Uninitialized variable checking....
Unreachable Code Checking
11) Use the GUI to help enforce the Wine Coding standard.. most modern GUI environments let you specify a style of coding.
This would help the new people understand and follow the coding standards set up... instead of guessing like they do now.
12) Online help / Context help... point to the IC in the wiki... lots of good stuff there... just hard to find sometimes....
13) Integration with bugzilla... they find a bug... they create it in the GUI.. dump out the screen, stack and the like... so some
of the base information is collected instead of wasting time back and forth and having so many invalid bugs. Again this format
can be enforced through coding style templates... you want to submit a bug here is what you do... check boxes to include things...
like I said screen shots... logs, traces, variables, hardware config, etc...
14) Integration with GIT... check and see if there is a new tree out there.. if so... flag it and git it...
15) Link to whats fixed in the new GIT tree... or a list of it...
16) Link to Dan's patchwatcher status... (kinda a workflow sort of thing) to know whats good and bad...
17) Generation of the GIT patch and then mail it to the list through a button...
18) GIT integration
You have to remember guy's alot of the new people coming in are not old timers like some of us who grew up in a non-gui
world.. Like it or not they are used to doing things in certain ways and I think we could get alot more people looking at
bugs and helping fix them if we started thinking of something along these lines. This of course is not a complete list...
And I am sure this is going to start a flame war or something close to it.. But I think this might be a good next step for something
like the summer of code people to do.. or whomever maintains the wine debugger to think seriously about.
Most of these things I think could be implemented using the current wine debugger with some form of pipe between it and the GUI.
That way the 'purists' can still debug using winedebug like now and the new people who choose to can use the GUI?
Thoughts????????????????????????????????
Problems I have noticed when debugging...
If I kill (press the X button or close it from the task bar) the wine application, Wine does not clean up from itself... it leaves the
wine mount daemon running. so I have to kill all the wine processes before I can restart wine. Otherwise any windows
application which loads another application fails to start IE a game with a loader which then starts th e game (I have found this
in alot of MMO's where you have some form of login screen / loader which then loads in the actual game) (and no you cant
always just call the main exe)
Question :
Why does wine have to allocate all its memory at startup? re... the issue that is causing the ATI drivers to have such
a fuss.... why not just allocate as needed? or have the ability (if its not there already) to specify the total amount of memory
which is available to the wine process and limit wine to just that ammount of memory (kind of like the way most VM machines
have the option of setting the maximum amount of memory which is available).
Looking for spoilers and reviews on the new TV season? Get AOL's ultimate guide to fall TV.
dbghelp supports both linux debug formats (stabs, dwarf) as well as microsoft's one so any debugger using dbghelp as it's debug info provide should debug with all bells & whistles native & builtin applications I had some success with windbg (with a an 'e' between n & d ;-)
unfortunately, http://www.winehq.org/site/docs/winedev-guide/dbg-others isn't fully uptodate A+
On Wed, Sep 10, 2008 at 8:17 PM, celticht32@aol.com wrote:
Question : Why does wine have to allocate all its memory at startup? re... the issue that is causing the ATI drivers to have such a fuss.... why not just allocate as needed? or have the ability (if its not there already) to specify the total amount of memory which is available to the wine process and limit wine to just that ammount of memory (kind of like the way most VM machines have the option of setting the maximum amount of memory which is available).
Windows applications assume a certain memory layout, which sometimes conflicts with what *nix does.
For example applications don't expect to see pointers into the upper 1-2 GB of the 4 GB virtual memory address space because on Windows the kernel's memory is mapped there. But, ld-linux.so.2 could load libraries there, including libraries hosting Wine's DLLs, and pointers to memory in those would leak into the Windows code. So Wine prevents the "special" areas of Windows memory from being used by *nix libraries and functions like malloc() by mmap()ing that memory in advance.
In my opinion, it would be better if we used a custom dynamic linker (ie. an ld-wine.so) that could control where all libraries get loaded so we wouldn't have to steal memory in advance and go through one of the most elaborate startup processes in existence, where an assembly _start routine in wine-preloader loads before ld-linux.so.2 and then pretends to be the kernel.
Bye Damjan Jovanovic
On Wednesday 10 September 2008 10:44:09 pm Damjan Jovanovic wrote:
For example applications don't expect to see pointers into the upper 1-2 GB of the 4 GB virtual memory address space because on Windows the kernel's memory is mapped there. But, ld-linux.so.2 could load libraries there, including libraries hosting Wine's DLLs, and pointers to memory in those would leak into the Windows code.
AFAIK, Wine doesn't load .dll.so files using the standard dl lib functions. At least, the dlopen/dlsym functions don't recognize the .dll.so files in a winelib app. What it does, again AFAIK, is mmap the lower 2-3GB range so it can put kernel32/etc where some apps expect it to be, and to mimick Windows' allocation algorithms.
However, because it's all premapped, further libc malloc calls can't use that same range, and will quickly run out of allocatable memory. This causes problems particularly with video cards that have 512MB VRAM or more, since there's not enough room to map and/or mirror the card resources.
An idea I had and mentioned on IRC a couple times is to have libwine expose functions that can be used by drivers and other native modules to allocate "win32 memory" instead of using the standard libc functions. It would be pretty easy for a driver or such to do:
void *hdl = dlopen("libwine.so", RTLD_NOLOAD); void *(*mallocfunc)(size_t) = (hdl ? dlsym(hdl, "wine_malloc") : NULL); void (*freefunc)(void*) = (hdl ? dlsym(hdl, "wine_free") : NULL); if(!mallocfunc || !freefunc || dlerror() != NULL) { mallocfunc = malloc; freefunc = free; } ..use mallocfunc/freefunc for memory..
This will, of course, rely on drivers to be aware of Wine and handle it.
An alternative idea Alexandre had was to override libc's mmap, so anything loaded in the process would automatically use the new function (and thus not need any Wine-specific code). However, my attempts at doing that caused glibc to crash on init.
Am 10.09.2008 um 17:32 schrieb Stefan Dösinger:
You can attach any debugger to a Win32 process running in Wine. This includes Linux debuggers like gdb, [...]
As I didn't find hints on how to do this I tried myself:
** First, start gdb in the C: directory
mah@piccard:/otherubuntu/home/mah/.wine/drive_c$ gdb GNU gdb 6.8-debian Copyright [...] This GDB was configured as "x86_64-linux-gnu". (gdb) file wine Reading symbols from /usr/local/bin/wine...done. (gdb) directory /otherubuntu/home/mah/wine/ Source directories searched: /otherubuntu/home/mah/wine:$cdir:$cwd (gdb)
** Then, run the app
(gdb) run windows/notepad.exe Starting program: /usr/local/bin/wine windows/notepad.exe [Thread debugging using libthread_db enabled] [New Thread 0xf7c628c0 (LWP 793)] [New Thread 0xf7c61b90 (LWP 796)] [Thread 0xf7c61b90 (LWP 796) exited] [New process 793] Executing new program: /usr/local/bin/wine-preloader warning: Cannot initialize thread debugging library: generic error warning: Cannot initialize thread debugging library: generic error [New process 793] Fontconfig warning: "/etc/fonts/conf.d/53-monospace-lcd-filter.conf", line 17: invalid constant used : lcdlegacy Fontconfig warning: "/etc/fonts/conf.d/53-monospace-lcd-filter.conf", line 17: invalid constant used : lcdlegacy Fontconfig warning: "/etc/fonts/conf.d/53-monospace-lcd-filter.conf", line 17: invalid constant used : lcdlegacy
** Notepad should be running here. Interrupt it from the command line to have a look:
^C Program received signal SIGINT, Interrupt. 0xf7fec430 in ?? () (gdb) bt #0 0xf7fec430 in ?? () #1 0x00000008 in ?? () #2 0x7bc76516 in ?? () #3 [...] (gdb) list 1 /* 2 * Preloader for ld.so 3 * 4 * Copyright (C) [...]
As you see, listing appears to work in principle, while symbol lookup doesn't.
It's no secret Wine runs multiple processes and Windows applications run multiple threads, so you might want to look up how to handle this in gdb:
http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html
My tries to break not into the preloader, but the actual Windows application weren't successful so far, gdb's console appears to lock up somehow when setting follow-fork-mode & friends.
MarKus
- - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
On Thu, Sep 11, 2008 at 01:20:42PM +0200, Markus Hitter wrote:
Am 10.09.2008 um 17:32 schrieb Stefan Dösinger:
You can attach any debugger to a Win32 process running in Wine. This includes Linux debuggers like gdb, [...]
As I didn't find hints on how to do this I tried myself:
** First, start gdb in the C: directory
mah@piccard:/otherubuntu/home/mah/.wine/drive_c$ gdb GNU gdb 6.8-debian Copyright [...] This GDB was configured as "x86_64-linux-gnu". (gdb) file wine Reading symbols from /usr/local/bin/wine...done. (gdb) directory /otherubuntu/home/mah/wine/ Source directories searched: /otherubuntu/home/mah/wine:$cdir:$cwd (gdb)
** Then, run the app
(gdb) run windows/notepad.exe Starting program: /usr/local/bin/wine windows/notepad.exe [Thread debugging using libthread_db enabled] [New Thread 0xf7c628c0 (LWP 793)] [New Thread 0xf7c61b90 (LWP 796)] [Thread 0xf7c61b90 (LWP 796) exited] [New process 793] Executing new program: /usr/local/bin/wine-preloader warning: Cannot initialize thread debugging library: generic error warning: Cannot initialize thread debugging library: generic error [New process 793] Fontconfig warning: "/etc/fonts/conf.d/53-monospace-lcd-filter.conf", line 17: invalid constant used : lcdlegacy Fontconfig warning: "/etc/fonts/conf.d/53-monospace-lcd-filter.conf", line 17: invalid constant used : lcdlegacy Fontconfig warning: "/etc/fonts/conf.d/53-monospace-lcd-filter.conf", line 17: invalid constant used : lcdlegacy
** Notepad should be running here. Interrupt it from the command line to have a look:
^C Program received signal SIGINT, Interrupt. 0xf7fec430 in ?? () (gdb) bt #0 0xf7fec430 in ?? () #1 0x00000008 in ?? () #2 0x7bc76516 in ?? () #3 [...] (gdb) list 1 /* 2 * Preloader for ld.so 3 * 4 * Copyright (C) [...]
As you see, listing appears to work in principle, while symbol lookup doesn't.
It's no secret Wine runs multiple processes and Windows applications run multiple threads, so you might want to look up how to handle this in gdb:
http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html
My tries to break not into the preloader, but the actual Windows application weren't successful so far, gdb's console appears to lock up somehow when setting follow-fork-mode & friends.
Easy to do for most applications you use wine-pthread for debugging:
$ gdb wine-pthread (gdb) break CreateWindowExW Function "CreateWindowExW" not defined. Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (CreateWindowExW) pending. (gdb) r notepad.exe Starting program: /usr/bin/wine-pthread notepad.exe [Thread debugging using libthread_db enabled] [New Thread 0xf7d106c0 (LWP 9202)] [Switching to Thread 0xf7d106c0 (LWP 9202)]
Breakpoint 1, CreateWindowExW (exStyle=0, className=0x7fcf7c70, windowName=0x7fcf7c60, style=13565952, x=1, y=2, width=729, height=546, parent=0x0, menu=0x0, instance=0x7fcf0000, data=0x0) at win.c:1401 1401 cs.lpCreateParams = data; (gdb)
Ciao, Marcus
Am 11.09.2008 um 13:41 schrieb Marcus Meissner:
$ gdb wine-pthread (gdb) break CreateWindowExW Function "CreateWindowExW" not defined. Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (CreateWindowExW) pending. (gdb) r notepad.exe Starting program: /usr/bin/wine-pthread notepad.exe [Thread debugging using libthread_db enabled] [New Thread 0xf7d106c0 (LWP 9202)] [Switching to Thread 0xf7d106c0 (LWP 9202)]
Breakpoint 1, CreateWindowExW (exStyle=0, className=0x7fcf7c70, windowName=0x7fcf7c60, style=13565952, x=1, y=2, width=729, height=546, parent=0x0, menu=0x0, instance=0x7fcf0000, data=0x0) at win.c:1401 1401 cs.lpCreateParams = data; (gdb)
That works great, thanks.
MarKus
- - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Am 10.09.2008 um 17:16 schrieb celticht32@aol.com:
- A way to select? the debug flags used with an explanation of
what each is for... +sed is for this +relay does that...etc....?? 3) When you do +relay you could open separate output windows for each thread 4) The ability to turn each of the +relay wine thread output on or off...
Sounds like you have a tool in mind to switch tracing flags on and off while the app is running in Wine. That would be awesome.
A GUI has not only the advantage of being more attractive, it also shows/documents the available switches and (hopefully) tracks them.
MarKus
- - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Exactly my thoughts....? and might make things a little easier for new people coming in...? But I don't know if it can be done once the trace has started...? I do know that +relay intermixes its output with a thread id in it... so there would be some need to say once a new thread starts... do you want to trace that thread etc.... Is what I am asking doable? or is it a 'pipe' (snicker) dream..... (hey it was there and I had to use it)
Chris
-----Original Message----- From: Markus Hitter mah@jump-ing.de To: celticht32@aol.com Cc: dank@kegel.com; wine-devel@winehq.org Sent: Wed, 10 Sep 2008 12:37 pm Subject: Re: Debugging Wine thoughts
Am 10.09.2008 um 17:16 schrieb celticht32@aol.com:? ?
- A way to select? the debug flags used with an explanation of > what each is for... +sed is for this +relay does that...etc....???
- When you do +relay you could open separate output windows for > each thread?
- The ability to turn each of the +relay wine thread output on or > off...?
?
Sounds like you have a tool in mind to switch tracing flags on and off while the app is running in Wine. That would be awesome.? ?
A GUI has not only the advantage of being more attractive, it also shows/documents the available switches and (hopefully) tracks them.? ?
MarKus? ?
- - - - - - - - - - - - - - - - - - -?
Dipl. Ing. Markus Hitter?
?
Markus Hitter wrote:
Am 10.09.2008 um 17:16 schrieb celticht32@aol.com:
- A way to select? the debug flags used with an explanation of
what each is for... +sed is for this +relay does that...etc....?? 3) When you do +relay you could open separate output windows for each thread 4) The ability to turn each of the +relay wine thread output on or off...
Sounds like you have a tool in mind to switch tracing flags on and off while the app is running in Wine. That would be awesome.
A GUI has not only the advantage of being more attractive, it also shows/documents the available switches and (hopefully) tracks them.
Wine's taskmgr has in the Processes tab a context menu entry "Edit Debug Channels ...". Unfortunately it's broken.
Markus
Markus Amsler wrote:
Wine's taskmgr has in the Processes tab a context menu entry "Edit Debug Channels ...". Unfortunately it's broken.
No it's not broken. You can only enable/disable debug channels from there that were enabled with WINEDEBUG env var at the start of the program. This is optimization AJ put in place a long time ago.
Vitaliy.
So is there a way... from say something like GDB to send a message to wine to do the same thing..
The problem is the task manager is envoked in wine correct? so If we are debugging its kind of hard to get to the taskmgr....??
Chris
-----Original Message----- From: Vitaliy Margolen wine-devel@kievinfo.com To: Markus Amsler markus.amsler@oribi.org Cc: wine-devel@winehq.org Sent: Wed, 10 Sep 2008 5:54 pm Subject: Re: Debugging Wine thoughts
Markus Amsler wrote:
Wine's taskmgr has in the Processes tab a context menu entry "Edit Debug Channels ...". Unfortunately it's broken.
No it's not broken. You can only enable/disable debug channels from there that were enabled with WINEDEBUG env var at the start of the program. This is optimization AJ put in place a long time ago.
Vitaliy.
Do not top post! Especially with html message!
celticht32@aol.com wrote:
So is there a way... from say something like GDB to send a message to wine to do the same thing..
The problem is the task manager is envoked in wine correct? so If we are debugging its kind of hard to get to the taskmgr....
Chris
-----Original Message----- From: Vitaliy Margolen wine-devel@kievinfo.com To: Markus Amsler markus.amsler@oribi.org Cc: wine-devel@winehq.org Sent: Wed, 10 Sep 2008 5:54 pm Subject: Re: Debugging Wine thoughts
Markus Amsler wrote:
Wine's taskmgr has in the Processes tab a context menu entry "Edit Debug
Channels ...". Unfortunately it's broken.
No it's not broken. You can only enable/disable debug channels from there
that were enabled with WINEDEBUG env var at the start of the program. This
is optimization AJ put in place a long time ago.
You can read the source of task manager and see how it's doing it.
Vitaliy
Vitaliy Margolen wrote:
Do not top post! Especially with html message!
celticht32@aol.com wrote:
So is there a way... from say something like GDB to send a message to wine to do the same thing..
The problem is the task manager is envoked in wine correct? so If we are debugging its kind of hard to get to the taskmgr....
Chris
-----Original Message----- From: Vitaliy Margolen wine-devel@kievinfo.com To: Markus Amsler markus.amsler@oribi.org Cc: wine-devel@winehq.org Sent: Wed, 10 Sep 2008 5:54 pm Subject: Re: Debugging Wine thoughts
Markus Amsler wrote:
Wine's taskmgr has in the Processes tab a context menu entry "Edit Debug Channels ...". Unfortunately it's broken.
No it's not broken. You can only enable/disable debug channels from there
that were enabled with WINEDEBUG env var at the start of the program. This
is optimization AJ put in place a long time ago.
You can read the source of task manager and see how it's doing it.
Vitaliy
So again I ask.. is there a way from something like GDB to do the same thing? Yes I can look at the task manager but if someone could explain it could be documented and possibly turned into IC for others to use...
Chris
Chris Ahrendt wrote:
Vitaliy Margolen wrote:
Do not top post! Especially with html message!
celticht32@aol.com wrote:
So is there a way... from say something like GDB to send a message to wine to do the same thing..
The problem is the task manager is envoked in wine correct? so If we are debugging its kind of hard to get to the taskmgr.... Chris
-----Original Message----- From: Vitaliy Margolen wine-devel@kievinfo.com To: Markus Amsler markus.amsler@oribi.org Cc: wine-devel@winehq.org Sent: Wed, 10 Sep 2008 5:54 pm Subject: Re: Debugging Wine thoughts
Markus Amsler wrote:
Wine's taskmgr has in the Processes tab a context menu entry "Edit Debug Channels ...". Unfortunately it's broken.
No it's not broken. You can only enable/disable debug channels from there
that were enabled with WINEDEBUG env var at the start of the program. This
is optimization AJ put in place a long time ago.
You can read the source of task manager and see how it's doing it.
Vitaliy
So again I ask.. is there a way from something like GDB to do the same thing? Yes I can look at the task manager but if someone could explain it could be documented and possibly turned into IC for others to use...
It's not that easy. Task manager reads/writes directly into the memory of the process to get state, enable or disable debug channels. So yeah you can do that from GDB, You just need to find exactly the place to read from/write to.
This is such a pain because it's made to be fast with a minimal overhead. Not to be easily used on the low level.
Vitaliy.
celticht32@aol.com wrote:
Dan / All, I think what the guy was asking on improving winedbg is to have some sort of visual debugger much like VC/C++ , Eclipse, Borland C++ or the like... Where you can step through the code (seeing the whole thing like any visual debugger). Then when looking at stacks you click on a variable or stack and it either winds it back or display's it.
Below is my thoughts on what would be a nice to have in some form of Debugger / Gui Debugger for Wine
So my wish list would be:
- Some form of a Standard Gui Debugger
- A way to select the debug flags used with an explanation of what
each is for... +sed is for this +relay does that...etc.... 3) When you do +relay you could open separate output windows for each thread 4) The ability to turn each of the +relay wine thread output on or off... 4) Currently Wading through a relay log is a real pain and in some cases it prevents the problem from occuring. Time outs because of too much data being collected and then having to wade through and determine what to and not to turn off. So a note or best practice somewhere showing the heavy hitters in a +relay log and turn them off by default. However, note somewhere saying if +relay doesnt give enough information then turn on just these flags and run. That way we are not managing flag lists when trying to figure out whats going wrong in an application. IMHO +relay is too unweldly and turning each flag on individually is as well, so there needs to be some sort of happy medium somewhere. 5) A window with a list of the important wine structures or resources that can be watched as the application runs. 6) Source code debugging in the GUI with step through, break points, etc..( not like now in winedbg but more like one of the GUI's mentioned before) 7) Loading of application from gui debugger and run it 8) Ability to look at a stack and backtrace in the GUI 9) Value Watches within the GUI. 10) Code Checking Some sort of bounds checking... Uninitialized variable checking.... Unreachable Code Checking 11) Use the GUI to help enforce the Wine Coding standard.. most modern GUI environments let you specify a style of coding. This would help the new people understand and follow the coding standards set up... instead of guessing like they do now. 12) Online help / Context help... point to the IC in the wiki... lots of good stuff there... just hard to find sometimes.... 13) Integration with bugzilla... they find a bug... they create it in the GUI.. dump out the screen, stack and the like... so some of the base information is collected instead of wasting time back and forth and having so many invalid bugs. Again this format can be enforced through coding style templates... you want to submit a bug here is what you do... check boxes to include things... like I said screen shots... logs, traces, variables, hardware config, etc... 14) Integration with GIT... check and see if there is a new tree out there.. if so... flag it and git it... 15) Link to whats fixed in the new GIT tree... or a list of it... 16) Link to Dan's patchwatcher status... (kinda a workflow sort of thing) to know whats good and bad... 17) Generation of the GIT patch and then mail it to the list through a button... 18) GIT integration
You have to remember guy's alot of the new people coming in are not old timers like some of us who grew up in a non-gui world.. Like it or not they are used to doing things in certain ways and I think we could get alot more people looking at bugs and helping fix them if we started thinking of something along these lines. This of course is not a complete list... And I am sure this is going to start a flame war or something close to it.. But I think this might be a good next step for something like the summer of code people to do.. or whomever maintains the wine debugger to think seriously about.
Most of these things I think could be implemented using the current wine debugger with some form of pipe between it and the GUI. That way the 'purists' can still debug using winedebug like now and the new people who choose to can use the GUI?
Thoughts????????????????????????????????
I had grate success in the past with debugging windows programs using the --gdb mode under Kdevelop . Quote: "WineDbg can act as a remote monitor for GDB" this is done with the --gdb switch. Read documentation about how to do this. Since --gdb gives you a remote gdb target, then a full screen debugger based on gdb like Kdevelop feels right at home. And you can see/debug both your Windows as well as wine source code. Also code that you have compiled with msvc++.
The only problem is that you do not have all the windowism goodies winedbg gives you. I have once tried to hack CodeBlocks, to spawn winedbg instead of gdb. But they are painfully not "output" compatible. Painfully I mean that they are very close, but different enough to break the gdb-output parsers. The easiest way would be to fix winedbg and submit patches but I never got to that.
You might also get lucky with mingw based gui-debuggers. But you will not be able to debug msvc++ compiled code. Just like on windows.
Problems I have noticed when debugging... If I kill (press the X button or close it from the task bar) the wine application, Wine does not clean up from itself... it leaves the wine mount daemon running. so I have to kill all the wine processes before I can restart wine. Otherwise any windows application which loads another application fails to start IE a game with a loader which then starts the game (I have found this in alot of MMO's where you have some form of login screen / loader which then loads in the actual game) (and no you cant always just call the main exe)
Question : Why does wine have to allocate all its memory at startup? re... the issue that is causing the ATI drivers to have such a fuss.... why not just allocate as needed? or have the ability (if its not there already) to specify the total amount of memory which is available to the wine process and limit wine to just that ammount of memory (kind of like the way most VM machines have the option of setting the maximum amount of memory which is available).
Free Life Boaz
-
Boaz Harrosh -
celticht32＠aol.com -
Chris Ahrendt
-
Chris Robinson -
Damjan Jovanovic -
Dan Kegel -
Eric Pouech -
Kai Blin -
Marcus Meissner -
Markus Amsler -
Markus Hitter -
Stefan Dösinger -
Vitaliy Margolen -
Zac Brown