March 2006 - Wine-Devel - list.winehq.org

Re: Winetools -> wine doors

by Dr J A Gow

Karl Lattimer wrote: > Fair point that it has been useful to you, it has been useful to me > also. Here's what I see. > > * An over complicated bash script, with way too many difficult to > maintain parts > * An inflexible application, which can only have new applications added > to it by the maintainer > * A terrible confusing GUI > > My choice of words was strong I admit, but I think this application is > ready to go to silicone heaven. > Your points are quite true. I was only really pointing out that something that enables individuals to Get Work Done Quickly (however bad the tool might be technically) is of considerable value. That, of course, does not mean that the tool shouldn't be replaced when it starts to suffer from 'bit-rot'. But let's not completely can it until a viable replacement is available otherwise we could undermine the perceived 'usefulness' of Wine when it comes to a necessary rush-job. I should add I don't use Winetools as a matter of course - I used it once to get me out of a hole, and it did! > What I am proposing and indeed working on is; > > * An appdb integrated application manager > * A clean UI which fits with gnome HIG > * A flexible, expandable, small and simple application which is easily > maintained but can do everything winetools does. This sounds like an excellent idea. > > Maybe nostalgia will keep some people using winetools, or trying to fix > something which is broken. Or maybe a couple people could lend a hand > with this and we could have something better ;) > > K, > > >

March 25, 2006

Re: Winetools -> wine doors

by Mike Hearn

Guys, WineTools clearly works for some people, there's no need to lay into it. After all, Wine itself has some slightly ugly areas of code still :)

March 25, 2006

Re: What happened to the Fedora packages?

by Andreas Bierfert

On Fri, 24 Mar 2006 15:13:16 +0100 Michel Ludwig <miclud(a)studcs.uni-sb.de> wrote: > Well, decent in the sense that the packages are well-made, or alternatively: > you've done a great job ! :-) ;) nice to hear ... tough if any of you have suggestions or problems let me know. - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert(a)lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred

March 25, 2006

Re: Could not run Digital Mars C/C++ Compiler under Wine

by Igor Sysoev

On Sat, 25 Mar 2006, Eric Pouech wrote: > Igor Sysoev wrote: >> On Thu, 23 Mar 2006, Eric Pouech wrote: >> >>> Igor Sysoev wrote: >>> >>>> When I try to run any program from Digital Mars C/C++ Compiler >>>> http://www.digitalmars.com/download/freecompiler.html >>>> under Wine 0.9.10 on FreeBSD 6.1, I always see the error: >>>> >>> this works fine here (on Linux)... may be a freebsd issue ? >> >> >> Well, is the way to try to debug the problem ? Some debug log ? > from what I see from your first post, a few remarks: > - file_set_error: Bad address => likely a read/write operation that fails > with an incorrect buffer > - stack overflow sent as a signal to the debugger > > it may well sound like that the running thread doesn't have all the required > memory > another strange item: fs is set to 1007 which is a rather high value (maybe > that's what you get on FreeBSD) > I'd start by looking at the stack allocation for the threads > > it also seems that you cannot get to the debug information (as dbghelp cannot > initiate), but this sounds like another issue I can run "WINEDEBUG=+all wine dmc.exe" and send a log. Igor Sysoev http://sysoev.ru/en/

March 25, 2006

Re: ilink32 hungs under Wine 0.9.10

by Igor Sysoev

On Thu, 23 Mar 2006, Igor Sysoev wrote: > When I try to link with ilink32.exe from C++ Builder Compiler and > Command Line Tools ( http://appdb.winehq.org/appview.php?versionId=1423 ) > ilink32 hangs. > > I saw comment on http://appdb.winehq.org/appview.php?versionId=1423 > about changing ADDRESS_SPACE_LIMIT. Could be applied to 0.9.10 ? I've tested changing ADDRESS_SPACE_LIMIT to 0x80000000 (patch attached) and ilink32.exe runs successfully. There is another patch http://www.winehq.com/hypermail/wine-devel/2004/03/att-0082/01-0012-wine-fi… that marks the page at 0x80000000 as reserved. As I know Windows has a compatibility code to emulate old bugs and undocumented for some applications depending on program name. Why not to add similar functionality to Wine ? Igor Sysoev http://sysoev.ru/en/

March 25, 2006

RE: [Bochs-developers] monitoring OS API calls

by Stanislav Shwartsman

Hello, Bochs already has two tools which able to do the things you describing. Bochs instrumentation allows you to set callback function for memory access occurred (it actually has a lot more capabilities) and you could write the callbacks to monitor WinAPI calls or everything else you want. Bochs internal debugger has virtual/linear/physical address breakpoint capability already, it also has some code to monitor Linux system calls as example. May be part of the code is outdate and should be modified/fixed but I don't think it should be a big effort to do that and I also could help you to do it fixing bugs or adding debug capabilities to the CPU. I think the tight choose for you it is Bochs with instrumentation; QEMU is less attractive because it has DT and it is much harder to instrument translated and not emulated code. Stanislav -----Original Message----- From: bochs-developers-admin(a)lists.sourceforge.net [mailto:bochs-developers-admin(a)lists.sourceforge.net] On Behalf Of Saulius Krasuckas Sent: Saturday, March 25, 2006 11:58 AM To: bochs-developers(a)lists.sourceforge.net Cc: wine-devel(a)winehq.org Subject: [Bochs-developers] monitoring OS API calls Hi, I mean Windows there - my primary aim is to monitor WinAPI calls. There exists quite a few of monitor apps to achieve this. But their nature is soft-intrusive - they patch system DLLs on disk or PE images in memory. I'd like to monitor calling of a functions from a lower-level side. One possibility is to rewrite system DLLs, which is hard in a case of Windows. Maybe another possibility can be to run OS in machine emulator and to break on reading/executing some virtual memory addresses? I imagine physical memory maps into linear addresses which maps into virtual addresses (perhaps into unshared space of each win32 process). Then it would be nice to implement a Debug Logging similar to one from the Wine project. [*] What effort is needed to implement breaking of emulation on execution of given/defined virtual addresses (plus reading a CPU state and virtual memory) of different Windows OS versions inside machine emulator? Can such code be put as some plugin to BOCHS or so? Maybe I need to look at the different machine virtualization projects like Qemu? [*] http://winehq.org/site/developer-cheatsheet ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ bochs-developers mailing list bochs-developers(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bochs-developers

March 25, 2006

monitoring OS API calls

by Saulius Krasuckas

Hi, I mean Windows there - my primary aim is to monitor WinAPI calls. There exists quite a few of monitor apps to achieve this. But their nature is soft-intrusive - they patch system DLLs on disk or PE images in memory. I'd like to monitor calling of a functions from a lower-level side. One possibility is to rewrite system DLLs, which is hard in a case of Windows. Maybe another possibility can be to run OS in machine emulator and to break on reading/executing some virtual memory addresses? I imagine physical memory maps into linear addresses which maps into virtual addresses (perhaps into unshared space of each win32 process). Then it would be nice to implement a Debug Logging similar to one from the Wine project. [*] What effort is needed to implement breaking of emulation on execution of given/defined virtual addresses (plus reading a CPU state and virtual memory) of different Windows OS versions inside machine emulator? Can such code be put as some plugin to BOCHS or so? Maybe I need to look at the different machine virtualization projects like Qemu? [*] http://winehq.org/site/developer-cheatsheet

March 25, 2006

Re: [Bochs-developers] monitoring OS API calls

by Fabian Scheler

Hi, well, how should this be possible with the help of an emulator like bochs? All you have is a binary image containing windows that is executed by bochs, how do you want to find out which API functions are called? At least you need a windows image that also contains debug symbols so you can find out which addresses are related to a OS API call. When you have this you may extend the simulation of the call-instruction to trace the OS API calls. Ciao, Fabian 2006/3/25, Saulius Krasuckas <saulius2(a)ar.fi.lt>: > Hi, > > I mean Windows there - my primary aim is to monitor WinAPI calls. There > exists quite a few of monitor apps to achieve this. But their nature is > soft-intrusive - they patch system DLLs on disk or PE images in memory. > > I'd like to monitor calling of a functions from a lower-level side. One > possibility is to rewrite system DLLs, which is hard in a case of Windows. > Maybe another possibility can be to run OS in machine emulator and to > break on reading/executing some virtual memory addresses? I imagine > physical memory maps into linear addresses which maps into virtual > addresses (perhaps into unshared space of each win32 process). > > Then it would be nice to implement a Debug Logging similar to one from the > Wine project. [*] > > What effort is needed to implement breaking of emulation on execution of > given/defined virtual addresses (plus reading a CPU state and virtual > memory) of different Windows OS versions inside machine emulator? > > Can such code be put as some plugin to BOCHS or so? Maybe I need to look > at the different machine virtualization projects like Qemu? > > > [*] http://winehq.org/site/developer-cheatsheet > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > bochs-developers mailing list > bochs-developers(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bochs-developers >

March 25, 2006

Re: Could not run Digital Mars C/C++ Compiler under Wine

by Eric Pouech

Igor Sysoev wrote: > On Thu, 23 Mar 2006, Eric Pouech wrote: > >> Igor Sysoev wrote: >> >>> When I try to run any program from Digital Mars C/C++ Compiler >>> http://www.digitalmars.com/download/freecompiler.html >>> under Wine 0.9.10 on FreeBSD 6.1, I always see the error: >>> >> this works fine here (on Linux)... may be a freebsd issue ? > > > Well, is the way to try to debug the problem ? Some debug log ? from what I see from your first post, a few remarks: - file_set_error: Bad address => likely a read/write operation that fails with an incorrect buffer - stack overflow sent as a signal to the debugger it may well sound like that the running thread doesn't have all the required memory another strange item: fs is set to 1007 which is a rather high value (maybe that's what you get on FreeBSD) I'd start by looking at the stack allocation for the threads it also seems that you cannot get to the debug information (as dbghelp cannot initiate), but this sounds like another issue A+ -- Eric Pouech

March 25, 2006

Re: Winetools -> wine doors

by Karl Lattimer

On Fri, 2006-03-24 at 19:00 +0000, Dr J A Gow wrote: > > I've looked through the winetools code and it is a clusterf*ck of > > nonsense. It appears to be in the final stages of code rot, however > > This "clusterf*ck of nonsense" helped me to get a microcontroller > development suite running under Wine, which otherwise would not install > natively. After over ten years designing and developing embedded systems, > there is one thing that stands out. Code that is 'nonsense' does not work > at all. Code that works may not be elegant, it may not be pretty and > you may hate the style, but it _works_ and therefore it is not nonsense. > This code works, is useful and serves a purpose. Just because you don't > like the way it is written does not make it nonsense. Language, please! Fair point that it has been useful to you, it has been useful to me also. Here's what I see. * An over complicated bash script, with way too many difficult to maintain parts * An inflexible application, which can only have new applications added to it by the maintainer * A terrible confusing GUI My choice of words was strong I admit, but I think this application is ready to go to silicone heaven. What I am proposing and indeed working on is; * An appdb integrated application manager * A clean UI which fits with gnome HIG * A flexible, expandable, small and simple application which is easily maintained but can do everything winetools does. Maybe nostalgia will keep some people using winetools, or trying to fix something which is broken. Or maybe a couple people could lend a hand with this and we could have something better ;) K,

March 25, 2006

Re: [opengl] Catch BadMatch errors before they can occur.

by Tony Lambregts

Tomas Carnecky wrote: > Tony Lambregts wrote: >> Tomas Carnecky wrote: >>> ok.. here is a patch, but I can't make it work. Maybe someone else sees >>> the bug. >>> >> What is the problem. this is from a log of Google using your patch and >> WINEDBUG="+wgl,+opengl" > > As you maybe see in the patch, I've put both SwapBuffers functions to > the opengl debug channel (rather than to wgl), but they don't show in my > trace. So something with the TRACE_(opengl)(...) is wrong or with the > way I've set up the channels. > > tom I do not think there is anything wrong. Just a little further in the same log I have: trace:opengl:X11DRV_SwapBuffers (0x7dde5470) trace:opengl:wine_glFinish () trace:opengl:X11DRV_SwapBuffers (0x7dde5470) trace:opengl:wine_glFinish () trace:opengl:X11DRV_SwapBuffers (0x7dde5470) trace:opengl:wine_glFinish () ... I applied your patch and did: $./configure && make depend && make $su #make install Perhaps a "make clean" will help? -- Tony Lambregts

March 25, 2006

Re: [opengl] Catch BadMatch errors before they can occur.

by Tomas Carnecky

Tony Lambregts wrote: > Tomas Carnecky wrote: >> ok.. here is a patch, but I can't make it work. Maybe someone else sees >> the bug. >> > What is the problem. this is from a log of Google using your patch and > WINEDBUG="+wgl,+opengl" As you maybe see in the patch, I've put both SwapBuffers functions to the opengl debug channel (rather than to wgl), but they don't show in my trace. So something with the TRACE_(opengl)(...) is wrong or with the way I've set up the channels. tom

March 24, 2006

Wine/Interix -- The pros and cons.

by Segin

I was thinking about running Wine on Interix (the POSIX layer of Microsoft's Services for Unix). There are a few apparent unknows: Would Wine load the .dll.so's? Since Interix uses PE for it's native format (running on Windows, duh), Would Wine load the .dll.so's? Would it reject them being in PE format and having the 'POSIX Layer' attribute set, or could we hack on a patch to detect if Wine itself is running in said layer, and load them if it is? Would that even *work*? And how about detecting Winelib applications? It might get detected as a regular Windows app, and ... uh-oh... (let's just say it isn't pretty) There are several obvious pros: You can test Wine almost fully under Windows without mingling with Windows's native componets. This would allow for better and faster compatability tests. We could also see what "unknowns" exist in Interix -- Althought not nessessrarly useful to Wine developers itself, it could mean a whole new generation of applications which are half-Unix, half-Windows, if the right holes are found. I am sure this will spark a LOT of debate.

March 24, 2006

Re: [opengl] Catch BadMatch errors before they can occur.

by Tony Lambregts

Tomas Carnecky wrote: > Lionel Ulmer wrote: >> On Fri, Mar 24, 2006 at 08:48:16PM +0100, Tomas Carnecky wrote: >>> so.. what about splitting 'opengl' up into 'opengl' (all the opengl >>> functions) and 'oglsetup' with the setup/wgl/pbuffer etc. functions ? >> Why not 'wgl' ? So we would have 'opengl' for 'core' functions and 'wgl' for >> the rest. >> > > ok.. here is a patch, but I can't make it work. Maybe someone else sees > the bug. > What is the problem. this is from a log of Google using your patch and WINEDBUG="+wgl,+opengl" trace:wgl:wglMakeCurrent returning True trace:opengl:wine_glGetString (7939) trace:wgl:internal_glGetString GL_EXTENSIONS reported: -- Tony Lambregts

March 24, 2006

firefox dogfooding on 0.9.10 - png bux FIXED.

by Segin

As of 0.9.10, the bug which caused all PNGs in Firefox to appear inverse is fixed. Also, for developers with slower machines, try using Mozilla 1.7.x, it's much much faster than Firefox. It may not have *as many* bugs, but it still brings up the same exact OLE problems which Firefox does, so using it is just as useful here.

March 24, 2006

Re: [opengl] Catch BadMatch errors before they can occur.

by Tomas Carnecky

Lionel Ulmer wrote: > On Fri, Mar 24, 2006 at 08:48:16PM +0100, Tomas Carnecky wrote: >> so.. what about splitting 'opengl' up into 'opengl' (all the opengl >> functions) and 'oglsetup' with the setup/wgl/pbuffer etc. functions ? > > Why not 'wgl' ? So we would have 'opengl' for 'core' functions and 'wgl' for > the rest. > ok.. here is a patch, but I can't make it work. Maybe someone else sees the bug. tom

March 24, 2006

What is the reason to use GL_FRONT_LEFT in wglMakeCurrent()

by Tomas Carnecky

GL_FRONT and GL_FRONT_LEFT mean the same unless the drawable is stereo. And I don't think PBuffers or Pixmaps can be stereo, so is there any special reason to use GL_FRONT_LEFT ? Or is it because the spec sais so? tom

March 24, 2006

Re: GetExitCodeProcess always returns 1

by Dmitry Timoshkov

"Igor Sysoev" <is(a)rambler-co.ru> wrote: > The attached patch is the same patch but for Wine-0.9.10. > I've tested it on FreeBSD 6.1. Please send it to wine-patches. If it's not included within next week or so I'd suggest to ask Alexandre directly what are his preferences in fixing this problem. -- Dmitry.

March 24, 2006

Page fault xmlspy 2006 wine .9.10

by Grant Lewis

It's repeatable. I can launch the progam fine but when I click in certain parts of the gui I generate the page fault and the program dies. wine: Unhandled page fault on write access to 0x0000001f at address 0x7d62d6 (th read 0009), starting debugger... WineDbg starting on pid 0x8 First chance exception: page fault on read access to 0x00000000 in 32-bit code ( 0x7ffa7292). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:7ffa7292 ESP:7fbfec74 EBP:7fbfed3c EFLAGS:00210246( - 00 -RIZP1) EAX:00000000 EBX:7ffd5280 ECX:00000000 EDX:00000000 ESI:0000001f EDI:00000002 Stack dump: 0x7fbfec74: 7fbfec90 00000001 00000000 00000c28 0x7fbfec84: 7fbff174 7ffa09d0 00000001 7ffd5280 0x7fbfec94: 0000001f 00000002 7fbfed3c 7fbfec74 0x7fbfeca4: 7ffa7283 00000001 80000000 00000000 0x7fbfecb4: 7ffa4dc9 7ffa406d 00000000 7ff9afea 0x7fbfecc4: 7ffd5280 7e1699a8 00000048 7ff9b0af Backtrace: =>1 0x7ffa7292 RtlImageNtHeader+0x72 in ntdll (0x7ffa7292) 2 0x7ffa757a RtlImageDirectoryEntryToData+0x3a in ntdll (0x7ffa757a) 3 0x7fc43dbf UnhandledExceptionFilter+0x4df in kernel32 (0x7fc43dbf) 4 0x7ffa0a65 __wine_exception_handler+0x95 in ntdll (0x7ffa0a65) 5 0x7ffbbb99 call_exception_handler+0x29 in ntdll (0x7ffbbb99) 6 0x7ffbbb6d EXC_CallHandler+0x1d in ntdll (0x7ffbbb6d) 7 0x7ffa040f in ntdll (+0x1040f) (0x7ffa040f) 8 0x7ffa059b __regs_RtlRaiseException+0x2b in ntdll (0x7ffa059b) 9 0x7ffbc2ac in ntdll (+0x2c2ac) (0x7ffbc2ac) 10 0xdeadbabe (0xdeadbabe) 11 0x00000000 (0x00000000) 0x7ffa7292 RtlImageNtHeader+0x72 in ntdll: cmpw $0x5a4d,0x0(%eax) Modules: Module Address Debug info Name (98 modules) PE 0x00400000-014eb000 Deferred xmlspy PE 0x10000000-1002e000 Deferred ssce5332 ELF 0x7bf00000-7bf03000 Deferred <wine-loader> ELF 0x7ed0b000-7ed20000 Deferred midimap<elf> \-PE 0x7ed10000-7ed20000 \ midimap ELF 0x7ee3e000-7ee5f000 Deferred msacm32<elf> \-PE 0x7ee50000-7ee5f000 \ msacm32 ELF 0x7ee5f000-7ee76000 Deferred msacm<elf> \-PE 0x7ee70000-7ee76000 \ msacm ELF 0x7ee76000-7ef4a000 Deferred libcrypto.so.0.9.7 ELF 0x7ef4a000-7ef72000 Deferred libssl.so.0.9.7 ELF 0x7ef72000-7ef8a000 Deferred libcups.so.2 ELF 0x7ef8c000-7efa0000 Deferred msimg32<elf> \-PE 0x7ef90000-7efa0000 \ msimg32 ELF 0x7f08e000-7f0bd000 Deferred uxtheme<elf> \-PE 0x7f0a0000-7f0bd000 \ uxtheme ELF 0x7f0bd000-7f0d5000 Deferred ximcp.so.2 ELF 0x7f0d5000-7f0d8000 Deferred xlcdef.so.2 ELF 0x7f0d8000-7f136000 Deferred libgl.so.1 ELF 0x7f14c000-7f1fb000 Deferred libx11.so.6 ELF 0x7f1fb000-7f26c000 Deferred winex11<elf> \-PE 0x7f210000-7f26c000 \ winex11 ELF 0x7f26c000-7f287000 Deferred libexpat.so.0 ELF 0x7f287000-7f2a9000 Deferred libfontconfig.so.1 ELF 0x7f2ab000-7f2bf000 Deferred libice.so.6 ELF 0x7f2bf000-7f321000 Deferred libfreetype.so.6 ELF 0x7f328000-7f330000 Deferred libxcursor.so.1.0.2 ELF 0x7f330000-7f337000 Deferred libxrender.so.1 ELF 0x7f337000-7f390000 Deferred msvcrt<elf> \-PE 0x7f350000-7f390000 \ msvcrt PE 0x7f390000-7f3cb000 Deferred oraclm32 ELF 0x7f3cf000-7f3da000 Deferred libxext.so.6 ELF 0x7f3da000-7f3f4000 Deferred imm32<elf> \-PE 0x7f3e0000-7f3f4000 \ imm32 ELF 0x7f3f4000-7f46d000 Deferred winmm<elf> \-PE 0x7f400000-7f46d000 \ winmm ELF 0x7f46d000-7f48d000 Deferred odbc32<elf> \-PE 0x7f480000-7f48d000 \ odbc32 ELF 0x7f48d000-7f4b2000 Deferred ws2_32<elf> \-PE 0x7f4a0000-7f4b2000 \ ws2_32 ELF 0x7f4b2000-7f4cb000 Deferred wsock32<elf> \-PE 0x7f4c0000-7f4cb000 \ wsock32 ELF 0x7f4cb000-7f4e7000 Deferred mpr<elf> \-PE 0x7f4d0000-7f4e7000 \ mpr ELF 0x7f4e7000-7f522000 Deferred wininet<elf> \-PE 0x7f4f0000-7f522000 \ wininet ELF 0x7f522000-7f541000 Deferred cabinet<elf> \-PE 0x7f530000-7f541000 \ cabinet ELF 0x7f541000-7f56d000 Deferred urlmon<elf> \-PE 0x7f550000-7f56d000 \ urlmon ELF 0x7f56d000-7f5e6000 Deferred oleaut32<elf> \-PE 0x7f580000-7f5e6000 \ oleaut32 ELF 0x7f5e6000-7f5fa000 Deferred olepro32<elf> \-PE 0x7f5f0000-7f5fa000 \ olepro32 ELF 0x7f5fa000-7f613000 Deferred oledlg<elf> \-PE 0x7f600000-7f613000 \ oledlg ELF 0x7f613000-7f639000 Deferred winspool<elf> \-PE 0x7f620000-7f639000 \ winspool ELF 0x7f639000-7f6d2000 Deferred comctl32<elf> \-PE 0x7f640000-7f6d2000 \ comctl32 ELF 0x7f6d2000-7f6ee000 Deferred iphlpapi<elf> \-PE 0x7f6e0000-7f6ee000 \ iphlpapi ELF 0x7f6ee000-7f729000 Deferred rpcrt4<elf> \-PE 0x7f700000-7f729000 \ rpcrt4 ELF 0x7f729000-7f79b000 Deferred ole32<elf> \-PE 0x7f740000-7f79b000 \ ole32 ELF 0x7f79b000-7f7e7000 Deferred shlwapi<elf> \-PE 0x7f7b0000-7f7e7000 \ shlwapi ELF 0x7f7e7000-7f896000 Deferred shell32<elf> \-PE 0x7f800000-7f896000 \ shell32 ELF 0x7f896000-7f92c000 Deferred comdlg32<elf> \-PE 0x7f8a0000-7f92c000 \ comdlg32 ELF 0x7f92c000-7f963000 Deferred advapi32<elf> \-PE 0x7f940000-7f963000 \ advapi32 ELF 0x7f963000-7f9e3000 Deferred gdi32<elf> \-PE 0x7f970000-7f9e3000 \ gdi32 ELF 0x7f9e3000-7faf0000 Deferred user32<elf> \-PE 0x7fa00000-7faf0000 \ user32 ELF 0x7fc01000-7fc05000 Deferred libxxf86vm.so.1 ELF 0x7fc05000-7fcf0000 Export kernel32<elf> \-PE 0x7fc20000-7fcf0000 \ kernel32 ELF 0x7fe01000-7fe06000 Deferred libxxf86dga.so.1 ELF 0x7fe06000-7fe10000 Deferred libnss_files.so.2 ELF 0x7fe10000-7fe1a000 Deferred libnss_nis.so.2 ELF 0x7fe1a000-7fe2f000 Deferred libnsl.so.1 ELF 0x7fe31000-7fe40000 Deferred libz.so.1 ELF 0x7fe42000-7fe45000 Deferred libxrandr.so.2 ELF 0x7fe45000-7fe68000 Deferred libm.so.6 ELF 0x7fe68000-7ff5e000 Deferred libwine_unicode.so.1 ELF 0x7ff5f000-7ff67000 Deferred libsm.so.6 ELF 0x7ff67000-7ff70000 Deferred libnss_compat.so.2 ELF 0x7ff74000-7ffe0000 Export ntdll<elf> \-PE 0x7ff90000-7ffe0000 \ ntdll ELF 0xb7dd9000-b7ddd000 Deferred libdl.so.2 ELF 0xb7ddd000-b7ef8000 Deferred libc.so.6 ELF 0xb7ef8000-b7f4a000 Deferred libpthread.so.0 ELF 0xb7f60000-b7f7a000 Deferred libwine.so.1 ELF 0xb7f7b000-b7f92000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 00000008 (D) Z:\opt\Altova\XMLSpy2006\XMLSpy.exe 0000000f -1 0000000e 0 0000000d 0 0000000c 0 0000000a 0000000b 0 00000008 (D) Z:\opt\Altova\XMLSpy2006\XMLSpy.exe 00000009 0 <==

March 24, 2006

Re: [winedoc] Resend Update to documentation

by Jeff Latimer

Dimi Paun wrote: > -- you need to refine a bit what your trying to say, > I can not apply it in the current form. > > > Looking over the file again I see you paraphrased the patch for me. Looks good so I withdraw mine. Jeff

March 24, 2006

wine in "online news"

by Stefan Leichter

The german publishing company Heise Verlag reported in his online new http://www.heise.de/newsticker/meldung/71270 the availability of a plugin running Photoshop filters in GIMP on Linux using wine. For details look the authors blog at http://tml-blog.blogspot.com/2006/02/photoshop-filters-in-gimp-on-linux.html There might be a similar article in english language somewere in the WEB. Bye Stefan

March 24, 2006

Re: GetExitCodeProcess always returns 1

by Igor Sysoev

On Thu, 23 Mar 2006, Igor Sysoev wrote: > 3 years ago I reported that on FreeBSD Wine-20030508's > GetExitCodeProcess() always returns 1: > http://www.winehq.org/hypermail/wine-devel/2003/06/0100.html > This report included a small test case. > > It was fixed by patch: > http://www.winehq.org/hypermail/wine-devel/2003/06/0381.html > > and I used the patched Wine-20030508 to run MSVC, > OpenWatcom C, and Borland C in a command line. > > Recenty I build Wine-0.9.10 from ports on FreeBSD 6.1, but > GetExitCodeProcess() still always returns 1. The attached patch is the same patch but for Wine-0.9.10. I've tested it on FreeBSD 6.1. Igor Sysoev http://sysoev.ru/en/

March 24, 2006

Re: [opengl] Catch BadMatch errors before they can occur.

by Tomas Carnecky

Lionel Ulmer wrote: > On Fri, Mar 24, 2006 at 08:20:08PM +0100, Tomas Carnecky wrote: >> When debugging opengl applications, I'm usually not interested in the >> *Swap*Buffers() functions, but in context creation, pbuffers stuff etc. >> It just writes unnecessary messages into the console. When debugging an >> application that crashes after 10 minutes it makes the log very big. If >> someone is interested in the *Swap*Buffers() functions, he still can >> enable them, but for the majority of the cases its useless. > > Strange as there are 'opengl' TRACEs for ALL OpenGL functions and extensions > so I would guess that those would vastly dwarf the SwapBuffer traces (except > if you have an application that does not draw anything on screen and just > does swapping its buffers :-) ). > That's what I also thought.. now it comes to my mind! I may have compiled with with debug disabled and now with debug enabled make didn't recompile the file with all the 'real' OpenGL functions. so.. what about splitting 'opengl' up into 'opengl' (all the opengl functions) and 'oglsetup' with the setup/wgl/pbuffer etc. functions ? tom

March 24, 2006

Re: [opengl] Catch BadMatch errors before they can occur.

by Lionel Ulmer

On Fri, Mar 24, 2006 at 08:48:16PM +0100, Tomas Carnecky wrote: > so.. what about splitting 'opengl' up into 'opengl' (all the opengl > functions) and 'oglsetup' with the setup/wgl/pbuffer etc. functions ? Why not 'wgl' ? So we would have 'opengl' for 'core' functions and 'wgl' for the rest. Lionel -- Lionel Ulmer - http://www.bbrox.org/

March 24, 2006

Re: [opengl] Catch BadMatch errors before they can occur.

by Lionel Ulmer

On Fri, Mar 24, 2006 at 08:20:08PM +0100, Tomas Carnecky wrote: > When debugging opengl applications, I'm usually not interested in the > *Swap*Buffers() functions, but in context creation, pbuffers stuff etc. > It just writes unnecessary messages into the console. When debugging an > application that crashes after 10 minutes it makes the log very big. If > someone is interested in the *Swap*Buffers() functions, he still can > enable them, but for the majority of the cases its useless. Strange as there are 'opengl' TRACEs for ALL OpenGL functions and extensions so I would guess that those would vastly dwarf the SwapBuffer traces (except if you have an application that does not draw anything on screen and just does swapping its buffers :-) ). Lionel -- Lionel Ulmer - http://www.bbrox.org/

March 24, 2006