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 25, 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 25, 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 25, 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 25, 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 25, 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 25, 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 25, 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 25, 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

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

by Tomas Carnecky

Lionel Ulmer wrote: >> Oh, and this patch creates a new debug-channel 'swapbuffers' and puts >> both opengl swapbuffers functions into it. > > What is the reason for this change ? > 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. That was basically the idea. I'll rewrite the patch and split it up, the GLX spec violation thing could be committed without breaking applications, other changes have to be tested first :) tom

March 24, 2006

Re: Winetools -> wine doors

by Dr J A Gow

> 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! John.

March 24, 2006

Re: Winetools -> wine doors

by Segin

Karl Lattimer 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 [...] > Is THIS enough to get rid of Winetools?

March 24, 2006

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

by Igor Sysoev

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 ? Igor Sysoev http://sysoev.ru/en/

March 24, 2006

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

by Lionel Ulmer

> Oh, and this patch creates a new debug-channel 'swapbuffers' and puts > both opengl swapbuffers functions into it. What is the reason for this change ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

March 24, 2006

Re: CreateScalableFontResourceA: what does it mean?

by Hiji

--- Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > Friday, March 24, 2006, 12:44:46 AM, Hiji wrote: > > There is this program, Cakewalk Sonar XL 2 > > > (http://appdb.winehq.org/appview.php?versionId=2615) > > that I always try to run on Wine. The good news > is, I > > can get it running, not smoothly, but it does run. > > > However, it tries to utilize one of its own fonts, > and > > always stubs on CreateScalableFontResourceA. > > > It hits this: > > fixme:font:CreateScalableFontResourceA > > > (0,"C:\\PROG~FBU\\Cakewalk\\SONA~3TJ\\TTSNOTE.FOR","C:\\PROG~FBU\\Cakewalk\\SONA~3TJ\\TTSNOTE.TTR",(null)): > > stub > > > Then the app tells me the following in a popup: > > "Cannot create the Staff view musical symbol > font." > > > Anybody know what this means or have any > workaround > > for making CreateScalableFontResourceA work? I've > > seen this problem since Dec. 2004, but since it > hasn't > > gone away, I thought I'd pipe up and ask about it. > > > Thanks in advance! > > Hiji > > AFAIK that was the only way for any program to > "temporary" install it's > fonts. Temporary means that the font will be > available to the current > session only (no entirely sure here if font will > stay after program > closes or will be available). > > Vitaliy Thanks for the tidbit - it makes things a lot clearer! The TTSNOTE.FOR font, I found, resides within the application's folder in Program Files and appears to go through this motion every time it starts up. So, my guess is that it goes away after the program closes. I know that on my Win install, the app never permanently moves the font to my system fonts folder. Anybody have a workaround for making this work? Thanks! Hiji __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

March 24, 2006

Problem with resolution

by Frederico Bertucci

Hello guys, I got a different problem I believe I'm trying run a application to develop interactive class, called VisualClass, if I start it with my kde resolution in 1280x1024, doesnt works, if i start it with my kde resolution in 800x600, doesnt works too, BUT if I start it with 800x600 and after change to 1280x1024 as soon its load, simply works, with 800x600, but works... I ckecked all configurations and components from wine, fonts, everything that I remember... There are anything to do ??... I am in a migration program, and this is one of the main of project... Tks. -- Frederico Bertucci e-mail / msn: fred(a)netbil.com.br www.netbil.com.br NetBil - Redes e Internet 18-3659-2444 XxX Linux for work Linux for fun XxX ________________________________________________ :: NetBil :: :: A escolha certa em Internet ::

March 24, 2006

Wine on FC5

by Kevin DeKorte

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been able to get Wine working on FC5, both from source and from RPM and neither seems to have the smooth font support. Is there some new option that is needed for FC5 support. I had Notes 6.51 working very nice under FC4, but it has some weird drawing issues in FC5. I'm guessing it has something to do with the new xorg packages, but any ideas would be helpful. Thanks, Kevin - -- Get my public GnuPG key from http://keyserver.veridis.com:11371/export?id=7574690260641978351 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEJCj2aR60qN0tF+8RApaaAKCo8pj6FAgoK7vHzBnGJ0jRZsV+5ACeL+kt jPJPYh8VeA8m2YIB2jreCsA= =1vFw -----END PGP SIGNATURE-----

March 24, 2006

Re: Race condition in keyboard code?

by Dmitry Timoshkov

"Peter Åstrand" <astrand(a)cendio.se> wrote: > What about using the thread_input->keystate, just as for Shift, Control, > and NumLock? > > ToUnicodeEx does have a lpKeyState argument, so to me, it seems very wrong > that a static, global variable is needed as well. I don't see how a thread local keystate would solve a problem with 2 repetitive KeyPress events you reported initially as being the source of the problem. > The current implementation has another drawback: AltGr key presses never > reaches the applications. In Windows, applications recieves VK_CONTROL, > VK_MENU when AltGr is pressed. Feel free to investigate it. -- Dmitry.

March 24, 2006

Re: What happened to the Fedora packages?

by Michel Ludwig

On Thu 23 Mar 2006 23:40, Andreas Bierfert wrote: > > Nice and decent Fedora Wine packages are in Fedora Extras: > > I am interested in the _decent_ part... always open for suggestions :) > Well, decent in the sense that the packages are well-made, or alternatively: you've done a great job ! :-) Michel

March 24, 2006

Re: SERVER: Only reset the notify event flag if there's no events pending.

by Alexandre Julliard

Mike McCormack <mike(a)codeweavers.com> writes: > diff --git a/server/change.c b/server/change.c > index 4349d7e..67a47af 100644 > --- a/server/change.c > +++ b/server/change.c > @@ -1130,7 +1130,7 @@ DECL_HANDLER(read_directory_changes) > dir->signaled--; > > /* clear the event */ > - if (event) > + if (event && !dir->signaled) > reset_event( event ); This breaks the tests: change.c:518: Test failed: action wrong change.c:522: Test failed: ov.Internal wrong change.c:523: Test failed: ov.InternalHigh wrong change.c:582: Test failed: should timeout change.c:590: Test failed: ov.Internal wrong change.c:603: Test failed: should timeout change.c:669: Test failed: should timeout make[1]: *** [change.ok] Error 7 -- Alexandre Julliard julliard(a)winehq.org

March 24, 2006

Re: CreateScalableFontResourceA: what does it mean?

by Vitaliy Margolen

Friday, March 24, 2006, 12:44:46 AM, Hiji wrote: > There is this program, Cakewalk Sonar XL 2 > (http://appdb.winehq.org/appview.php?versionId=2615) > that I always try to run on Wine. The good news is, I > can get it running, not smoothly, but it does run. > However, it tries to utilize one of its own fonts, and > always stubs on CreateScalableFontResourceA. > It hits this: > fixme:font:CreateScalableFontResourceA > (0,"C:\\PROG~FBU\\Cakewalk\\SONA~3TJ\\TTSNOTE.FOR","C:\\PROG~FBU\\Cakewalk\\SONA~3TJ\\TTSNOTE.TTR",(null)): > stub > Then the app tells me the following in a popup: > "Cannot create the Staff view musical symbol font." > Anybody know what this means or have any workaround > for making CreateScalableFontResourceA work? I've > seen this problem since Dec. 2004, but since it hasn't > gone away, I thought I'd pipe up and ask about it. > Thanks in advance! > Hiji AFAIK that was the only way for any program to "temporary" install it's fonts. Temporary means that the font will be available to the current session only (no entirely sure here if font will stay after program closes or will be available). Vitaliy

March 24, 2006

Winetools -> wine doors

by Karl Lattimer

I read your story about winetools a couple weeks ago around the same time that I tried using winetools on FC5 test 3, it didn't go well with winetools and I was looking for another solution and couldn't find one that fitted well with my criteria. I started thinking of packages like RPMs and started breaking down a wine application installation into what we would need to run it directly from the application menu. What I came up with this is, its pretty raw right now, its simply a small self contained package for managing the install process of a wine application, soon I'm going to start work on creating a package repository and the package browser but would really like to use the appdb for supplementary information, i.e. screenshots version compatibility etc... http://www.qdh.org.uk/wordpress/?cat=6 I have also considered having a way of making apps install gobally on a machine so any and every user has access to them, and considered using inotify to watch events and provide a way of handling this. This is still in the beginning stages and I would be grateful for any input you may have. I was very interested in what was published here, http://www.winehq.org/?issue=308#Winetools..%20part%20II 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 there are some useful little bits in there which I have been cannibalising when necessary into my own application. The beauty of this is that it is only an application shell, in theory the appdb could be the central configuration repository containing all the information to make an app work. Available apps can be browsed, downloaded if possible or installed from a cd drive with minimal fuss. I have one other who has joined in the project, his name is Alex Doukas and I believe he has also recently joined wine-devel. Right now we're at the stage of building up some script archives and starting to put together application packs for the most important stuff, I will be working on the downloaders/xml parsers within the next couple of weeks and hopefully we should soon have a working application where the community keeps it up to date. To prevent duplication of work I would suggest that suggestions to my project will be accepted, I hope to provide some public space for bug tracking etc... in the next couple of weeks and even public SVN. I currently have this configured and running but unfortunately do not have a great deal of bandwidth. The more people who join in the better, python programmers especially welcome, any scripts should eventually be posted to the bugzilla. Once the application db and my application fit together nicely we could have users publishing scripts in the appdb.

March 24, 2006

Re: wine.inf: Add a shdocvw.dll stub dll to the system directory

by Stefan Dösinger

> Yes, if there's evidence that an app references a dll (or exe) as a file > then it should be put into the FakeDllsSection. The Need for Speed Porsche Unleashed demo requires ddraw.dll in the system32 directory, otherwise it complains that it can't find directx.

March 24, 2006

Re: [opengl] check drawable and context Visual IDs in wglMakeCurrent ()

by Stefan Dösinger

Hi, > maybe it was because of the earlier opengl patch 'Store GL context in > TEB'. But I didn't notice such an increase then.. only from ~20 -> ~30fps Hm. Something increased the speed of half-life / counter strike drastically. It isn't your patch, but some change that is in CVS already. The change is this: Before half-life(non-steam) was running at 40-71 fps, depending on the situation. Now it's runs at 70-71 fps constantly. Counter-Strike 1.6(steam) ran at 60-71 fps before if there were no bots in the game. Adding 8 bots(or maybe human players, didn't check that) made the fps drop to 20 in many rendering situations. Now this doesn't happen any more, the game runs at 60-71 fps in general, only if much players are visible, it may drop down to 30 fps. Jedi academy got a major speed boost too, but that's mostly because I activated compressed textures in the game. Btw, the card is a Radeon Mobility M9, with the dri driver from Xorg 7.0.

March 24, 2006

Re: Race condition in keyboard code?

by Peter Åstrand

On Fri, 24 Mar 2006, Dmitry Timoshkov wrote: >> ? I do understand why this happens: X11DRV_ToUnicodeEx uses the global, >> static variable AltGrMask. Is this a bug? > > In X11DRV_ToUnicodeEx we need to restore XKeyEvent from the previous > KeyPress event. If you have a better idea how to do it without using > global variables please let us know. What about using the thread_input->keystate, just as for Shift, Control, and NumLock? ToUnicodeEx does have a lpKeyState argument, so to me, it seems very wrong that a static, global variable is needed as well. TranslateMessage calls GetKeyboardState just before ToUnicode. MSDN documents GetKeyboardState as: "The status changes as a thread removes keyboard messages from its message queue." My interpretation is that this means that ToUnicodeEx consider how the modifiers *was* rather then what they *are*. The current implementation has another drawback: AltGr key presses never reaches the applications. In Windows, applications recieves VK_CONTROL, VK_MENU when AltGr is pressed. -- Peter Åstrand ThinLinc Chief Developer Cendio http://www.cendio.se Teknikringen 3 583 30 Linköping Phone: +46-13-21 46 00

March 24, 2006

Re: wine.inf: Add a shdocvw.dll stub dll to the system directory

by Mike McCormack

Louis. Lenders wrote: > What about adding a few more, like opengl32 > (http://bugs.winehq.org/show_bug.cgi?id=3877) and some > more (there are more of these bugs in bugzilla that > can be solved that way, i could make a quick list of > them if necessary) Regards Louis Sure. How about sending a patch to wine-patches adding it to wine.inf? Mike

March 24, 2006

Re: [opengl] check drawable and context Visual IDs in wglMakeCurrent()

by Molle Bestefich

Tomas Carnecky wrote: > Also, it would be great if we could put the *Swap*Buffers() into their > own log domain, something like 'swapbuffers', because the trace is > usually useless, only when you explicitly look whether these functions > are called or not, otherwise they only fill the log with garbage. Use grep -vE? (Or completely remove it if it's useless, if someone needs to specifically debug *Swap*Buffers() they can add trace lines themselves..)

March 24, 2006

Re: wine.inf: Add a shdocvw.dll stub dll to the system directory

by Hans Leidekker

On Thursday 23 March 2006 23:05, Louis. Lenders wrote: > What about adding a few more, like opengl32 Yes, if there's evidence that an app references a dll (or exe) as a file then it should be put into the FakeDllsSection. -Hans

March 24, 2006

CreateScalableFontResourceA: what does it mean?

by Hiji

There is this program, Cakewalk Sonar XL 2 (http://appdb.winehq.org/appview.php?versionId=2615) that I always try to run on Wine. The good news is, I can get it running, not smoothly, but it does run. However, it tries to utilize one of its own fonts, and always stubs on CreateScalableFontResourceA. It hits this: fixme:font:CreateScalableFontResourceA (0,"C:\\PROG~FBU\\Cakewalk\\SONA~3TJ\\TTSNOTE.FOR","C:\\PROG~FBU\\Cakewalk\\SONA~3TJ\\TTSNOTE.TTR",(null)): stub Then the app tells me the following in a popup: "Cannot create the Staff view musical symbol font." Anybody know what this means or have any workaround for making CreateScalableFontResourceA work? I've seen this problem since Dec. 2004, but since it hasn't gone away, I thought I'd pipe up and ask about it. Thanks in advance! Hiji __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

March 24, 2006

Re: Bugzilla: Duplicates

by Tony Lambregts

Tony Lambregts wrote: > Jeremy Newman wrote: >> On Wed, 2006-03-22 at 21:22 +0100, Tobias Burnus wrote: >> >>> Hello, >>> >>> >>>> Just found, that gcc has "Most frequently reported Bugs": >>>> http://gcc.gnu.org/bugzilla/duplicates.cgi >>>> >>>> And since we have also bugzilla, i tested >>>> http://bugs.winehq.org/duplicates.cgi >>>> The Page is present, but not configured to be useful for wine. >>>> >>>> The code is in the cvs, but I'm unable to help here (perl). >>>> (Browse the cvs: "http://cvs.winehq.org/cvsweb/bugzilla/") >>>> >>>> >>> >>> Hmm, in principle one only needs to tweek at >>> http://bugs.winehq.org/editparams.cgi the 'mostfreqthreshold' option. >>> >>> Running ./checksetup.pl doesn't harm either >>> >>> The essential task is to fill the duplicates table using the script: >>> http://cvs.winehq.org/cvsweb/bugzilla/collectstats.pl >>> You need to run it using cron. >>> >>> Tobias >>> > > When I try to run the collectstats.pl script I get this: > > > > wineowner(a)wine:~/opt/bugzilla$ ./collectstats.pl > > No value for param loginmethod at Bugzilla/Config.pm line 135. > > BEGIN failed--compilation aborted at Bugzilla/Auth.pm line 36. > > Compilation failed in require at Bugzilla.pm line 27. > > BEGIN failed--compilation aborted at Bugzilla.pm line 27. > > Compilation failed in require at ./collectstats.pl line 37. >> BEGIN failed--compilation aborted at ./collectstats.pl line 37. > > >> I have not looked into the code to find why it does not work. Seems >> odd since the rest of bugzilla works fine. > > Looks like you need to give loginmethod a value in Bugzilla.pm. For > whatever reason this file is not part of CVS. > > I can look at my local copy of this file when I get home. > > -- > This is because we do not have loginmenthod defined in data/params 'letsubmitterchoosepriority' => 1, + 'loginmethod' => 'DB', 'loginnetmask' => '32', -- Tony Lambregts

March 24, 2006

[PATCH] server/mailslot.c doesn't compile on certain systems. [Added ChangeLog]

by Segin

I have noticed that including stdint.h to server/mailslot.c fixes it for me. Those on wine-patches and not wine-devel, please CC any replies. ChangeLog: Includes stdint.h in server/mailslot.c, added comment explaining why. --- server/mailslot.c.orig 2006-03-23 22:37:32.000000000 -0500 +++ server/mailslot.c 2006-03-23 22:40:32.000000000 -0500 @@ -34,6 +34,8 @@ #include <stdlib.h> #include <sys/time.h> #include <sys/types.h> +/* include stdint.h cause of some systems breaking */ +#include <stdint.h> #ifdef HAVE_SYS_IOCTL_H #include <sys/ioctl.h>

March 24, 2006

[PATCH] server/mailslot.c doesn't compile on certain systems.

by Segin

I have noticed that including stdint.h to server/mailslot.c fixes it for me. Those on wine-patches and not wine-devel, please CC any replies. --- server/mailslot.c.orig 2006-03-23 22:37:32.000000000 -0500 +++ server/mailslot.c 2006-03-23 22:40:32.000000000 -0500 @@ -34,6 +34,8 @@ #include <stdlib.h> #include <sys/time.h> #include <sys/types.h> +/* include stdint.h cause of some systems breaking */ +#include <stdint.h> #ifdef HAVE_SYS_IOCTL_H #include <sys/ioctl.h>

March 24, 2006

Re: GetExitCodeProcess always returns 1

by Dmitry Timoshkov

Hi Igor, "Igor Sysoev" <is(a)rambler-co.ru> wrote: >> Maybe Alexandre would accept patches to add a todo_wine_freebsd {} to the >> test suite where there's things that are hard to fix? having todo_wine_xxx for each platform 'xxx' where a test is failing sounds not very elegant. > It seems that I am the first person who ever run the Wine regression tests > on FreeBSD :) Actually the test results did not bother me too much. > The wrong exit code simply means that I could not use the "make" under > Wine on FreeBSD: "make" stops after the first command. Actually failing tests on FreeBSD is a worrisome sign. That means that some applications may fail without an apparent reason. It's really worth a further investigation for every failing test in the Wine test suite. -- Dmitry.

March 24, 2006

Re: Race condition in keyboard code?

by Dmitry Timoshkov

"Peter Åstrand" <astrand(a)cendio.se> wrote: > ? I do understand why this happens: X11DRV_ToUnicodeEx uses the global, > static variable AltGrMask. Is this a bug? In X11DRV_ToUnicodeEx we need to restore XKeyEvent from the previous KeyPress event. If you have a better idea how to do it without using global variables please let us know. -- Dmitry.

March 24, 2006

Re: rebar patch

by Mike McCormack

qingdoa daoo wrote: > Hi > Can i suggest a patch to wine's rebar src > > The patch is made against current cvs source. > [root(a)localhost comctl32]# diff -u rebar.c.cvs rebar.c > attach.diff > --- rebar.c.cvs 2006-03-24 09:53:28.000000000 +0800 > +++ rebar.c 2006-03-24 09:38:29.000000000 +0800 Sure, we like patches. Please send them to wine-patches(a)winehq.org. You might also consider doing the diff in the wine directory: cd wine diff -urp dlls/comctl32/rebar.c.cvs dlls/comctl32/rebar.c > attach.diff That makes it easier to apply the patch, because whoever applies it doesn't have to figure out that it's against a file in dlls/comctl32. Then attach it to your mail as you have, with a ChangeLog line, something like: ChangeLog: Let apps remember rebar layout across runs. Mike (who especially likes Qingdao pijiu)

March 24, 2006

Re: GoogleEarth

by Dimi Paun

On Thu, 2006-03-23 at 19:48 +0100, Francois Gouget wrote: > Is there a place where we collect changes we'd like to see/do in other > projects? It would be a good resource when the date of some 'Linux on > the desktop' summit nears... The wiki would be a good place, I guess. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

March 24, 2006

rebar patch

by qingdoa daoo

Hi Can i suggest a patch to wine's rebar src The patch is made against current cvs source. [root(a)localhost comctl32]# diff -u rebar.c.cvs rebar.c > attach.diff --- rebar.c.cvs 2006-03-24 09:53:28.000000000 +0800 +++ rebar.c 2006-03-24 09:38:29.000000000 +0800 @@ -2820,7 +2820,7 @@ } if (lprbbi->fMask & RBBIM_SIZE) - lprbbi->cx = lpBand->cx; + lprbbi->cx = lpBand->ccx; if (lprbbi->fMask & RBBIM_BACKGROUND) lprbbi->hbmBack = lpBand->hbmBack; @@ -2902,7 +2902,7 @@ } if (lprbbi->fMask & RBBIM_SIZE) - lprbbi->cx = lpBand->cx; + lprbbi->cx = lpBand->ccx; if (lprbbi->fMask & RBBIM_BACKGROUND) lprbbi->hbmBack = lpBand->hbmBack; It's a fix to the problem that apps can't remember rebar layout across runs. When apps exit, they often ask the rebar for current band info so that the next time they run, they can tell the rebar how to layout the bands. When they ask about the size of a band, current code passes them lpBand->cx, which is a value passed by apps at band creation time, validated and stored by rebar, and then never gets updated. So apps alway get the old size value, while lpBand->ccx as the name suggests is the current rebar size. Tested with some apps, and no regression observed. Source Insight works better, so is Internet Explorer. I have actually made more changes to rebar.c. Wondering if some could review this patch and submit it. So that I can suggest subsequent patches against the updated source. --------------------------------- Blab-away for as little as 1¢/min. Make PC-to-Phone Calls using Yahoo! Messenger with Voice.

March 24, 2006

Re: file.c:246: Test failed: shouldn't be able to delete a readonly file

by Tom Spear (Dustin Booker, Dustin Navea)

Mike McCormack wrote: > > Tom Spear (Dustin Booker, Dustin Navea) wrote: > >> Hmm.. I'm thinking that the test isn't doing it right then... Cause >> windows will let you delete a readonly file, but it prompts you first > > Deleting using the UI isn't the same as a program using DeleteFile(). > > Mike > Crap, you are right.. doing del in the command prompt returns access denied.... ok the test is right....

March 24, 2006

Re: file.c:246: Test failed: shouldn't be able to delete a readonly file

by Mike McCormack

Tom Spear (Dustin Booker, Dustin Navea) wrote: > Hmm.. I'm thinking that the test isn't doing it right then... Cause > windows will let you delete a readonly file, but it prompts you first Deleting using the UI isn't the same as a program using DeleteFile(). Mike

March 24, 2006

Re: file.c:246: Test failed: shouldn't be able to delete a readonly file

by Tom Spear (Dustin Booker, Dustin Navea)

Huw D M Davies wrote: > On Thu, Mar 23, 2006 at 01:24:53PM -0500, Matt Finnicum wrote: > >> I'm at a windows XP machine right now. >> >> I have no trouble deleting read-only files - I get the dialog informing me >> it's read-only, but then it allows me to delete it. >> >> Is it the same on 95/98? >> > > How are you trying to delete them? The question is whether the > DeleteFile() function works as tested - the way to find this is to run > that test on Windows XP. > > Huw. > > I usually do Shift+Delete (skip the recycle bin), but delete will work to move a readonly file to the recycle bin as well... Tom

March 24, 2006

Re: file.c:246: Test failed: shouldn't be able to delete a readonly file

by Tom Spear (Dustin Booker, Dustin Navea)

Huw D M Davies wrote: > On Thu, Mar 23, 2006 at 06:04:21AM -0600, Tom Spear (Dustin Booker, Dustin Navea) wrote: > >> Umm.. I'm not totally sure this is 100% in conformance with windows. >> When I try to delete a readonly file, I get a dialog telling me that it >> is readonly, and asking me if I really want to delete it. If we are >> completely disallowing removal of a readonly file (by windows standard, >> not linux' standard), then it is incorrect and should be fixed... >> >> > > Well the test passes on Win 2000. > > C:\>kernel32_crosstest.exe file > file: 494243 test executed, 0 marked as todo, 0 failures. > > Huw. > Hmm.. I'm thinking that the test isn't doing it right then... Cause windows will let you delete a readonly file, but it prompts you first Tom

March 24, 2006

Re: [opengl] check drawable and context Visual IDs in wglMakeCurrent()

by Raphael

On Thursday 23 March 2006 20:26, Tomas Carnecky wrote: > Tomas Carnecky wrote: > > Changelog: > > - fail if the drawable and context Visual IDs don't match. > > > > why? because this will produce a BadMatch and crash the application so > > instead of the crash rather return GL_FALSE and let the application > > handle it. > > Please don't apply this patch yet. It fixes one case but there is more > to be aware of. > > This BadMatch bug is triggered if an application creates a window (with > a default Visual ID) and a custom (non-default) pixel format, the IDs > were 0x21 and 0x23 in my case (glxinfo/xdpyinfo report Visual ID in the > range from 0x21 to 0x70). yes, the classic wine problem :( > But! I've seen that World of Warcraft calls wglMakeCurrent() with a > darawable that has Visual ID 0x71 and a context with Visual ID 0x21. Now > 0x71 is not defined (according to the glxino output) but it works fine, > eg. glXMakeCurrent() doesn't produce the X Error in that case. > So I went up the backtrace, into create_glxpixmap(). I let this function > fail if it would produce a X Error, eg. if "depth of pixmap does not > match the GLX_BUFFER_SIZE value of vis". > Then I had to modify wglMakeCurrent() to respect the create_glxpixmap() > failure and return FALSE. Works good so far, framerate in WoW went up > from ~20 to up to 70 fps, average is somewhere between 40-50 !!! This is > incredible. good news. But try to see if users aren't too impacted (ie. diff between nvidia/ATI drivers) > So.. in this attachment you'll find a patch that does what I've just > described. I can't test it on anything else than WoW, so if someone > would please review it and test with outher opengl/d3d applications it > would be great. Sorry no time to test ii :( but send it to wine-users to see > Also, it would be great if we could put the *Swap*Buffers() into their > own log domain, something like 'swapbuffers', because the trace is > usually useless, only when you explicitly look whether these functions > are called or not, otherwise they only fill the log with garbage. > > thanks > tom Regards, Raphael

March 24, 2006

Re: [opengl] check drawable and context Visual IDs in wglMakeCurrent ()

by Raphael

On Friday 24 March 2006 00:13, Tomas Carnecky wrote: > Stefan Dösinger wrote: > > Hi, > > > >> So.. in this attachment you'll find a patch that does what I've just > >> described. I can't test it on anything else than WoW, so if someone > >> would please review it and test with outher opengl/d3d applications it > >> would be great. > > > > No effects noticed with Half-life 1(GL), Warcraft III(GL and D3D) and > > Jedi Academy(GL). > > maybe it was because of the earlier opengl patch 'Store GL context in > TEB'. But I didn't notice such an increase then.. only from ~20 -> ~30fps > > > That patch gave me a hint for a possible reason for the WineD3D slowness > > with a few games :) > > good, at least something :) > > > Something else.. now I know why there is this VisualID mismatch. Someone > didn't read the GLX spec. It's me. i have read the spec. And it's work (but not really well documented) :) > in opengl32/wgl.c:describeDrawable() you call > glXQueryDrawable() with GLX_VISUAL_ID, but that's not allowed ! only > GLX_FBCONFIG_ID and three others, according to the GLX 1.3/1.4 spec [1]. > > According to the spec, you can get the GLXFBConfig from a GLXDrawable > using glXQueryDrawable() and then the Visual from the GLXFBConfig using > glXGetFBConfigAttrib(). Yes i now that, problem is that glXQueryDrawable is not always available (only nvidia drivers implement it). So expect to break major part of wine users Regards, Raphael

March 24, 2006

Re: build failure on Gentoo Linux, recommended fix included.

by Mike McCormack

Segin wrote: > Suggested fix: Include stdint.h in server/mailslot.c > > (Patch not included due to the simplicity of code changes) Please include the patch and send this mail to wine-patches instead, otherwise you're just making more work for somebody else. Mike

March 24, 2006

Re: What happened to the Fedora packages?

by Neal Gompa

I just decided to use the yum packages suggested earlier... and yes, it fails, then crashes! anyway, thanks! On 3/23/06, Francois Gouget <fgouget(a)free.fr> wrote: > > On Wed, 22 Mar 2006, Neal Gompa wrote: > > > Well, the system is a Pentium 4 2.8GHz HyperThreading with 512MB RAM, so > > that is not the problem! It just always fails.... > > Oh, the compilation fails? That's not the same as the computer > crashing... > > Maybe you can send us the error message and then we can help you. > > -- > Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ > Demander si un ordinateur peut penser revient à demander > si un sous-marin peut nager. >

March 24, 2006

build failure on Gentoo Linux, recommended fix included.

by Segin

Kernel 2.6.15-gentoo-r7 (2.6.15.7) glibc 2.3.6 (NTPL/NTPL only) Build error in server/mailslot.c: mailslot.c: In function 'mailslot_next_msg_size': mailslot.c:221: error: 'uint32_t' undeclared (first use in this function) mailslot.c:221: error: (Each undeclared identifier is reported only once mailslot.c:221: error: for each function it appears in.) make[1]: *** [mailslot.o] Error 1 make[1]: Leaving directory `/var/tmp/portage/wine-0.9.10/work/wine-0.9.10/server' Suggested fix: Include stdint.h in server/mailslot.c (Patch not included due to the simplicity of code changes)

March 23, 2006

Re: CVS EU Server

by Brian Vincent

On 3/23/06, Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote: > > > Uhoh, with my own little server problem I now seem to have started > some wildfire... No, no wildfire here. I'm still one of those heathens using CVS too. What I meant was use git to clone the existing git repository to the local rhlx01box. Then I naively assumed you could some how export from git into CVS. A git expert probably knows whether that's possible (a quick Google search didn't provide an answer). Then you'd have both git and CVS available in Europe as well. Did you try this copy of cvsup? ftp://ftp.winehq.org/pub/wine/cvsup/cvsup-glibc2.3.tar.gz -Brian

March 23, 2006

Re: [opengl] check drawable and context Visual IDs in wglMakeCurrent()

by Tomas Carnecky

Stefan Dösinger wrote: > Hi, >> So.. in this attachment you'll find a patch that does what I've just >> described. I can't test it on anything else than WoW, so if someone >> would please review it and test with outher opengl/d3d applications it >> would be great. > No effects noticed with Half-life 1(GL), Warcraft III(GL and D3D) and Jedi > Academy(GL). > maybe it was because of the earlier opengl patch 'Store GL context in TEB'. But I didn't notice such an increase then.. only from ~20 -> ~30fps > That patch gave me a hint for a possible reason for the WineD3D slowness with > a few games :) > good, at least something :) Something else.. now I know why there is this VisualID mismatch. Someone didn't read the GLX spec. in opengl32/wgl.c:describeDrawable() you call glXQueryDrawable() with GLX_VISUAL_ID, but that's not allowed ! only GLX_FBCONFIG_ID and three others, according to the GLX 1.3/1.4 spec [1]. According to the spec, you can get the GLXFBConfig from a GLXDrawable using glXQueryDrawable() and then the Visual from the GLXFBConfig using glXGetFBConfigAttrib(). .. I'll send a patch. tom [1] http://www.opengl.org/documentation/specs/

March 23, 2006

Re: What happened to the Fedora packages?

by Andreas Bierfert

On Wed, 22 Mar 2006 11:01:23 +0100 Michel Ludwig <miclud(a)studcs.uni-sb.de> wrote: > Nice and decent Fedora Wine packages are in Fedora Extras: I am interested in the _decent_ part... always open for suggestions :) - Andreas P.S.: wine-0.9.10.i386 made it to the x86_64 tree so x86_64 users of Fedora Extras can get wine.i386 now by typing yum install wine as well... -- 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 23, 2006

Re:wine.inf: Add a shdocvw.dll stub dll to the system directory

by Louis. Lenders

What about adding a few more, like opengl32 (http://bugs.winehq.org/show_bug.cgi?id=3877) and some more (there are more of these bugs in bugzilla that can be solved that way, i could make a quick list of them if necessary) Regards Louis Module: wine Branch: refs/heads/master Commit: c3c112de231fae2f28d3f685c341a204ddef26a9 URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=c3c112de231fae2f28d3f68… Author: Mike McCormack <mike <at> codeweavers.com> Date: Wed Mar 22 23:46:31 2006 +0900 wine.inf: Add a shdocvw.dll stub dll to the system directory. --- tools/wine.inf | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/tools/wine.inf b/tools/wine.inf index 747eb83..17d9144 100644 --- a/tools/wine.inf +++ b/tools/wine.inf <at> <at> -2114,6 +2114,7 <at> <at> HKLM,%CurrentVersion%\Telephony\Country 11,,help.exe,winhelp.exe 11,,msiexec.exe 11,,notepad.exe +11,,shdocvw.dll 11,,progman.exe 11,,regsvr32.exe 11,,wcmd.exe ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

March 23, 2006

Re: [opengl] check drawable and context Visual IDs in wglMakeCurrent()

by Stefan Dösinger

Hi, > So.. in this attachment you'll find a patch that does what I've just > described. I can't test it on anything else than WoW, so if someone > would please review it and test with outher opengl/d3d applications it > would be great. No effects noticed with Half-life 1(GL), Warcraft III(GL and D3D) and Jedi Academy(GL). That patch gave me a hint for a possible reason for the WineD3D slowness with a few games :) Stefan

March 23, 2006

Re: Bugzilla: Duplicates

by Tony Lambregts

Jeremy Newman wrote: > On Wed, 2006-03-22 at 21:22 +0100, Tobias Burnus wrote: > >>Hello, >> >> >>>Just found, that gcc has "Most frequently reported Bugs": >>>http://gcc.gnu.org/bugzilla/duplicates.cgi >>> >>>And since we have also bugzilla, i tested http://bugs.winehq.org/duplicates.cgi >>>The Page is present, but not configured to be useful for wine. >>> >>>The code is in the cvs, but I'm unable to help here (perl). >>>(Browse the cvs: "http://cvs.winehq.org/cvsweb/bugzilla/") >>> >>> >> >>Hmm, in principle one only needs to tweek at >>http://bugs.winehq.org/editparams.cgi the 'mostfreqthreshold' option. >> >>Running ./checksetup.pl doesn't harm either >> >>The essential task is to fill the duplicates table using the script: >> http://cvs.winehq.org/cvsweb/bugzilla/collectstats.pl >>You need to run it using cron. >> >>Tobias >> > When I try to run the collectstats.pl script I get this: > > wineowner(a)wine:~/opt/bugzilla$ ./collectstats.pl > No value for param loginmethod at Bugzilla/Config.pm line 135. > BEGIN failed--compilation aborted at Bugzilla/Auth.pm line 36. > Compilation failed in require at Bugzilla.pm line 27. > BEGIN failed--compilation aborted at Bugzilla.pm line 27. > Compilation failed in require at ./collectstats.pl line 37. > BEGIN failed--compilation aborted at ./collectstats.pl line 37. > > I have not looked into the code to find why it does not work. Seems > odd since the rest of bugzilla works fine. Looks like you need to give loginmethod a value in Bugzilla.pm. For whatever reason this file is not part of CVS. I can look at my local copy of this file when I get home. -- Tony Lambregts

March 23, 2006

Re: GoogleEarth

by Segin

Lionel Ulmer wrote: >On Thu, Mar 23, 2006 at 07:48:11PM +0100, Francois Gouget wrote: > > >>Is there a place where we collect changes we'd like to see/do in other >>projects? It would be a good resource when the date of some 'Linux on >>the desktop' summit nears... >> >> > >Some information is here for OpenGL: http://wiki.winehq.org/OpenGL > > Lionel > > > Google Earth works stable (barely usable due to some QT/GL errors, yes GoogleEarth uses QT under Windows) under wine 0.9.9

March 23, 2006

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

by Eric Pouech

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 ? -- Eric Pouech

March 23, 2006

Re: Bugzilla: Duplicates

by Jeremy Newman

When I try to run the collectstats.pl script I get this: wineowner(a)wine:~/opt/bugzilla$ ./collectstats.pl No value for param loginmethod at Bugzilla/Config.pm line 135. BEGIN failed--compilation aborted at Bugzilla/Auth.pm line 36. Compilation failed in require at Bugzilla.pm line 27. BEGIN failed--compilation aborted at Bugzilla.pm line 27. Compilation failed in require at ./collectstats.pl line 37. BEGIN failed--compilation aborted at ./collectstats.pl line 37. I have not looked into the code to find why it does not work. Seems odd since the rest of bugzilla works fine. On Wed, 2006-03-22 at 21:22 +0100, Tobias Burnus wrote: > Hello, > > > Just found, that gcc has "Most frequently reported Bugs": > > http://gcc.gnu.org/bugzilla/duplicates.cgi > > > > And since we have also bugzilla, i tested http://bugs.winehq.org/duplicates.cgi > > The Page is present, but not configured to be useful for wine. > > > > The code is in the cvs, but I'm unable to help here (perl). > > (Browse the cvs: "http://cvs.winehq.org/cvsweb/bugzilla/") > > > > > > Hmm, in principle one only needs to tweek at > http://bugs.winehq.org/editparams.cgi the 'mostfreqthreshold' option. > > Running ./checksetup.pl doesn't harm either > > The essential task is to fill the duplicates table using the script: > http://cvs.winehq.org/cvsweb/bugzilla/collectstats.pl > You need to run it using cron. > > Tobias > >

March 23, 2006

Re: GoogleEarth

by Lionel Ulmer

On Thu, Mar 23, 2006 at 07:48:11PM +0100, Francois Gouget wrote: > Is there a place where we collect changes we'd like to see/do in other > projects? It would be a good resource when the date of some 'Linux on > the desktop' summit nears... Some information is here for OpenGL: http://wiki.winehq.org/OpenGL Lionel -- Lionel Ulmer - http://www.bbrox.org/

March 23, 2006

Regression 16 bit threading problem with Use explorer to handle desktop window commit

by paul

If I start two 16 bit programs in wcmd or in the original case use wintask to start a Delphi 1 based GUI the second program does not get a new thread detach. As soon as the switch occurs back to the original task a page fault occurs. See bug for traces, more details and sample program. http://bugs.winehq.org/show_bug.cgi?id=4897 Paul Romanyszyn

March 23, 2006

Re: [opengl] check drawable and context Visual IDs in wglMakeCurrent()

by Tomas Carnecky

Tomas Carnecky wrote: > Changelog: > - fail if the drawable and context Visual IDs don't match. > > why? because this will produce a BadMatch and crash the application so > instead of the crash rather return GL_FALSE and let the application > handle it. Please don't apply this patch yet. It fixes one case but there is more to be aware of. This BadMatch bug is triggered if an application creates a window (with a default Visual ID) and a custom (non-default) pixel format, the IDs were 0x21 and 0x23 in my case (glxinfo/xdpyinfo report Visual ID in the range from 0x21 to 0x70). But! I've seen that World of Warcraft calls wglMakeCurrent() with a darawable that has Visual ID 0x71 and a context with Visual ID 0x21. Now 0x71 is not defined (according to the glxino output) but it works fine, eg. glXMakeCurrent() doesn't produce the X Error in that case. So I went up the backtrace, into create_glxpixmap(). I let this function fail if it would produce a X Error, eg. if "depth of pixmap does not match the GLX_BUFFER_SIZE value of vis". Then I had to modify wglMakeCurrent() to respect the create_glxpixmap() failure and return FALSE. Works good so far, framerate in WoW went up from ~20 to up to 70 fps, average is somewhere between 40-50 !!! This is incredible. So.. in this attachment you'll find a patch that does what I've just described. I can't test it on anything else than WoW, so if someone would please review it and test with outher opengl/d3d applications it would be great. Also, it would be great if we could put the *Swap*Buffers() into their own log domain, something like 'swapbuffers', because the trace is usually useless, only when you explicitly look whether these functions are called or not, otherwise they only fill the log with garbage. thanks tom

March 23, 2006

Re: file.c:246: Test failed: shouldn't be able to delete a readonly file

by Huw D M Davies

On Thu, Mar 23, 2006 at 01:59:12PM -0500, Bryan Mayland wrote: > Huw D M Davies wrote: > >How are you trying to delete them? The question is whether the > >DeleteFile() function works as tested - the way to find this is to run > >that test on Windows XP. > > > DeleteFile on an read-only file under XP returns false. > GetLastError returns 5 (Access denied) Right, which is what we're testing for (well ok we don't test GetLastError). Huw.

March 23, 2006

Re: file.c:246: Test failed: shouldn't be able to delete a readonly file

by Bryan Mayland

Huw D M Davies wrote: > How are you trying to delete them? The question is whether the > DeleteFile() function works as tested - the way to find this is to run > that test on Windows XP. > DeleteFile on an read-only file under XP returns false. GetLastError returns 5 (Access denied)

March 23, 2006

Re: file.c:246: Test failed: shouldn't be able to delete a readonly file

by Huw D M Davies

On Thu, Mar 23, 2006 at 01:24:53PM -0500, Matt Finnicum wrote: > I'm at a windows XP machine right now. > > I have no trouble deleting read-only files - I get the dialog informing me > it's read-only, but then it allows me to delete it. > > Is it the same on 95/98? How are you trying to delete them? The question is whether the DeleteFile() function works as tested - the way to find this is to run that test on Windows XP. Huw.

March 23, 2006

Re: GoogleEarth

by Francois Gouget

On Thu, 23 Mar 2006, Mike Hearn wrote: > On Sun, 19 Mar 2006 23:59:39 +0000, James Courtier-Dutton wrote: >> Can one run GoogleEarth under wine? >> It does not seem to run here under the default settings. > > OpenGL child windows don't work since the WM rewrite, so no, Google Earth > doesn't currently run. To fix it requires X server work apparently :( Is there a place where we collect changes we'd like to see/do in other projects? It would be a good resource when the date of some 'Linux on the desktop' summit nears... -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ 145 = 1! + 4! + 5!

March 23, 2006

Re: GetExitCodeProcess always returns 1

by Igor Sysoev

On Thu, 23 Mar 2006, Mike McCormack wrote: > Igor Sysoev wrote: > >> It seems the tests try to use my old .wine for Wine-20030508. >> I have renamed it and now I can run tests. >> Here are some failed tests (I run make -i test to ignore failures): >> >> ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p >> kernel32_test.e >> xe.so change.c && touch change.ok >> fixme:file:NtNotifyChangeDirectoryFile parameters ignored 0x0 0x0 1 >> change.c:287: Test failed: should be ready > > <snip lots of failed tests> > > Maybe Alexandre would accept patches to add a todo_wine_freebsd {} to the > test suite where there's things that are hard to fix? It seems that I am the first person who ever run the Wine regression tests on FreeBSD :) Actually the test results did not bother me too much. The wrong exit code simply means that I could not use the "make" under Wine on FreeBSD: "make" stops after the first command. Igor Sysoev http://sysoev.ru/en/

March 23, 2006

Re: Dev-C++ dogfooding

by Frank Richter

On 23.03.2006 10:22, Francois Gouget wrote: > Could it be that it is trying to load the resource 160 of shell32.dll? > This resource is an AVI that is meant to be played when you copy files: > it shows sheets jumping from one folder to another. > > If so the tricky thing is getting an animation that plays ok in Wine and > is of a reasonable size. A single empty frame or so might suffice to start with... -f.r.

March 23, 2006

Re: file.c:246: Test failed: shouldn't be able to delete a readonly file

by Matt Finnicum

I'm at a windows XP machine right now. I have no trouble deleting read-only files - I get the dialog informing me it's read-only, but then it allows me to delete it. Is it the same on 95/98? --Murph On 3/23/06, Huw D M Davies <h.davies1(a)physics.ox.ac.uk> wrote: > > On Thu, Mar 23, 2006 at 06:04:21AM -0600, Tom Spear (Dustin Booker, Dustin > Navea) wrote: > > Umm.. I'm not totally sure this is 100% in conformance with windows. > > When I try to delete a readonly file, I get a dialog telling me that it > > is readonly, and asking me if I really want to delete it. If we are > > completely disallowing removal of a readonly file (by windows standard, > > not linux' standard), then it is incorrect and should be fixed... > > > > Well the test passes on Win 2000. > > C:\>kernel32_crosstest.exe file > file: 494243 test executed, 0 marked as todo, 0 failures. > > Huw. > -- > Huw Davies > huw(a)codeweavers.com > > >

March 23, 2006

Race condition in keyboard code?

by Peter Åstrand

Hi, I've been debugging a very strange keyboard problem this afternoon: In some cases the key combination AltGr+2 produces "2" (wrong) rather than "@" (correct), when using a Swedish layout. The problem seems to be a race condition: If a KeyEvent occurs almost directly after the "2" key is pressed, the AltGr state is incorrect. The problem has been verified with this simple test program: /* gcc -Wall xfake.c -o xfake -L/usr/X11R6/lib -lX11 -lXtst */ #include <X11/Xlib.h> #include <X11/extensions/XTest.h> int main( int argc, char* argv[] ) { Display* dpy; dpy = XOpenDisplay( NULL ); XTestFakeKeyEvent(dpy, 0x71, True, CurrentTime); XTestFakeKeyEvent(dpy, 0xb, True, CurrentTime); XSync(dpy, False); //sleep(1); XTestFakeKeyEvent(dpy, 0x71, False, CurrentTime); XTestFakeKeyEvent(dpy, 0xb, False, CurrentTime); XCloseDisplay( dpy ); return 0; } (0x71 is Mode_Switch, 0xb is the "2" key). I'm executing the program while having Wines Notepad active. If the sleep() is commented out, a "2" is inserted into Notepad. If the sleep() is active, "@" is inserted. More evidence: When debugging with WINEDEBUG=keyboard,key, the traces for X11DRV_ToUnicodeEx is printed after the Mode_Switch KeyRelease trace. Now I wonder, is this a problem with: 1) Wine or 2) The Windows API or 3) The way I'm using X11/the keyboard (generating events that quickly). ? I do understand why this happens: X11DRV_ToUnicodeEx uses the global, static variable AltGrMask. Is this a bug? Regards, -- Peter Åstrand ThinLinc Chief Developer Cendio http://www.cendio.se Teknikringen 3 583 30 Linköping Phone: +46-13-21 46 00

March 23, 2006

Re: Another fun winelib project

by Olaf Leidinger

Hello! The source of Civilization "Call to Power 2" was also released some years ago. Have a look at http://apolyton.net/forums/forumdisplay.php?forumid=213 > According to the appdb it does not run so maybe having the source > could better help us find out what we are missing. And it doesn't work either ;-( Ciao, Olaf

March 23, 2006

Re: Regression in gdi

by Tony Lambregts

Alexander N. Sørnes wrote: > Greetings, > > The patch mentioned below introduced a regression in gdi, so that the > part of the slidefields in Windows Media Player 9 left of the slider > were drawn as single-colour rectangles instead of a normal-looking part > of the slidefield. It can be unapplied cleanly from current CVS. See > bug 4868 (http://bugs.winehq.org/show_bug.cgi?id=4868) > > gdi: Better support for 1bpp dib sections. > http://source.winehq.org/git/?p=wine.git;a=commit;h=b55746ab62739fc1e4c0d4a… > > It's not just windows mediaplayer thats for sure. winrar also suffers from this regression. (dogfood) -- Tony Lambregts

March 23, 2006

Re: CVS EU Server

by Andreas Mohr

Hi, On Thu, Mar 23, 2006 at 08:03:09AM -0700, Brian Vincent wrote: > On 3/23/06, Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote: > > > > Welll... not quite: the very high FC5 download number is not the problem, > > rather the server got upgraded a couple days ago (to FC5, too), which > > broke > > cvsup (SEGV). > > > Would it be worth skipping cvsup and moving to git? Uhoh, with my own little server problem I now seem to have started some wildfire... Well, two things: a) WineHQ doesn't really seem to mention git, only CVS b) 85% of all users: "git!? whaddchadibbledegack??" I would be more or less willing to move to git, I'm just not sure whether it's the way to go currently. But cvsup certainly seems somewhat stale currently, despite the fact that it's a VERY important lowlevel tool used at lots of places. Andreas -- No programming skills!? Why not help translate many Linux applications! https://launchpad.ubuntu.com/rosetta

March 23, 2006

Re: CVS EU Server

by Brian Vincent

On 3/23/06, Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote: > > Welll... not quite: the very high FC5 download number is not the problem, > rather the server got upgraded a couple days ago (to FC5, too), which > broke > cvsup (SEGV). Would it be worth skipping cvsup and moving to git? -Brian

March 23, 2006

glXCreateGLXPixmap() BadMatch

by Tomas Carnecky

Tomas Carnecky wrote: > Tomas Carnecky wrote: >> Mike Hearn wrote: >>> Mike Hearn <mike(a)plan99.net> >>> Optimize thunks by storing GL context in the thread environment block >>> >> good job. this fixed the BadMatch error in World of Warcraft and also >> increased performance, from ~20fps to ~25fps. >> > > Maybe that was too soon.. I can login with some characters, with others > I still get the BadMatch error. This bug may be related to the minimap > bug that caused opengl to crash when you entered a building, because I > can login with my characters than stand outside, but now with those that > stands in an inn (building) or in Ironforge. > > Does anyone remeber how the minimap bug was fixed and if this BadMatch > bug may be related to it? > BadMatch is generated if the depth of pixmap does not match the GLX_BUFFER_SIZE value of vis, or if pixmap was not created with respect to the same screen as vis. Futher investigation revealed this: when create_glxpixmap() is called, physDev->depth and physDev->bitmap->pixmap_depth are 1, but GLX_BUFFER_SIZE from the visual returns 32, I don't know how to get the depth directly from the pixmap (in case physDev->bitmap->pixmap_depth is not up-to-date), so any clarification how the bimap/pixmap code works would be great. Also, when looking where the depth is changed, I came across X11DRV_SelectBitmap(), there you change the depth if physDev->depth and physBitmap->pixmap_depth don't match. In the trace I see that WoW creates lots of bitmaps and the last time a bitmap is selected the depth is changed to 1: trace:x11drv:X11DRV_CreateBitmap (0x340) 32x32 1 bpp trace:x11drv:X11DRV_CreateBitmap physBitmap->pixmap_depth: 1 trace:x11drv:X11DRV_SetBitmapBits (bmp=0x340, bits=0x7fd64e50, count=0x80) trace:x11drv:X11DRV_SetBitmapBits (physBitmap->pixmap_depth=1 trace:x11drv:X11DRV_CreateBitmap (0x33c) 32x32 24 bpp trace:x11drv:X11DRV_CreateBitmap physBitmap->pixmap_depth: 24 trace:x11drv:X11DRV_SetBitmapBits (bmp=0x33c, bits=0x7fd888b8, count=0xc00) trace:x11drv:X11DRV_SetBitmapBits (physBitmap->pixmap_depth=24 trace:x11drv:X11DRV_SelectBitmap changing depth of physDev(0x7fd64ed8) to 24 trace:x11drv:X11DRV_SelectBitmap changing depth of physDev(0x7fd64ed8) to 1 And also, I don't see anywhere in the trace that the bitmap depth would be 32 (to match GLX_BUFFER_SIZE). tom

March 23, 2006

Re: IDE with Winemaker

by Stefan Dösinger

Hi, > Hi, I am a Windows Developer who is new to the Linux world. Is there any > IDE (like Visio Studio) I can use with Winemaker? I am trying to port a > Windows App to Linux Fedora. I managed to use wineg++ with kdevelop by overriding the compiler. It worked quite well for my needs(code a ddraw test app), but I don't know if it works for bigger apps. Just set a CC="winegcc", CXX="wineg++" and LINK="winegcc" (??) environment variable in the projekt options. There isn't any IDE which offers an editor for the resource files, so you have to edit them by hand.

March 23, 2006

Re: GoogleEarth

by Mike Hearn

On Sun, 19 Mar 2006 23:59:39 +0000, James Courtier-Dutton wrote: > Can one run GoogleEarth under wine? > It does not seem to run here under the default settings. OpenGL child windows don't work since the WM rewrite, so no, Google Earth doesn't currently run. To fix it requires X server work apparently :(

March 23, 2006

Keyboard fix - patch available

by penna＠bb.com.br

Hi all, Sorry for bothering you guys ..... but .... I saw a patch for bug #2400 (a very old bug) at http://bugs.winehq.org/show_bug.cgi?id=2400 Looking at the comments at the bugzilla tracking, the patch worked flawlessly for lots of keyboard types (croatian, german and russian), including mine: a brazilian abnt2 keyboard. The patch looks fine and very clean. The problem mentioned with remote X-windows access seems not to occur besides someone mention it. Anyway, at least the problem is gone with local access and, *if confirmed*, remains with remote access only. Maybe, just maybe, the patch could be applied for the next version of wine (0.9.11) .... ;-) Thank you very much for the very good piece of work: WINE (I use it since 1999). --------------------------------------------------------- Ulisses de Sousa Penna Analista Consultor - Banco do Brasil Fone: +55-61-3310-6320 Fax: +55-61-3310-6435 --------------------------------------------------------- P.S.: I am not subscribed at wine-devel list (just wine-users list)

March 23, 2006

Re: IDE with Winemaker

by Mike Hearn

On Wed, 22 Mar 2006 15:58:13 -0500, Ng, Billy H CIV NAVSEA wrote: > Hi, I am a Windows Developer who is new to the Linux world. > Is there any IDE (like Visio Studio) I can use with Winemaker? I am > trying to port a Windows App to Linux Fedora. Heya, On Linux the usage of IDEs is much less common than on Windows, and the usage of powerful generic text editors like emacs or vim is greater. So I'm afraid no IDE/winemaker integration is likely to exist (I definitely never heard of it). Winemaker is only ever run once anyway, just use the command line. That said, Eclipse has some C/C++ support these days if you want to use that. But if I were you I'd learn emacs ;) I did and never regretted it (used to use delphi). thanks -mike

March 23, 2006

Re: What happened to the Fedora packages?

by Francois Gouget

On Wed, 22 Mar 2006, Neal Gompa wrote: > Well, the system is a Pentium 4 2.8GHz HyperThreading with 512MB RAM, so > that is not the problem! It just always fails.... Oh, the compilation fails? That's not the same as the computer crashing... Maybe you can send us the error message and then we can help you. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager.

March 23, 2006

Re: What happened to the Fedora packages?

by Mike Hearn

On Thu, 23 Mar 2006 13:55:41 +0100, Alexandre Julliard wrote: > The problem was actually with gcc, and it's been fixed for a while > now. Ah awesome, I'll re-enable winetest then, thanks.

March 23, 2006

Re: Store GL context in the TEB

by Tomas Carnecky

Tomas Carnecky wrote: > Mike Hearn wrote: >> Mike Hearn <mike(a)plan99.net> >> Optimize thunks by storing GL context in the thread environment block >> > > good job. this fixed the BadMatch error in World of Warcraft and also > increased performance, from ~20fps to ~25fps. > Maybe that was too soon.. I can login with some characters, with others I still get the BadMatch error. This bug may be related to the minimap bug that caused opengl to crash when you entered a building, because I can login with my characters than stand outside, but now with those that stands in an inn (building) or in Ironforge. Does anyone remeber how the minimap bug was fixed and if this BadMatch bug may be related to it? tom

March 23, 2006

Re: What happened to the Fedora packages?

by Alexandre Julliard

Mike Hearn <mike(a)plan99.net> writes: > It's a bug in Wine, which I harassed AJ about a long time ago but it was > never fixed I guess because he has a super-awesome machine :) > > Basically, compiling winetest causes gas to blow gigs of memory, because > it's compiling like 50mb+ of assembly. I just hacked it out of the build > system myself. The problem was actually with gcc, and it's been fixed for a while now. -- Alexandre Julliard julliard(a)winehq.org

March 23, 2006

Re: file.c:246: Test failed: shouldn't be able to delete a readonly file

by Huw D M Davies

On Thu, Mar 23, 2006 at 06:04:21AM -0600, Tom Spear (Dustin Booker, Dustin Navea) wrote: > Umm.. I'm not totally sure this is 100% in conformance with windows. > When I try to delete a readonly file, I get a dialog telling me that it > is readonly, and asking me if I really want to delete it. If we are > completely disallowing removal of a readonly file (by windows standard, > not linux' standard), then it is incorrect and should be fixed... > Well the test passes on Win 2000. C:\>kernel32_crosstest.exe file file: 494243 test executed, 0 marked as todo, 0 failures. Huw. -- Huw Davies huw(a)codeweavers.com

March 23, 2006

Re: What happened to the Fedora packages?

by Eddy Nigg (StartCom Ltd.)

We just compiled the latest wine rpm for our upcoming MultiMedia Edition....no problems at all...We made only minor adjustments, to reflect the fact, that it's a StartCom build and not Fedora.... The files can be used of course by any compatible OS: http://ftp.belnet.be/linux/startcom/ML-5.0.5/os/i386/StartCom/RPMS/wine*.rpm Cheers! Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 Neal Gompa wrote: > Well, the system is a Pentium 4 2.8GHz HyperThreading with 512MB RAM, > so that is not the problem! It just always fails.... > > On 3/22/06, *Segin* < segin2005(a)gmail.com > <mailto:segin2005(a)gmail.com>> wrote: > > Neal Gompa wrote: > What happened to the Fedora packages? They have not been updated > since 0.9.2!!!! Right now it is at 0.9.10!!! Nearly every other > Linux distro supported has the up to date packages!!! And why does > the Red Hat packages site not go to the SourceForge site as it > does for SUSE packages and the others?? I have not really had the > guts to ask until now, because I thought that maybe there was a > slump, but now, its getting annoying!! And Fedora just released > Fedora Core 5 yesterday!!! Please tell me new packages will be > ready soon!!! Compiling WINE always crashes my computer, so I > prefer to use the RPMs... > > ------------------------------------------------------------------------ > > > > > Is your computer also a Pentium 166MHz with 32MB of RAM? ... > > No, wait, even THAT can compile wine. Wine wasn't rated for 16MB > systems, sorry. </sarcasam> > > Or in English: You need more RAM. When you run out of RAM, almost > all UNIXes and clones have a kernel panic. Linux does either that, > or it starts randomly killing off proccesses (your window manager, > X, init, and so on) depending on it config at compile time. > Please make sure you have enough swap, you have plenty of RAM > (512MB or more), all of your toolkit conponets (gcc, binutils, > etc.) are up to date, and that you don't have faulty hardware. > > > > ------------------------------------------------------------------------ > > > -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390

March 23, 2006

file.c:246: Test failed: shouldn't be able to delete a readonly file

by Tom Spear (Dustin Booker, Dustin Navea)

Umm.. I'm not totally sure this is 100% in conformance with windows. When I try to delete a readonly file, I get a dialog telling me that it is readonly, and asking me if I really want to delete it. If we are completely disallowing removal of a readonly file (by windows standard, not linux' standard), then it is incorrect and should be fixed... Tom Igor Sysoev wrote: > > file.c:246: Test failed: shouldn't be able to delete a readonly file

March 23, 2006

Re: Dev-C++ dogfooding

by Tom Spear (Dustin Booker, Dustin Navea)

There is a freeware program called Total Copy that you might be able to convince the author to let you have the source (or to at least let you use the animation).. He doesn't actively develop it anymore, and it would be nice to have our own copy dialog anyways.. I use total copy on my windows machine all the time, I just wish I could make it _replace_ the standard copy dialog, but right dragging and clicking is ok too.. Tom Francois Gouget wrote: > On Wed, 22 Mar 2006, Segin wrote: > [...] >> Package manager starts up, presents you with a disloag (like aother >> package install) but when it goes to copy files, it open a dialog box >> with the error "Cannot Open AVI" with buttons which are clipped off >> (the window is a bit too small, push the farthest to the left to >> makei t resize and such.) > > Could it be that it is trying to load the resource 160 of shell32.dll? > This resource is an AVI that is meant to be played when you copy > files: it shows sheets jumping from one folder to another. > > If so the tricky thing is getting an animation that plays ok in Wine > and is of a reasonable size. >

March 23, 2006

Re: GetExitCodeProcess always returns 1

by Mike McCormack

Igor Sysoev wrote: > It seems the tests try to use my old .wine for Wine-20030508. > I have renamed it and now I can run tests. > Here are some failed tests (I run make -i test to ignore failures): > > ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p > kernel32_test.e > xe.so change.c && touch change.ok > fixme:file:NtNotifyChangeDirectoryFile parameters ignored 0x0 0x0 1 > change.c:287: Test failed: should be ready <snip lots of failed tests> Maybe Alexandre would accept patches to add a todo_wine_freebsd {} to the test suite where there's things that are hard to fix? Mike

March 23, 2006

Re: GetExitCodeProcess always returns 1

by Igor Sysoev

On Thu, 23 Mar 2006, Mike McCormack wrote: > Igor Sysoev wrote: > >> Should Wine be already installed before run these tests ? I've tried: >> >> make test >> ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p >> kernel32_test.exe.so alloc.c && touch alloc.ok >> Warning: the specified Windows directory L"c:\\windows" is not accessible. >> Warning: the specified System directory L"c:\\windows\\system32" is not >> accessible. >> Warning: could not find DOS drive for current working directory >> '/usr/ports/emulators/wine/work/wine-0.9.10/dlls/kernel/tests', starting in >> the Windows directory. >> wine: could not load L"c:\\windows\\system32\\kernel32_test.exe.so": Module >> not found >> *** Error code 126 > > No, it should work without Wine installed, and without a ~/.wine > Perhaps try running wine/tools/wineprefixcreate first? > > bash-3.00$ rm -rf ~/.wine > bash-3.00$ cd dlls/kernel > bash-3.00$ make test > make[1]: Entering directory `/home/mike/wine/dlls/kernel/tests' > ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p > kernel32_test.exe.so alloc.c && touch alloc.ok > wine: creating configuration directory '/home/mike/.wine'... > wine: '/home/mike/.wine' created successfully. > ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p > kernel32_test.exe.so atom.c && touch atom.ok > ... It seems the tests try to use my old .wine for Wine-20030508. I have renamed it and now I can run tests. Here are some failed tests (I run make -i test to ignore failures): ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.e xe.so change.c && touch change.ok fixme:file:NtNotifyChangeDirectoryFile parameters ignored 0x0 0x0 1 change.c:287: Test failed: should be ready change.c:290: Test failed: should be ready change.c:302: Test failed: should be ready change.c:305: Test failed: should be ready fixme:file:NtNotifyChangeDirectoryFile parameters ignored 0x0 0x0 1 [ Here Wine-0.9.10 hangs and I have killed the process ] ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.e xe.so file.c && touch file.ok file.c:246: Test failed: shouldn't be able to delete a readonly file file.c:248: Test failed: couldn't change attributes on file file.c:250: Test failed: now it should be possible to delete the file! file.c:1271: Test failed: mapping should fail file.c:1275: Test failed: mapping should fail file.c:1281: Test failed: DeleteFile failed after map file.c:1288: Test failed: open testfile.xxx failed file.c:1290: Test failed: expected type disk got 0 *** Error code 8 (ignored) ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.e xe.so mailslot.c && touch mailslot.ok mailslot.c:195: Test failed: dwNext incorrect mailslot.c:206: Test failed: dwNext incorrect mailslot.c:218: Test failed: dwNext incorrect mailslot.c:238: Test failed: dwNext incorrect mailslot.c:255: Test succeeded inside todo block: dwMsgCount incorrect mailslot.c:260: Test succeeded inside todo block: 3rd slot read failed *** Error code 6 (ignored) ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.e xe.so pipe.c && touch pipe.ok pipe.c:134: Test succeeded inside todo block: peek3 got 21 bytes pipe.c:146: Test succeeded inside todo block: pipe content 3b check pipe.c:166: Test succeeded inside todo block: peek4 got 21 bytes pipe.c:178: Test succeeded inside todo block: pipe content 4b check pipe.c:138: Test failed: peek3 got 21 bytes pipe.c:170: Test failed: peek4 got 21 bytes pipe.c:215: Test failed: peek5 got 21 bytes pipe.c:246: Test failed: peek6 got 21 bytes *** Error code 8 (ignored) ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.e xe.so process.c && touch process.ok err:wineconsole:WCUSER_SetFont wrong font process.c:1246: Test failed: ExitCode:value expected 1, but got 123 *** Error code 1 (ignored) The last message is strange: process.c:1246: Test failed: ExitCode:value expected 1, but got 123 The child should return 123 and this value should be expected. Igor Sysoev http://sysoev.ru/en/

March 23, 2006

Re: CVS EU Server

by Andreas Mohr

Hi, On Thu, Mar 23, 2006 at 09:46:53AM +0100, Andreas Mohr wrote: > I'll try to get cvs synched again manually (just doing it more often), > but no promises since the pipe (or shaping or whatever) is pretty much > bursting and thus it may not be overly successful... > > Thanks for the report, it's very important! Welll... not quite: the very high FC5 download number is not the problem, rather the server got upgraded a couple days ago (to FC5, too), which broke cvsup (SEGV). Since cvsup is written in Modula-3, it's not particularly easy to get it built (Adrian told me he has trouble getting it built with gcc 4.1, I should additionally try to get it done myself). Oh well, hopefully we'll get it done properly Andreas -- Please consider not buying any HDTV hardware! (extremely anti-consumer) Bitte kaufen Sie besser keinerlei HDTV-Geräte! (extrem verbraucherfeindlich) Visit http://www.hdboycott.com or http://www.eff.org/IP/DRM/ for more infos

March 23, 2006

Re: GetExitCodeProcess always returns 1

by Mike McCormack

Igor Sysoev wrote: > Should Wine be already installed before run these tests ? I've tried: > > make test > ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p > kernel32_test.exe.so alloc.c && touch alloc.ok > Warning: the specified Windows directory L"c:\\windows" is not accessible. > Warning: the specified System directory L"c:\\windows\\system32" is not > accessible. > Warning: could not find DOS drive for current working directory > '/usr/ports/emulators/wine/work/wine-0.9.10/dlls/kernel/tests', starting > in the Windows directory. > wine: could not load L"c:\\windows\\system32\\kernel32_test.exe.so": > Module not found > *** Error code 126 No, it should work without Wine installed, and without a ~/.wine Perhaps try running wine/tools/wineprefixcreate first? Mike bash-3.00$ rm -rf ~/.wine bash-3.00$ cd dlls/kernel bash-3.00$ make test make[1]: Entering directory `/home/mike/wine/dlls/kernel/tests' ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so alloc.c && touch alloc.ok wine: creating configuration directory '/home/mike/.wine'... wine: '/home/mike/.wine' created successfully. ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so atom.c && touch atom.ok ...

March 23, 2006

Re: GetExitCodeProcess always returns 1

by Igor Sysoev

On Thu, 23 Mar 2006, Mike McCormack wrote: > Igor Sysoev wrote: > >> Well, but then I could not build Wine port under FreeBSD: as I understand >> the port runs something like >> ./configure && make depend && make && make install >> >> But I have built and installed Wine successfully. > > Sorry, misunderstood you. The tests don't run on every build, you have to > run them explicitly. > > Try running "make test", or "cd dlls/kernel; make test" Should Wine be already installed before run these tests ? I've tried: make test ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so alloc.c && touch alloc.ok Warning: the specified Windows directory L"c:\\windows" is not accessible. Warning: the specified System directory L"c:\\windows\\system32" is not accessible. Warning: could not find DOS drive for current working directory '/usr/ports/emulators/wine/work/wine-0.9.10/dlls/kernel/tests', starting in the Windows directory. wine: could not load L"c:\\windows\\system32\\kernel32_test.exe.so": Module not found *** Error code 126 Igor Sysoev http://sysoev.ru/en/

March 23, 2006

Re: Dev-C++ dogfooding

by Francois Gouget

On Wed, 22 Mar 2006, Segin wrote: [...] > Package manager starts up, presents you with a disloag (like aother package > install) but when it goes to copy files, it open a dialog box with the error > "Cannot Open AVI" with buttons which are clipped off (the window is a bit too > small, push the farthest to the left to makei t resize and such.) Could it be that it is trying to load the resource 160 of shell32.dll? This resource is an AVI that is meant to be played when you copy files: it shows sheets jumping from one folder to another. If so the tricky thing is getting an animation that plays ok in Wine and is of a reasonable size. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.

March 23, 2006

Re: CVS EU Server

by Andreas Mohr

Hi, On Wed, Mar 22, 2006 at 09:09:17PM +0100, Sven Paschukat wrote: > Does anyone know what's wrong with the CVS server > rhlx01.fht-esslingen.de in Europe? It's out of sync for a few days now. Hmpf. Now that's why I was getting the "CVS problem" mails slightly more often than normal... There's nothing "wrong" with that server per se, apart from: [andi(a)rhlx01 ~]$ pgrep http|wc -l 257 [andi(a)rhlx01 ~]$ pgrep vsftpd|wc -l 319 permanently for the last couple of days ("just" about 500Mbps bandwidth). Can you spell "FC5"? ;-) I'll try to get cvs synched again manually (just doing it more often), but no promises since the pipe (or shaping or whatever) is pretty much bursting and thus it may not be overly successful... Thanks for the report, it's very important! Andreas

March 23, 2006

Re: GetExitCodeProcess always returns 1

by Igor Sysoev

On Thu, 23 Mar 2006, Mike McCormack wrote: > Igor Sysoev wrote: > >> It seems that dlls/kernel/tests/process.c already has such test: >> test_ExitCode(). Does it run while usual build ? > > Yes, it is run after commits, so it's likely that it's only broken on > FreeBSD. Well, but then I could not build Wine port under FreeBSD: as I understand the port runs something like ./configure && make depend && make && make install But I have built and installed Wine successfully. Igor Sysoev http://sysoev.ru/en/

March 23, 2006

Re: GetExitCodeProcess always returns 1

by Mike McCormack

Igor Sysoev wrote: > Well, but then I could not build Wine port under FreeBSD: as I understand > the port runs something like > ./configure && make depend && make && make install > > But I have built and installed Wine successfully. Sorry, misunderstood you. The tests don't run on every build, you have to run them explicitly. Try running "make test", or "cd dlls/kernel; make test" Mike

March 23, 2006

Re: GetExitCodeProcess always returns 1

by Igor Sysoev

On Thu, 23 Mar 2006, Mike McCormack wrote: > 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. > > If you turn your test case into a Wine regression test, and add it to > dlls/kernel/tests/process.c, then it won't be broken on Linux, and therefore > there's a better chance it won't break on FreeBSD. > > It's also up to FreeBSD users to make sure Wine doesn't break on FreeBSD by > making the test cases pass and testing them regularly to find regressions. It seems that dlls/kernel/tests/process.c already has such test: test_ExitCode(). Does it run while usual build ? Igor Sysoev http://sysoev.ru/en/

March 23, 2006

Re: GetExitCodeProcess always returns 1

by Mike McCormack

Igor Sysoev wrote: > It seems that dlls/kernel/tests/process.c already has such test: > test_ExitCode(). Does it run while usual build ? Yes, it is run after commits, so it's likely that it's only broken on FreeBSD. Mike

March 23, 2006

Re: GetExitCodeProcess always returns 1

by Mike McCormack

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. If you turn your test case into a Wine regression test, and add it to dlls/kernel/tests/process.c, then it won't be broken on Linux, and therefore there's a better chance it won't break on FreeBSD. It's also up to FreeBSD users to make sure Wine doesn't break on FreeBSD by making the test cases pass and testing them regularly to find regressions. Mike

March 23, 2006

ilink32 hungs under Wine 0.9.10

by Igor Sysoev

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 ? Igor Sysoev http://sysoev.ru/en/

March 23, 2006

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

by Igor Sysoev

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: C:\dmc\bin>dmc wine: Unhandled stack overflow at address 0x405620 (thread 0017), starting debugger... WineDbg starting on pid 0x16 Couldn't initiate DbgHelp Unhandled exception: stack overflow in 32-bit code (0x00405620). file_set_error: Bad address file_set_error: Bad address Register dump: CS:0033 SS:003b DS:003b ES:003b FS:1007 GS:001b EIP:00405620 ESP:0035ff6c EBP:0035ffe8 EFLAGS:00010216( - 00 -RIAP1) EAX:00000000 EBX:9c297064 ECX:0035ff1c EDX:00000000 ESI:9c099460 EDI:00405620 Stack dump: 0x0035ff6c: 9c20b210 9c099460 00000000 00000000 0x0035ff7c: 00000000 ffffffff 9c1d1ff8 9c1e47ec 0x0035ff8c: 9c20b1a8 9c297064 0035ff6c 0035ffe8 0x0035ff9c: 00110000 00001000 0000127f 00000000 0x0035ffac: 00000000 00000000 00000000 00000001 0x0035ffbc: 00000000 00000000 00000000 00000000 0200: sel=1007 base=00110000 limit=00001fff 32-bit rw- Backtrace: =>1 0x00405620 (0x00405620) file_set_error: Bad address 0x00405620: -- no code accessible -- Modules: Module Address Debug info Name (0 modules) Threads: process tid prio (all id:s are in hex) 00000016 (D) C:\dmc\bin\dmc.exe 00000017 0 <== 00000008 00000009 0 Igor Sysoev http://sysoev.ru/en/

March 23, 2006

GetExitCodeProcess always returns 1

by Igor Sysoev

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. Igor Sysoev http://sysoev.ru/en/

March 23, 2006

Re: [winedoc] Resend Update to documentation

by Dimi Paun

On Wed, 2006-03-22 at 00:11 +1100, Jeff L wrote: > I assume that documentation patches still come here. Yes, they do. A few points however: -- please make patches from the root of the docs/, not from docs/en/ -- you need to refine a bit what your trying to say, I can not apply it in the current form. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

March 23, 2006

Wiki access

by Tom Spear (Dustin Booker, Dustin Navea)

Could someone give me access to rename and delete pages in the wiki? I can't even rename or delete my own user page (!!) Thanks Tom

March 23, 2006

Re: advpack: Forward the remaining advpack.c ansi functions to their unicode counterparts

by Mike McCormack

James Hawkins wrote: > Would MultiByteToWideChar(CP_ACP, 0, pPerUser->szGUID, -1, > perUserW.szGUID, sizeof(perUserW.szGUID)) be a better solution? The counts for both A and W are in characters, and sizeof() gives bytes, so you need to divide the sizeof a WCHAR array by sizeof(WCHAR) to get the number of characters in the array. Mike

March 23, 2006

Re: advpack: Forward the remaining advpack.c ansi functions to their unicode counterparts

by James Hawkins

On 3/22/06, Alexandre Julliard <julliard(a)winehq.org> wrote: > > The source lengths are wrong, these are null-terminated strings. Also > please use sizeof() instead of hardcoding the constants. > Would MultiByteToWideChar(CP_ACP, 0, pPerUser->szGUID, -1, perUserW.szGUID, sizeof(perUserW.szGUID)) be a better solution? -- James Hawkins

March 23, 2006

Re: What happened to the Fedora packages?

by Segin

Did you install the -devel packages for all of the dependecies? They contain the headers nessessrary for complimation. Also you need gcc/binutils. or you can try a slackware package, just untar the entire thing to / and delete /install afterwards Neal Gompa wrote: > Well, the system is a Pentium 4 2.8GHz HyperThreading with 512MB RAM, > so that is not the problem! It just always fails.... > > On 3/22/06, *Segin* < segin2005(a)gmail.com > <mailto:segin2005(a)gmail.com>> wrote: > > Neal Gompa wrote: > What happened to the Fedora packages? They have not been updated > since 0.9.2!!!! Right now it is at 0.9.10!!! Nearly every other > Linux distro supported has the up to date packages!!! And why does > the Red Hat packages site not go to the SourceForge site as it > does for SUSE packages and the others?? I have not really had the > guts to ask until now, because I thought that maybe there was a > slump, but now, its getting annoying!! And Fedora just released > Fedora Core 5 yesterday!!! Please tell me new packages will be > ready soon!!! Compiling WINE always crashes my computer, so I > prefer to use the RPMs... > >------------------------------------------------------------------------ > > > > > Is your computer also a Pentium 166MHz with 32MB of RAM? ... > > No, wait, even THAT can compile wine. Wine wasn't rated for 16MB > systems, sorry. </sarcasam> > > Or in English: You need more RAM. When you run out of RAM, almost > all UNIXes and clones have a kernel panic. Linux does either that, > or it starts randomly killing off proccesses (your window manager, > X, init, and so on) depending on it config at compile time. > Please make sure you have enough swap, you have plenty of RAM > (512MB or more), all of your toolkit conponets (gcc, binutils, > etc.) are up to date, and that you don't have faulty hardware. > > >

March 23, 2006

Re: Dev-C++ dogfooding

by Segin

Dimi Paun wrote: >From: "Segin" <segin2005(a)gmail.com> > > >>For some odd reason some files won't compile, yet others do, i can't >>explain it. Must be a MingW bug. >> >> > >Is Dev-C++ using MinGW or the native gcc? > > > MinGW, it cannot use the native gcc AFAIK. Also note that the MinGW it uses is self-contained, and is distributed with the IDE. You can upgrade it using update packages. I'll email you a copy of Dev-C++ if you wish to use it..

March 22, 2006

Re: What happened to the Fedora packages?

by Neal Gompa

Well, the system is a Pentium 4 2.8GHz HyperThreading with 512MB RAM, so that is not the problem! It just always fails.... On 3/22/06, Segin <segin2005(a)gmail.com> wrote: > > Neal Gompa wrote: > > What happened to the Fedora packages? They have not been updated since > 0.9.2!!!! Right now it is at 0.9.10!!! Nearly every other Linux distro > supported has the up to date packages!!! And why does the Red Hat packages > site not go to the SourceForge site as it does for SUSE packages and the > others?? I have not really had the guts to ask until now, because I thought > that maybe there was a slump, but now, its getting annoying!! And Fedora > just released Fedora Core 5 yesterday!!! Please tell me new packages will be > ready soon!!! Compiling WINE always crashes my computer, so I prefer to use > the RPMs... > > ------------------------------ > > > Is your computer also a Pentium 166MHz with 32MB of RAM? ... > > No, wait, even THAT can compile wine. Wine wasn't rated for 16MB systems, > sorry. </sarcasam> > > Or in English: You need more RAM. When you run out of RAM, almost all > UNIXes and clones have a kernel panic. Linux does either that, or it starts > randomly killing off proccesses (your window manager, X, init, and so on) > depending on it config at compile time. > Please make sure you have enough swap, you have plenty of RAM (512MB or > more), all of your toolkit conponets (gcc, binutils, etc.) are up to date, > and that you don't have faulty hardware. > > >

March 22, 2006

Dev-C++ dogfooding

by Segin

So far, everything works, except when you try to install a package that already is installed (of any version, so this also breaks upgrades via the package manager) Package manager starts up, presents you with a disloag (like aother package install) but when it goes to copy files, it open a dialog box with the error "Cannot Open AVI" with buttons which are clipped off (the window is a bit too small, push the farthest to the left to makei t resize and such.) It should be noted that a manual upgrade can be done by untarring the DevPak (it's a .tar.bz2) and copying the files manually, if the directory names aren't mangled. For some odd reason some files won't compile, yet others do, i can't explain it. Must be a MingW bug.

March 22, 2006

Another fun winelib project

by Steven Edwards

It seems Microsoft has MS-FOSSed Mech Commander 2 under a shared source license http://www.microsoft.com/downloads/details.aspx?FamilyID=6d790cde-c3e5-46be… According to the appdb it does not run so maybe having the source could better help us find out what we are missing. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

March 22, 2006

Re: Dev-C++ dogfooding

by Stefan Dösinger

Hi, > Package manager starts up, presents you with a disloag (like aother > package install) but when it goes to copy files, it open a dialog box > with the error "Cannot Open AVI" I've seen simmilar problems with other apps. They want to load an copy animation video from the windows dir, but can't find it. Time to add some more artwork to wine? Stefan

March 22, 2006

Re: Dev-C++ dogfooding

by Dimi Paun

From: "Segin" <segin2005(a)gmail.com> > For some odd reason some files won't compile, yet others do, i can't > explain it. Must be a MingW bug. Is Dev-C++ using MinGW or the native gcc? -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

March 22, 2006

Re: winedbg: Fix stepping over

by Eric Pouech

Petr Tesarik wrote: > Hi, > > this patch fixes a bug in winedbg, which caused it to continue > execution at a wrong address when stepping over a function call. > The trouble was that if there was no breakpoint found, the code at the > end of break_should_continue reversed the PC adjustment and later the > debugger resumed program execution AFTER the INT3 instruction, which > is clearly wrong. > Index: break.c > =================================================================== > RCS file: /home/wine/wine/programs/winedbg/break.c,v > retrieving revision 1.17 > diff -u -r1.17 break.c > --- break.c 27 Jan 2006 15:22:15 -0000 1.17 > +++ break.c 21 Mar 2006 10:36:07 -0000 > @@ -731,9 +731,13 @@ > if (code == EXCEPTION_BREAKPOINT) > addr->Offset += be_cpu->adjust_pc_for_break(&dbg_context, TRUE); > > + dbg_curr_thread->stopped_xpoint = find_xpoint(addr, be_xpoint_break); > dbg_curr_process->bp[0].enabled = FALSE; /* disable the step-over breakpoint */ > > - dbg_curr_thread->stopped_xpoint = find_xpoint(addr, be_xpoint_break); this part looks correct > + /* Unconditionally stop on the step-over breakpoint */ > + if (dbg_curr_thread->stopped_xpoint == 0) > + return FALSE; > + but this doesn't... you don't handle the count here... what you should do is only compute dbg_curr_thread->stopped_xpoint (and do the appropriate handling) when its current value is -1 (not found) A+ -- Eric Pouech

March 22, 2006

IDE with Winemaker

by Ng, Billy H CIV NAVSEA

Hi, I am a Windows Developer who is new to the Linux world. Is there any IDE (like Visio Studio) I can use with Winemaker? I am trying to port a Windows App to Linux Fedora. Thanks, Billy.

March 22, 2006

Re: advpack: Forward the remaining advpack.c ansi functions to their unicode counterparts

by Alexandre Julliard

"James Hawkins" <truiken(a)gmail.com> writes: > +HRESULT WINAPI SetPerUserSecValuesA(PERUSERSECTIONA* pPerUser) > +{ > + PERUSERSECTIONW perUserW; > + > + if (!pPerUser) > + return E_INVALIDARG; > + > + TRACE("(%p)\n", pPerUser); > + > + /* lengths copied from PERUSERSECTION structure definition */ > + MultiByteToWideChar(CP_ACP, 0, pPerUser->szGUID, 59, perUserW.szGUID, 59); > + MultiByteToWideChar(CP_ACP, 0, pPerUser->szDispName, 128, perUserW.szDispName, 128); > + MultiByteToWideChar(CP_ACP, 0, pPerUser->szLocale, 10, perUserW.szLocale, 10); > + MultiByteToWideChar(CP_ACP, 0, pPerUser->szStub, MAX_PATH * 4, perUserW.szStub, MAX_PATH * 4); > + MultiByteToWideChar(CP_ACP, 0, pPerUser->szVersion, 32, perUserW.szVersion, 32); > + MultiByteToWideChar(CP_ACP, 0, pPerUser->szCompID, 128, perUserW.szCompID, 128); The source lengths are wrong, these are null-terminated strings. Also please use sizeof() instead of hardcoding the constants. -- Alexandre Julliard julliard(a)winehq.org

March 22, 2006

Re: Bugzilla: Duplicates

by Tobias Burnus

Hello, > Just found, that gcc has "Most frequently reported Bugs": > http://gcc.gnu.org/bugzilla/duplicates.cgi > > And since we have also bugzilla, i tested http://bugs.winehq.org/duplicates.cgi > The Page is present, but not configured to be useful for wine. > > The code is in the cvs, but I'm unable to help here (perl). > (Browse the cvs: "http://cvs.winehq.org/cvsweb/bugzilla/") > > Hmm, in principle one only needs to tweek at http://bugs.winehq.org/editparams.cgi the 'mostfreqthreshold' option. Running ./checksetup.pl doesn't harm either The essential task is to fill the duplicates table using the script: http://cvs.winehq.org/cvsweb/bugzilla/collectstats.pl You need to run it using cron. Tobias

March 22, 2006

CVS EU Server

by Sven.Paschukat＠t-online.de

Does anyone know what's wrong with the CVS server rhlx01.fht-esslingen.de in Europe? It's out of sync for a few days now. Sven

March 22, 2006

Bugzilla: Duplicates (was: Known issues area on main wiki page)

by Detlef Riekenberg

Tony Lambregts wrote: > Tom Spear wrote: >> On 3/21/06, *Vitaliy Margolen* <wine-devel(a)kievinfo.com >> <mailto:wine-devel(a)kievinfo.com>> wrote: >> >> I sure hope all users will go look at this page first. But some how I >> don't think they will. When we getting _exact_ duplicates with the > Keeping them around for a while even after they are fixed would be a > good idea since not everyone keeps up with the latest version of wine. > > [1] > http://bugs.winehq.org/show_bug.cgi?id=219 (SafeDisk) > http://bugs.winehq.org/show_bug.cgi?id=1631 (dsound: problem with underrun detection) > http://bugs.winehq.org/show_bug.cgi?id=1410 (mouse always recenterd) Just found, that gcc has "Most frequently reported Bugs": http://gcc.gnu.org/bugzilla/duplicates.cgi And since we have also bugzilla, i tested http://bugs.winehq.org/duplicates.cgi The Page is present, but not configured to be useful for wine. The code is in the cvs, but I'm unable to help here (perl). (Browse the cvs: "http://cvs.winehq.org/cvsweb/bugzilla/") -- By by ... Detlef

March 22, 2006

Re: What happened to the Fedora packages?

by Mike Hearn

On Wed, 22 Mar 2006 12:04:52 +0100, Francois Gouget wrote: > If compiling Wine crashes your computer!!! then something is wrong!!! > with your computer!!! You should really find out what!!! and fix it!!! > Otherwise you are likely to get problems running Wine!!! It's a bug in Wine, which I harassed AJ about a long time ago but it was never fixed I guess because he has a super-awesome machine :) Basically, compiling winetest causes gas to blow gigs of memory, because it's compiling like 50mb+ of assembly. I just hacked it out of the build system myself. There's nothing wrong with my machine except it being old ...

March 22, 2006

Re: Store GL context in the TEB

by Mike Hearn

On Tue, 21 Mar 2006 13:03:13 -0500, Wino Rojo wrote: > Where can I find more information about this, or a path to try? I'm > currently getting the BadMatch error and I would like to try this solution Just wait until it's merged then upgrade, it's the easiest way.

March 22, 2006

Re: Easy applications to write automated tests for?

by Dan Kegel

On 3/22/06, Molle Bestefich <molle.bestefich(a)gmail.com> wrote: > Ok. Cygwin does pretty well if you're using it as a single user / do > not use many processes/threads while pushing it CPU-wise. Right -- and I think we can hew to that limitation when using msys as part of a possible wine regression test. > Eg., Cygwin will be able to run a ./configure script just fine, too. Right, but modern cygwin is hard to support on wine, I think. The old snapshot in msys is probably easier. > > > There are a couple of other Windows-->Unix emulation kits readily > > > available, so shouldn't be hard to find something that both runs > > > reliably and can make ./configure scripts work... > > > > Oh, really? Got URLs? > > MKS Toolkit > http://www.mkssoftware.com/ Commercial, not a free download. There's a way to apply for a trial, but it's not easy, and you can't just download it. > Windows Services for Unix > http://www.microsoft.com/technet/interopmigration/unix/sfu/ I just tried it; it bombs on setup, complaining that the TCP/IP service isn't installed. But even if we fix that, downloading it requires a Microsoft Passport account and you have to fill out an intrusive questionaire. Also, there's no way of knowing when Microsoft will suspend free downloads. So I think that's out. Which kind of leaves us with msys/mingw as the prime contender, I think. For starters, all we have to do is verify, say, that it can build and run a hello, world app on wine. I think that even works right now! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 22, 2006

Re: WIDL: Add missing ignore attribute. Check for inapplicable attributes in typedef.

by Saveliy Tretiakov

I think it is still possible to implement meaningful error messages. A good overview of how this can be done is here: http://www.cs.nmsu.edu/~jeffery/merr.html. Anyway, if you disagree, I will resend patch with explicit error check. Alexandre Julliard wrote: > I think checking values explicitly is preferable to encoding them in > the syntax, since it gives you a chance to provide meaningful > errors. If you rely on the parser all you'll get is a generic "syntax > error" with no clue to what you did wrong. > >

March 22, 2006

Re: What happened to the Fedora packages?

by Segin

Neal Gompa wrote: > What happened to the Fedora packages? They have not been updated since > 0.9.2!!!! Right now it is at 0.9.10!!! Nearly every other Linux distro > supported has the up to date packages!!! And why does the Red Hat > packages site not go to the SourceForge site as it does for SUSE > packages and the others?? I have not really had the guts to ask until > now, because I thought that maybe there was a slump, but now, its > getting annoying!! And Fedora just released Fedora Core 5 yesterday!!! > Please tell me new packages will be ready soon!!! Compiling WINE > always crashes my computer, so I prefer to use the RPMs... > >------------------------------------------------------------------------ > > > > Is your computer also a Pentium 166MHz with 32MB of RAM? ... No, wait, even THAT can compile wine. Wine wasn't rated for 16MB systems, sorry. </sarcasam> Or in English: You need more RAM. When you run out of RAM, almost all UNIXes and clones have a kernel panic. Linux does either that, or it starts randomly killing off proccesses (your window manager, X, init, and so on) depending on it config at compile time. Please make sure you have enough swap, you have plenty of RAM (512MB or more), all of your toolkit conponets (gcc, binutils, etc.) are up to date, and that you don't have faulty hardware.

March 22, 2006

Re: Easy applications to write automated tests for?

by Molle Bestefich

Dan Kegel wrote: > Molle Bestefich wrote: > > Dimi Paun wrote: > > > Being able to run an emulation layer like msys/cygwin > > > > In my experience (couple of years worth of different Cygwin versions, > > all relatively new stuff), the Cygwin kernel emulation stuff is > > extremely unstable itself. > > unstable in the sense that it changes all the time, yes. No. Unstable in the sense that the core code is buggy. > msys, on the other hand, is working off a frozen snapshot > of cygwin from long ago, and never changes. > So it's stable in at least that sense. I have no idea > how buggy it is. It works well enough to run configure > scripts on real windows, though. Ok. Cygwin does pretty well if you're using it as a single user / do not use many processes/threads while pushing it CPU-wise. I'll agree that hobby usage (running a couple of Unix apps) is the most common use case for Cygwin, and it works well in that case. Eg., Cygwin will be able to run a ./configure script just fine, too. > > There are a couple of other Windows-->Unix emulation kits readily > > available, so shouldn't be hard to find something that both runs > > reliably and can make ./configure scripts work... > > Oh, really? Got URLs? MKS Toolkit http://www.mkssoftware.com/ Windows Services for Unix http://www.microsoft.com/technet/interopmigration/unix/sfu/ > Have you tried any of them on wine? Unfortunately, no.

March 22, 2006

Re: WIDL: Add missing ignore attribute. Check for inapplicable attributes in typedef.

by Alexandre Julliard

Saveliy Tretiakov <saveliyt(a)mail.ru> writes: > ChangeLog: > Saveliy Tretiakov <saveliyt(a)mail.ru> > - Add missing ignore attribute. > - Check for inapplicable attributes in typedef. Changed attribute > parsing in a way Mike McCormack suggested. > - Register type alias in typelib, if ATTR_PUBLIC is set. I think checking values explicitly is preferable to encoding them in the syntax, since it gives you a chance to provide meaningful errors. If you rely on the parser all you'll get is a generic "syntax error" with no clue to what you did wrong. -- Alexandre Julliard julliard(a)winehq.org

March 22, 2006

Re: What happened to the Fedora packages?

by Francois Gouget

On Tue, 21 Mar 2006, Neal Gompa wrote: > What happened to the Fedora packages? They have not been updated since > 0.9.2!!!! Right now it is at 0.9.10!!! Nearly every other Linux distro > supported has the up to date packages!!! And why does the Red Hat packages > site not go to the SourceForge site as it does for SUSE packages and the > others?? I have not really had the guts to ask until now, because I thought > that maybe there was a slump, but now, its getting annoying!! And Fedora > just released Fedora Core 5 yesterday!!! Please tell me new packages will be > ready soon!!! Compiling WINE always crashes my computer, so I prefer to use > the RPMs... If compiling Wine crashes your computer!!! then something is wrong!!! with your computer!!! You should really find out what!!! and fix it!!! Otherwise you are likely to get problems running Wine!!! Exclamation marks aside this is a good question. Is help needed to generate the RedHat packages? I'm not voluntering myself since I don't use Fedora<g>. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ 145 = 1! + 4! + 5!

March 22, 2006

Re: advpack: Forward AddDelBackupEntryA to its unicode counterpart

by Alexandre Julliard

"James Hawkins" <truiken(a)gmail.com> writes: > + do > + { > + MultiByteToWideChar(CP_ACP, 0, ansi_list, len, ptr, len); > + > + ansi_list += len; > + ptr += len; > + > + len = lstrlenA(ansi_list) + 1; > + size += len * sizeof(WCHAR); > + list = HeapReAlloc(GetProcessHeap(), 0, list, size); > + } while (*ansi_list); You are assuming that A and W have the same length, that's wrong. Also it will be quite expensive to resize the list all the time. You should determine the full length of the list and then convert everything in one go. -- Alexandre Julliard julliard(a)winehq.org

March 22, 2006

Re: What happened to the Fedora packages?

by Michel Ludwig

On Wed 22 Mar 2006 03:55, Neal Gompa wrote: > What happened to the Fedora packages? They have not been updated since > 0.9.2!!!! Right now it is at 0.9.10!!! Nearly every other Linux distro > supported has the up to date packages!!! And why does the Red Hat packages > site not go to the SourceForge site as it does for SUSE packages and the > others?? I have not really had the guts to ask until now, because I thought > that maybe there was a slump, but now, its getting annoying!! And Fedora > just released Fedora Core 5 yesterday!!! Please tell me new packages will > be ready soon!!! Compiling WINE always crashes my computer, so I prefer to > use the RPMs... Nice and decent Fedora Wine packages are in Fedora Extras: http://fedoraproject.org/extras/4/i386/repodata/repoview/W.group.html http://fedoraproject.org/extras/5/i386/repodata/repoview/W.group.html And even a "yum install wine" should do it (as root of course :-)).

March 22, 2006

Re: linux mmap bug ? not filling in allocation gaps

by Marcus Meissner

On Wed, Mar 22, 2006 at 12:11:27AM -0800, Geoff Brimhall wrote: > I've been debugging why an n64 emulator ( Project64 ) > gets "Failed to allocate memory" errors under wine > 9.9.10 on linux kernel 2.6. > > The program allocates a large chunk of size > 0x20100000, which succeeds, and then another large > 0x10100000 chunk, which fails. Do you have ulimits set? > I can't be the first person to notice this. Are there > any TODO solutions for this ? No. Ciao, Marcus

March 22, 2006

Re: linux mmap bug ? not filling in allocation gaps

by Mike McCormack

Geoff Brimhall wrote: > Wrote a test mmap binary to fill a process address > space, it created a similar gap between the executable > load address and the loaded shared libraries, > eventually failing mmap calls when it hit the stack > address space. When I updated the test app to > explicitly mmap in the gap area via specifying the > aligned start address, the mmap call succeeded. > > I can't be the first person to notice this. Are there > any TODO solutions for this ? Wine's holey memory map has been discussed before: http://www.winehq.com/pipermail/wine-devel/2006-February/044979.html The "truely correct" solution is probably to implement Windows compatible memory allocation in the Linux kernel, but there's other hacks that could be done in user space. Just a matter of finding something that Alexandre is willing to live with. A preload-ish type thing that overrode libc's mmap/munmap calls seems pausible to me. Mike

March 22, 2006

linux mmap bug ? not filling in allocation gaps

by Geoff Brimhall

I've been debugging why an n64 emulator ( Project64 ) gets "Failed to allocate memory" errors under wine 9.9.10 on linux kernel 2.6. The program allocates a large chunk of size 0x20100000, which succeeds, and then another large 0x10100000 chunk, which fails. WINEDEBUG=+relay,+virtual eventually brought me to look at the linux /proc/<pid>/maps to see if the address space was really fully allocated. Here's what I noticed: Address start - end: 00400000-0554000 - Project64.exe address 00554000-20000000 ---p large mem allocation *** <gap> *** 55555000-573e0000 - loaded shared libraries 573e0000-774e0000 ---p mem alloc of 0x20100000 7bf00000-7c003000 - wine-pthread 7c003000-7c1ee000 - [heap] 7ffe0000-fffe0000 ---p large mem allocation ffff7000-fffff000 - [stack] Wrote a test mmap binary to fill a process address space, it created a similar gap between the executable load address and the loaded shared libraries, eventually failing mmap calls when it hit the stack address space. When I updated the test app to explicitly mmap in the gap area via specifying the aligned start address, the mmap call succeeded. I can't be the first person to notice this. Are there any TODO solutions for this ? One linux-centric solution would be to look for gaps like this in /proc/<pid>/maps in the libs/wine/mmap.c and take advantage of this. Or maybe another would be to keep a table of address spaces returned in wine_anon_mmap as a guide, then validate with try_mmap_fixed as to where a next-allocation should occur ( would this solution work outside linux ) ? Thanks, geoff Brimhall __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

March 22, 2006

Re: Known issues area on main wiki page

by Tom Spear (Dustin Booker, Dustin Navea)

Tony Lambregts wrote: > Tom Spear wrote: >> On 3/21/06, *Vitaliy Margolen* <wine-devel(a)kievinfo.com >> <mailto:wine-devel(a)kievinfo.com>> wrote: >> >> I sure hope all users will go look at this page first. But some >> how I >> don't think they will. When we getting _exact_ duplicates with >> the same >> summary and almost identical comments. I don't think users will >> bother to >> look anywhere else. >> >> But that will add extra work on our side to keep this list in >> synch. On >> top of the usual stuff that we already do. >> >> Vitaliy. >> >> It wouldnt take much extra time outta my day to do it. 5 mins at max >> and only once I notice something is being reported rather >> frequently. I assume that these people who are reporting identical >> duplicates read some of the dodcumentation though, because otherwise >> they probably wouldn't have even known about winecfg. >> >> Tom >> > Keeping them around for a while even after they are fixed would be a > good idea since not everyone keeps up with the latest version of wine. > > Tony Lambregts > I didn't think about that, but you are right. I'll do something like Bug (x) - (Description) - Status: Resolved - Resolved as of wine v(x) Thanks Tom

March 22, 2006

What happened to the Fedora packages?

by Neal Gompa

What happened to the Fedora packages? They have not been updated since 0.9.2!!!! Right now it is at 0.9.10!!! Nearly every other Linux distro supported has the up to date packages!!! And why does the Red Hat packages site not go to the SourceForge site as it does for SUSE packages and the others?? I have not really had the guts to ask until now, because I thought that maybe there was a slump, but now, its getting annoying!! And Fedora just released Fedora Core 5 yesterday!!! Please tell me new packages will be ready soon!!! Compiling WINE always crashes my computer, so I prefer to use the RPMs...

March 22, 2006

Re: x11drv: (bug 4685) some ALT+key combos processed incorrectly

by Vitaliy Margolen

Tuesday, March 21, 2006, 3:49:53 PM, tkho(a)ucla.edu wrote: > Patch to recognize VK_LMENU and VK_RMENU in alt-key combos (bug 4685) > This patch looks for VK_LMENU and VK_RMENU in addition to VK_MENU when dealing > with ALT-key combo messages. This is the easiest way to add this functionality, > but arguably not the cleanest. > 2006-03-21 Thomas Kho <tkho(a)ucla.edu> > * dlls/x11drv/keyboard.c > x11drv: recognize VK_LMENU and VK_RMENU in ALT-key combos I'm sorry but this is further away from native, not closer. I just made some tests, and native sets/clears VM_MENU whenever right or left ALT is pressed/depressed. So we should be doing the same thing. Btw exactly the same thing happens with CONTROL & SHIFT. I will try to send these tests today-tomorrow. But you could try that yourself using SendInput(). Vitaliy Margolen

March 22, 2006

Re: Known issues area on main wiki page

by Tom Spear (Dustin Booker, Dustin Navea)

Segin wrote: > Tony Lambregts wrote: >> Tom Spear wrote: >>> On 3/21/06, **Vitaliy Margolen** <wine-devel(a)kievinfo.com >>> <mailto:wine-devel(a)kievinfo.com>> wrote: >>> >>> [...] >> [...] >> Keeping them around for a while even after they are fixed would be a >> good idea since not everyone keeps up with the latest version of wine. > I have an idea, let's add a update check program to wine, so that when > a person run it, they get to know what the latest version is, and > their current version, plus make a standard executable of it for use > on older versions. That is a good supplement, but we already have the wine-announce mailing list. I guess you are right though, not everyone subscribes to it that uses wine. Tom

March 22, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime

by Stefan Dösinger

Am Dienstag, 21. März 2006 23:31 schrieb Lionel Ulmer: > > What says that a gl context can be used by one thread only? In the > > glxDestroyContext man page it sounds like a context has a sort of > > reference count, and it can be used by multiple threads. > > man glXMakeCurrent > > BadAccess is generated if ctx was current to another > thread at the time glXMakeCurrent was called. > > Seems pretty clear to me, but well, my man pages may be outdated :-) Indeed. I must have overloocked it :-| Thanks for the clarification

March 21, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime

by Lionel Ulmer

> What says that a gl context can be used by one thread only? In the > glxDestroyContext man page it sounds like a context has a sort of reference > count, and it can be used by multiple threads. man glXMakeCurrent BadAccess is generated if ctx was current to another thread at the time glXMakeCurrent was called. Seems pretty clear to me, but well, my man pages may be outdated :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

March 21, 2006

Re: WaitForMultipleObjectsEx will not take up to MAXIMUM_WAIT_OBJECTS

by Dan Kegel

On 3/21/06, Bryan Mayland <bmayland(a)leoninedev.com> wrote: > Dan Kegel wrote: > > Yes. Make the code as small and simple as possible > > to check that one limit. > > > I've sent the patch to wine-patches as suggested at winehq. I'm not > subscribed to that list though, so let me know if there are any problems > receiving it or you don't like the test case. I haven't seen it yet at http://www.winehq.org/pipermail/wine-patches/2006-March/ so perhaps there was some trouble with mail. Did you make sure the test passed on both wine and windows when built as a standalone program? e.g. if you happen to have msvc and the platform sdk installed, and have your environment set up right, you can just do cd dlls/kernell/tests cl -DSTANDALONE -D_X86_ -I../../../include sync.c to compile the test as a standalone app, and then run sync.exe on both Windows and Wine. - Dan > > -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 21, 2006

Re: WaitForMultipleObjectsEx will not take up to MAXIMUM_WAIT_OBJECTS

by Bryan Mayland

Dan Kegel wrote: > Yes. Make the code as small and simple as possible > to check that one limit. > I've sent the patch to wine-patches as suggested at winehq. I'm not subscribed to that list though, so let me know if there are any problems receiving it or you don't like the test case. Thanks for your guidance!

March 21, 2006

Re: WaitForMultipleObjectsEx will not take up to MAXIMUM_WAIT_OBJECTS

by Dan Kegel

On 3/21/06, Bryan Mayland <bmayland(a)leoninedev.com> wrote: > ...My test app is 150 lines of ugly > code whose purpose was to narrow down where the problem was, which was > that MAXIMUM_WAIT_OBJECTS weren't supported. You probably don't want to > put all that socket code in just to test the event system. Right. > Should the > test I create actually just create MAXIMUM_WAIT_OBJECTS events and do a > wait on them to verify that it can be done? Yes. Make the code as small and simple as possible to check that one limit. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 21, 2006

Re: WaitForMultipleObjectsEx will not take up to MAXIMUM_WAIT_OBJECTS

by Bryan Mayland

Dan Kegel wrote: > Congratulations, sounds like you found a bug in Wine! > Yay! I'm glad I'm not crazy. > Looks like it should be changed. > > You've helped greatly with your post. > You could help even more by posting a patch > that modifies dlls/kernel/tests/sync.c to incorporate your test > and also fixes the error. Yeah this is no problem at all. My test app is 150 lines of ugly code whose purpose was to narrow down where the problem was, which was that MAXIMUM_WAIT_OBJECTS weren't supported. You probably don't want to put all that socket code in just to test the event system. Should the test I create actually just create MAXIMUM_WAIT_OBJECTS events and do a wait on them to verify that it can be done?

March 21, 2006

Re: Wine and RDPRINT

by Frederico Bertucci

I try run this patch, but it not works still... some have another idea, or patch to run... with windows app works okay but with this specific application that uses rdprint, does not work... -- Frederico Bertucci e-mail / msn: fred(a)netbil.com.br www.netbil.com.br NetBil - Redes e Internet 18-3659-2444 XxX Linux for work Linux for fun XxX --------- Mensagem Original -------- De: Mariusz Kie³piñski <kielpi(a)poczta.onet.pl> Para: wine-devel(a)winehq.org <wine-devel(a)winehq.org> Assunto: Re: Wine and RDPRINT Data: 17/03/06 17:40 > > Dnia pi±tek, 17 marca 2006 14:35, Frederico Bertucci napisa³: > Hi > > Good morning guys > > > > I did my system works with wine no problem, but when I try print using > > then, doesnt work... if I print from any other aplication, works. > > > > I talked with my developer and he told me that are using a delphi componet > > called RDPRINT, this in windows, to create better graphics. > > > > So, Are there any way to print in wine, using this RDPRINT ?? any dll, any > > configuration > > > > I am using latest wine configured with winetools, the printer is a lx300. > > > > I am trying do this works since 2 weeks ago and not sucefull > > > > Tks guys > > > > > > try this patch > > > ================================= > > wine.15.03.06.19.02.59.diff > ? dlls/msvideo/Makefile > ? dlls/win32s/Makefile > ? dlls/winsock/Makefile > ? dlls/winsock/libws2_32.def > ? dlls/winsock/version.res > ? dlls/winsock/tests/Makefile > ? dlls/winsock/tests/testlist.c > Index: dlls/gdi/printdrv.c > =================================================================== > RCS file: /home/wine/wine/dlls/gdi/printdrv.c,v > retrieving revision 1.46 > diff -u -p -1 -r1.46 printdrv.c > --- dlls/gdi/printdrv.c 12 Sep 2005 10:30:06 -0000 1.46 > +++ dlls/gdi/printdrv.c 15 Mar 2006 18:03:01 -0000 > @@ -471,3 +471,3 @@ static int CreateSpoolFile(LPCSTR pszOut > if (!psCmd[0] && !strncmp("LPR:",pszOutput,4)) > - sprintf(psCmd,"|lpr -P%s",pszOutput+4); > + sprintf(psCmd,"|lp -d'%s' ",pszOutput+4); > > > ======================================= > > > > > > > > > > > > > > ________________________________________________ :: NetBil :: :: A escolha certa em Internet ::

March 21, 2006

re: WaitForMultipleObjectsEx will not take up to MAXIMUM_WAIT_OBJECTS

by Dan Kegel

Bryan Mayland wrote: > dlls/kernel/sync.c:173: > 176 if (count >= MAXIMUM_WAIT_OBJECTS) > 177 { > 178 SetLastError(ERROR_INVALID_PARAMETER); > 179 return WAIT_FAILED; > > Windows supports up to and including that number, wine only supports up > to that number. Congratulations, sounds like you found a bug in Wine! > Since the rest of the code actually does support the > full 64 wait objects, is there any reason this should not be changed to > 176 if (count > MAXIMUM_WAIT_OBJECTS) Looks like it should be changed. You've helped greatly with your post. You could help even more by posting a patch that modifies dlls/kernel/tests/sync.c to incorporate your test and also fixes the error. Feel up to it? Just yell if you need help. Thanks! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 21, 2006

Re: Known issues area on main wiki page

by Segin

Tony Lambregts wrote: > Tom Spear wrote: > >> On 3/21/06, **Vitaliy Margolen** <wine-devel(a)kievinfo.com >> <mailto:wine-devel(a)kievinfo.com>> wrote: >> >> [...] > > [...] > Keeping them around for a while even after they are fixed would be a > good idea since not everyone keeps up with the latest version of wine. I have an idea, let's add a update check program to wine, so that when a person run it, they get to know what the latest version is, and their current version, plus make a standard executable of it for use on older versions.

March 21, 2006

Re: edit: Only adjust margins if the edit control is above a certain size.

by Alexandre Julliard

Huw D M Davies <h.davies1(a)physics.ox.ac.uk> writes: > Huw Davies <huw(a)codeweavers.com> > edit: Only adjust the margins if the edit control is above a certain > size. This breaks the tests here: edit.c:788: Test failed: got 0 edit.c:789: Test failed: got 0 edit.c:802: Test failed: got 0 edit.c:808: Test failed: got 0 edit.c:809: Test failed: got 0 edit.c:813: Test failed: got 0 edit.c:814: Test failed: got 0 edit.c:817: Test failed: got 0 edit.c:818: Test failed: got 0 edit.c:840: Test failed: got 0 edit.c:841: Test failed: got 0 make[1]: *** [edit.ok] Error 11 -- Alexandre Julliard julliard(a)winehq.org

March 21, 2006

Re: Known issues area on main wiki page

by Tony Lambregts

Tom Spear wrote: > On 3/21/06, *Vitaliy Margolen* <wine-devel(a)kievinfo.com > <mailto:wine-devel(a)kievinfo.com>> wrote: > > I sure hope all users will go look at this page first. But some how I > don't think they will. When we getting _exact_ duplicates with the same > summary and almost identical comments. I don't think users will > bother to > look anywhere else. > > But that will add extra work on our side to keep this list in synch. On > top of the usual stuff that we already do. > > Vitaliy. > > It wouldnt take much extra time outta my day to do it. 5 mins at max > and only once I notice something is being reported rather frequently. I > assume that these people who are reporting identical duplicates read > some of the dodcumentation though, because otherwise they probably > wouldn't have even known about winecfg. > > Tom > One Major advantage is that even if people keep on reporting duplicates then it will make it easier for those people doing QA in Bugzilla. If they have a place to go when they think a bug is a duplicate instead of having to search for or remember the bug numbers[1]. Keeping them around for a while even after they are fixed would be a good idea since not everyone keeps up with the latest version of wine. [1] http://bugs.winehq.org/show_bug.cgi?id=219 (SafeDisk) http://bugs.winehq.org/show_bug.cgi?id=1631 (dsound: problem with underrun detection) http://bugs.winehq.org/show_bug.cgi?id=1410 (mouse always recenterd) -- Tony Lambregts

March 21, 2006

Re: Store GL context in the TEB

by Wino Rojo

Hi Tom, Where can I find more information about this, or a path to try? I'm currently getting the BadMatch error and I would like to try this solution Thanks, W >From: Tomas Carnecky <tom(a)dbservice.com> >To: wine-devel(a)winehq.org >Subject: Re: Store GL context in the TEB >Date: Tue, 21 Mar 2006 18:04:39 +0100 > >Mike Hearn wrote: > > Mike Hearn <mike(a)plan99.net> > > Optimize thunks by storing GL context in the thread environment block > > > >good job. this fixed the BadMatch error in World of Warcraft and also >increased performance, from ~20fps to ~25fps. > >tom > > _________________________________________________________________ Take advantage of powerful junk e-mail filters built on patented Microsoft® SmartScreen Technology. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht… Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.

March 21, 2006

WaitForMultipleObjectsEx will not take up to MAXIMUM_WAIT_OBJECTS

by Bryan Mayland

I've been digging into why versions of uTorrent greater than 1.1.3 do not work under the latest wine and tracked it down to their use of WSAEventSelects to receive socket notifications. I created a small test application which mimics this behavior which works under WindowsXP but not wine. The problem is that they create MAXIMUM_WAIT_OBJECTS events and pass them to WaitForMultipleObjectsEx. That function bails out early due to dlls/kernel/sync.c:173: 176 if (count >= MAXIMUM_WAIT_OBJECTS) 177 { 178 SetLastError(ERROR_INVALID_PARAMETER); 179 return WAIT_FAILED; 180 } Windows supports up to and including that number, wine only supports up to that number. Since the rest of the code actually does support the full 64 wait objects, is there any reason this should not be changed to 176 if (count > MAXIMUM_WAIT_OBJECTS)

March 21, 2006

Re: Store GL context in the TEB

by Tomas Carnecky

Mike Hearn wrote: > Mike Hearn <mike(a)plan99.net> > Optimize thunks by storing GL context in the thread environment block > good job. this fixed the BadMatch error in World of Warcraft and also increased performance, from ~20fps to ~25fps. tom

March 21, 2006

Re: OLEAUT32: bug 4502 - request for comment before trying to fix

by Robert Shearman

Dan Kegel wrote: >On 3/19/06, Dan Kegel <dank(a)kegel.com> wrote: > > >>Alex wrote: >> >> >>>It seems that I will have to wait until I code >>>enough of a test case for a *successful* >>>ITypeInfo::Invoke() >>> >>> > >A few more vaguely relevant notes: >http://codeguru.earthweb.com/Cpp/COM-Tech/atl/article.php/c3565/ >briefly mentions how ATL uses ITypeInfo::Invoke(). >http://www.opengroup.org/onlinepubs/009899899/CHP18GDC.HTM >is the Open Group's documentation for ActiveX (!) which also >covers this a bit. And, more usefully, >http://groups.google.com/group/comp.os.ms-windows.programmer.ole/msg/c1417f… >says: >0) Call CoCreateInstance() to get a pointer to the object >1) Create a ITypeLib interface (via the 'LoadTypeLib' API function). >2) Call ITypeLib::GetTypeInfo to obtain ITypeInfo interface. >3) Call ITypeInfo::Invoke (almost like IDispatch::Invoke) >which is exactly what I was starting to gather by >reading the Automation and Type Libraries chapters of "Essence of COM". > I appreciate the effort, but none of those sources provide any more information than that present on MSDN, and even MSDN is woefully inadequate on the behaviour of the function in less common cases. Attached is a test case that covers a bit of the functionality in ITypeInfo::Invoke. -- Rob Shearman

March 21, 2006

Re: Known issues area on main wiki page

by Tom Spear

On 3/21/06, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > > Tuesday, March 21, 2006, 8:38:48 AM, Tom Spear wrote: > > On 3/21/06, Robert Reif <reif(a)earthlink.net> wrote:Tom Spear (Dustin > Booker, Dustin Navea) wrote: > > >> Jesse Allen wrote: > >> > >>> On 3/20/06, Mike McCormack <mike(a)codeweavers.com> wrote: > >>> > >>> > >>>> Dimi Paun wrote: > >>>> > >>>> > >>>>> On Mon, 2006-03-20 at 22:28 -0600, Tom Spear (Dustin Booker, Dustin > >>>>> Navea) wrote: > >>>>> > >>>>> > >>>>> > >>>>>> clicking on the audio tab to check out bug 4051 first? Please! > >>>>>> > >>>>> > >>>>> How about we fix the problem instead? :) > >>>>> > >>>> > >>>> The best way to fix it is probably to rearrange the code so that the > >>>> Audio tab shows, then there's a [Detect] button that the user can > click > >>>> to run the autodetect code that might crash.At least then the user > >>>> can > >>>> set their Wine Audio settings manually. > >>>> > >>>> Mike > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> This is not enough, as when I click the audio tab, it will lock up in > >>> the kernel.I already identified where it happens and patch the > >>> kernel myself.I told the ALSA devs, but they haven't looked at why > >>> certain register usage causes a lockup.So it remains in the stable > >>> kernel who knows who else hits it. > >>> > >>> Jesse > >>> > >>> > >> > >> Which is why I agree with the ideas from Mike and Dimi AND Segin.. > >> Why not put an autodetect button, have the exception handler catch the > >> crash if arts decides to die, and then still have a popup dialog for > >> when arts is manually selected that tells users it is buggy and not > >> recommended to use?That doesn't fix your specific problem Jesse, I > >> know, but at least it keeps winecfg open when you click on the audio > tab. > >> > >> Tom > >> > >> > >> > > The reason I added the probe of all drivers in winecfg was so that the > > broken and marginal drivers would get used and hopefully fixed.Moving > > the problem will just create different bugs: [BUG xxx] winecfg crashes > > when autodetect button pressed or [BUG yyy] winecfg crashes when driver > > xyz selected. > > > > > > > Yes, and I agree that that is a good idea, which is why I asked > > about putting a known issues page somewhere where a lot of users will > > see it. It wouldnt just have to be used for the issue mentioned > > above. It could be done for anything that is frequently reported. I'm > > going to go ahead and get started on putting it in tonight. Since it > > will be in the wiki, as the issues are fixed, they can be removed, and > > as other issues become more frequently reported, they can be added. I > > think it will be a good supplement to bugzilla and the appdb, as more > > people check out wiki's (as well as README's) than do the appdb, and so > > therefore they will see that the issue is already reported, and can > > find out what bug # it is instead of filing a duplicate bug. It also > > helps cut down on the number of bug submissions in the comments of the > > appdb.. > > I sure hope all users will go look at this page first. But some how I > don't think they will. When we getting _exact_ duplicates with the same > summary and almost identical comments. I don't think users will bother to > look anywhere else. > > But that will add extra work on our side to keep this list in synch. On > top of the usual stuff that we already do. > > Vitaliy. > > > > > It wouldnt take much extra time outta my day to do it. 5 mins at max and only once I notice something is being reported rather frequently. I assume that these people who are reporting identical duplicates read some of the dodcumentation though, because otherwise they probably wouldn't have even known about winecfg. Tom

March 21, 2006

Re: Known issues area on main wiki page

by Vitaliy Margolen

Tuesday, March 21, 2006, 8:38:48 AM, Tom Spear wrote: > On 3/21/06, Robert Reif <reif(a)earthlink.net> wrote:Tom Spear (Dustin Booker, Dustin Navea) wrote: >> Jesse Allen wrote: >> >>> On 3/20/06, Mike McCormack <mike(a)codeweavers.com> wrote: >>> >>> >>>> Dimi Paun wrote: >>>> >>>> >>>>> On Mon, 2006-03-20 at 22:28 -0600, Tom Spear (Dustin Booker, Dustin >>>>> Navea) wrote: >>>>> >>>>> >>>>> >>>>>> clicking on the audio tab to check out bug 4051 first? Please! >>>>>> >>>>> >>>>> How about we fix the problem instead? :) >>>>> >>>> >>>> The best way to fix it is probably to rearrange the code so that the >>>> Audio tab shows, then there's a [Detect] button that the user can click >>>> to run the autodetect code that might crash. At least then the user >>>> can >>>> set their Wine Audio settings manually. >>>> >>>> Mike >>>> >>>> >>>> >>> >>> >>> >>> This is not enough, as when I click the audio tab, it will lock up in >>> the kernel. I already identified where it happens and patch the >>> kernel myself. I told the ALSA devs, but they haven't looked at why >>> certain register usage causes a lockup. So it remains in the stable >>> kernel who knows who else hits it. >>> >>> Jesse >>> >>> >> >> Which is why I agree with the ideas from Mike and Dimi AND Segin.. >> Why not put an autodetect button, have the exception handler catch the >> crash if arts decides to die, and then still have a popup dialog for >> when arts is manually selected that tells users it is buggy and not >> recommended to use? That doesn't fix your specific problem Jesse, I >> know, but at least it keeps winecfg open when you click on the audio tab. >> >> Tom >> >> >> > The reason I added the probe of all drivers in winecfg was so that the > broken and marginal drivers would get used and hopefully fixed. Moving > the problem will just create different bugs: [BUG xxx] winecfg crashes > when autodetect button pressed or [BUG yyy] winecfg crashes when driver > xyz selected. > Yes, and I agree that that is a good idea, which is why I asked > about putting a known issues page somewhere where a lot of users will > see it. It wouldnt just have to be used for the issue mentioned > above. It could be done for anything that is frequently reported. I'm > going to go ahead and get started on putting it in tonight. Since it > will be in the wiki, as the issues are fixed, they can be removed, and > as other issues become more frequently reported, they can be added. I > think it will be a good supplement to bugzilla and the appdb, as more > people check out wiki's (as well as README's) than do the appdb, and so > therefore they will see that the issue is already reported, and can > find out what bug # it is instead of filing a duplicate bug. It also > helps cut down on the number of bug submissions in the comments of the > appdb.. I sure hope all users will go look at this page first. But some how I don't think they will. When we getting _exact_ duplicates with the same summary and almost identical comments. I don't think users will bother to look anywhere else. But that will add extra work on our side to keep this list in synch. On top of the usual stuff that we already do. Vitaliy.

March 21, 2006

Re: Known issues area on main wiki page

by Chris Morgan

> aRts in and of itself is a buggy hack, KDE is droipping it in the 4.0 > release, Skype crashes if you use artsdsp with it and play sound, arts is > also known to just segfault for no reason whatsoever. Best suggestion is to > drop support for aRts entirely, it won't be around much longer. Arts has been unmaintained for many years now. As the original author I was on the mailing list for a number of years and support was bad even when the arts plugin was originally written. The website documentation was out of date, it was difficult to find the latest version of the code. If there is something we can do to get arts working now that would be great since many people still use it and will continue to do so for some years. I'm certainly looking forward to when it is end-of-lifed with kde 4.0. Chris

March 21, 2006

Re: [WINEDOCS] add question on Intel MacOS X

by Emmanuel Maillard

Hi, The plan for porting Darwine/ppc is to use qemu either Bochs. Thanks Emmanuel Le 21 mars 06 à 06:48, Brian Vincent a écrit : > Are there any other FAQ additions anyone wants to see? There's at > least one other one I was thinking of adding but have since forgotten. > > Changelog: > Brian Vincent > Explicitly address Intel Mac OS X. > > Index: en/wine-faq.sgml > =================================================================== > RCS file: /cvsroot/wine/docs/en/wine-faq.sgml,v > retrieving revision 1.15 > diff -u -u -r1.15 wine-faq.sgml > --- en/wine-faq.sgml 1 Feb 2006 04:47:04 -0000 1.15 > +++ en/wine-faq.sgml 21 Mar 2006 05:45:34 -0000 > @@ -591,9 +591,12 @@ > <para> > Mac OS X / Darwin: The <ulink > url="http://darwine.opendarwin.org/">Darwine</ulink> > project is > - currently working on porting Wine to the Darwin/x86 > platform. Their > - goal is to eventually make it possible to run x86 Windows > + currently working on porting Wine to the Darwin/x86 > platform. > + Their goal is to eventually make it possible to run x86 > Windows > applications on Darwin/PPC and then Mac OS X by using > Bochs. > + In addition, CodeWeavers has focused some of their > resources on > + Intel Mac OS X as well. With a little luck, Wine will > be running on > + it by the third quarter of 2006. > </para> > <para> > FreeBSD: This port is well maintained and should work with > @@ -606,7 +609,32 @@ > </para> > </answer> > </qandaentry> > - > + <qandaentry> > + <question id="Will-wine-run-on-macintel"> > + <para> > + I want to run Wine on an Intel Mac OS X (MacIntel) > system, will it > + work? > + </para> > + </question> > + <answer> > + <para> > + (Also see the previous question.) As of March, 2006, > simple > + applications are just beginning to to run on Intel Mac > OS X. > + It's possible in about 6 months we'll see applications > running > + similarly to how they do on Linux or FreeBSD. > + </para> > + <para> > + There are some complicated issues surrounding Wine on > Mac OS X. > + Working with low-level features, such as signal handling > and system > + registers, are quite different on Mac OS X. Further > hampering > + the issue are some bugs within the operating system. > Beyond > + that, integration on Mac OS X becomes difficult because > it is > + vastly different than a traditional *nix desktop. Menuing > + and graphics drivers are just two areas that require a > complete > + reimplementation in order to be functional. > + </para> > + </answer> > + </qanaentry> > <qandaentry> > <question id="What-minimum-CPU-must-I-have"> > <para> > >

March 21, 2006

Re: Known issues area on main wiki page

by Tom Spear

On 3/21/06, Robert Reif <reif(a)earthlink.net> wrote: > > Tom Spear (Dustin Booker, Dustin Navea) wrote: > > > Jesse Allen wrote: > > > >> On 3/20/06, Mike McCormack <mike(a)codeweavers.com> wrote: > >> > >> > >>> Dimi Paun wrote: > >>> > >>> > >>>> On Mon, 2006-03-20 at 22:28 -0600, Tom Spear (Dustin Booker, Dustin > >>>> Navea) wrote: > >>>> > >>>> > >>>> > >>>>> clicking on the audio tab to check out bug 4051 first? Please! > >>>>> > >>>> > >>>> How about we fix the problem instead? :) > >>>> > >>> > >>> The best way to fix it is probably to rearrange the code so that the > >>> Audio tab shows, then there's a [Detect] button that the user can > click > >>> to run the autodetect code that might crash. At least then the user > >>> can > >>> set their Wine Audio settings manually. > >>> > >>> Mike > >>> > >>> > >>> > >> > >> > >> > >> This is not enough, as when I click the audio tab, it will lock up in > >> the kernel. I already identified where it happens and patch the > >> kernel myself. I told the ALSA devs, but they haven't looked at why > >> certain register usage causes a lockup. So it remains in the stable > >> kernel who knows who else hits it. > >> > >> Jesse > >> > >> > > > > Which is why I agree with the ideas from Mike and Dimi AND Segin.. > > Why not put an autodetect button, have the exception handler catch the > > crash if arts decides to die, and then still have a popup dialog for > > when arts is manually selected that tells users it is buggy and not > > recommended to use? That doesn't fix your specific problem Jesse, I > > know, but at least it keeps winecfg open when you click on the audio > tab. > > > > Tom > > > > > > > The reason I added the probe of all drivers in winecfg was so that the > broken and marginal drivers would get used and hopefully fixed. Moving > the problem will just create different bugs: [BUG xxx] winecfg crashes > when autodetect button pressed or [BUG yyy] winecfg crashes when driver > xyz selected. > > Yes, and I agree that that is a good idea, which is why I asked about putting a known issues page somewhere where a lot of users will see it. It wouldnt just have to be used for the issue mentioned above. It could be done for anything that is frequently reported. I'm going to go ahead and get started on putting it in tonight. Since it will be in the wiki, as the issues are fixed, they can be removed, and as other issues become more frequently reported, they can be added. I think it will be a good supplement to bugzilla and the appdb, as more people check out wiki's (as well as README's) than do the appdb, and so therefore they will see that the issue is already reported, and can find out what bug # it is instead of filing a duplicate bug. It also helps cut down on the number of bug submissions in the comments of the appdb.. Tom

March 21, 2006

Re: IAMMultiMediaStream::OpenFile

by Robert Shearman

Ivan Leo Puoti wrote: >@@ -282,9 +283,15 @@ > { > IAMMultiMediaStreamImpl *This = (IAMMultiMediaStreamImpl *)iface; > >- FIXME("(%p/%p)->(%s,%lx) stub!\n", This, iface, debugstr_w(pszFileName), dwFlags); >+ TRACE("(%p/%p)->(%s,%lx)\n", This, iface, debugstr_w(pszFileName), dwFlags); > >- return E_NOTIMPL; >+ /* We should check the file format and fail to open it if we can't reder it */ >+ >+ This->FileHandle = CreateFileW(pszFileName, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL); >+ if(This->FileHandle == INVALID_HANLDE_VALUE) >+ return E_FAIL; >+ >+ return CoCreateInstance(&CLSID_FilterGraph, NULL, CLSCTX_INPROC_SERVER, &IID_IGraphBuilder, (LPVOID*)&This->pFilterGraph); > } > This is wrong. Here is the pseudo-code I sent to Peter Åstrand for the very same function: CoCreateInstance with IFileSourceFilter on CLSID_AsyncReader. Call IFileSourceFilter_Load. Get the output pin and stash it in This. Call IGraphBuilder_AddSourceFilter. Then IAMMultiMediaStreamImpl_Render should do the following: Call IGraphBuilder_Render using the pin previously stashed away. -- Rob Shearman

March 21, 2006

Re: IAMMultiMediaStream::OpenFile

by Dmitry Timoshkov

"Ivan Leo Puoti" <ivanleo(a)gmail.com> wrote: > + HANDLE FileHandle; > + This->FileHandle = CreateFileW(pszFileName, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL); > + if(This->FileHandle == INVALID_HANLDE_VALUE) > + return E_FAIL; I guess that you need to close that file handle somewhere. -- Dmitry.

March 21, 2006

Re: GoogleEarth

by Jeff Latimer

I have been looking at uniscribe functions which have been partially implemented. After I implement a few functions it was reported that GoogleEarth did not crash any more but did not display text. I think you will have to wait till more uniscribe is implemented or look at the code yourself. I will be having a look at more of it over the next couple of weeks. Jeff James Courtier-Dutton wrote: >Hi, > >Can one run GoogleEarth under wine? >It does not seem to run here under the default settings. > >James > > > > > > > >

March 21, 2006

Re: Known issues area on main wiki page

by Robert Reif

Tom Spear (Dustin Booker, Dustin Navea) wrote: > Jesse Allen wrote: > >> On 3/20/06, Mike McCormack <mike(a)codeweavers.com> wrote: >> >> >>> Dimi Paun wrote: >>> >>> >>>> On Mon, 2006-03-20 at 22:28 -0600, Tom Spear (Dustin Booker, Dustin >>>> Navea) wrote: >>>> >>>> >>>> >>>>> clicking on the audio tab to check out bug 4051 first? Please! >>>>> >>>> >>>> How about we fix the problem instead? :) >>>> >>> >>> The best way to fix it is probably to rearrange the code so that the >>> Audio tab shows, then there's a [Detect] button that the user can click >>> to run the autodetect code that might crash. At least then the user >>> can >>> set their Wine Audio settings manually. >>> >>> Mike >>> >>> >>> >> >> >> >> This is not enough, as when I click the audio tab, it will lock up in >> the kernel. I already identified where it happens and patch the >> kernel myself. I told the ALSA devs, but they haven't looked at why >> certain register usage causes a lockup. So it remains in the stable >> kernel who knows who else hits it. >> >> Jesse >> >> > > Which is why I agree with the ideas from Mike and Dimi AND Segin.. > Why not put an autodetect button, have the exception handler catch the > crash if arts decides to die, and then still have a popup dialog for > when arts is manually selected that tells users it is buggy and not > recommended to use? That doesn't fix your specific problem Jesse, I > know, but at least it keeps winecfg open when you click on the audio tab. > > Tom > > > The reason I added the probe of all drivers in winecfg was so that the broken and marginal drivers would get used and hopefully fixed. Moving the problem will just create different bugs: [BUG xxx] winecfg crashes when autodetect button pressed or [BUG yyy] winecfg crashes when driver xyz selected.

March 21, 2006

Re: Known issues area on main wiki page

by Tom Spear (Dustin Booker, Dustin Navea)

Jesse Allen wrote: > On 3/20/06, Mike McCormack <mike(a)codeweavers.com> wrote: > >> Dimi Paun wrote: >> >>> On Mon, 2006-03-20 at 22:28 -0600, Tom Spear (Dustin Booker, Dustin >>> Navea) wrote: >>> >>> >>>> clicking on the audio tab to check out bug 4051 first? Please! >>>> >>> How about we fix the problem instead? :) >>> >> The best way to fix it is probably to rearrange the code so that the >> Audio tab shows, then there's a [Detect] button that the user can click >> to run the autodetect code that might crash. At least then the user can >> set their Wine Audio settings manually. >> >> Mike >> >> >> > > > This is not enough, as when I click the audio tab, it will lock up in > the kernel. I already identified where it happens and patch the > kernel myself. I told the ALSA devs, but they haven't looked at why > certain register usage causes a lockup. So it remains in the stable > kernel who knows who else hits it. > > Jesse > > Which is why I agree with the ideas from Mike and Dimi AND Segin.. Why not put an autodetect button, have the exception handler catch the crash if arts decides to die, and then still have a popup dialog for when arts is manually selected that tells users it is buggy and not recommended to use? That doesn't fix your specific problem Jesse, I know, but at least it keeps winecfg open when you click on the audio tab. Tom

March 21, 2006

Re: winedbg: resend - add display for floating point status

by Jeff Latimer

Eric Pouech wrote: > - first, I don't think it's worthwhile to add another method to the > CPU backend. Adding a boolean (as parameter) to print_context should do. I thought you meant that I needed a new method, might have come at it differently I if I had understood the parser at the beginning rather than tackle it at the end. I am not sure why the extra method is not a good thing. Is it a maintenance issue? > - you also need to fix all the be_*.c files (for amd, ppc...) as well. > Otherwise, they won't compile. The rule of thumb is never commit a > patch that breaks compilation on some platforms. I think I see what you mean about needing to fix all the be_*.c files. My patch would cause a problem in that the method was not present for the other OS's, hence the INFO command would fail. In anycase I can see the work to be done. Will take a day or two. > - one of the test looks suspicious (shouldn't it be if > (!(ctx->loatSave.StatusWord & 0x00000001)) instead ?) > >> + if (!ctx->FloatSave.StatusWord & 0x00000001) > Point taken about the test and will fix though it did not seem to cause a problem. > A+ > Jeff

March 21, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime

by Raphael

Hi Stefan, On Tuesday 21 March 2006 01:41, Stefan Dösinger wrote: > Am Montag, 20. März 2006 23:26 schrieb Lionel Ulmer: > > Well, in OpenGL each thread can have its own context (and you can also > > bind a context to only one thread which explains why multi-threaded D3D > > applications are such a pain to support). So you can have multi-threaded > > GL applications with each thread having its own GL context. > > What says that a gl context can be used by one thread only? In the > glxDestroyContext man page it sounds like a context has a sort of reference > count, and it can be used by multiple threads. You're right you can use the same context for many threads. you only have to "map" it to each threads (using MakeCurrent APIs) Anyway i have seen many problems when using the same context active for too many threads (seems the nvidia drivers don't like this kind of behavior) > A little bit OT, but related to multi-threaded opengl is a bug in the dri > radeon driver(https://bugs.freedesktop.org/show_bug.cgi?id=6240). I've > reported it to the dri devs but didn't get any response so far. :) > Stefan Regards, Raphael

March 21, 2006

Re: Known issues area on main wiki page

by Segin

Mike McCormack wrote: > > Segin wrote: > >> aRts in and of itself is a b/uggy ha/ck, KDE is droipping it in the >> 4.0 release, Skype crashes if you use artsdsp with it and play sound, >> arts is also known to just segfault for no reason whatsoever. Best >> suggestion is to drop support for aRts entirely, it won't be around >> much longer. > > > aRts is not the only library giving trouble here. Here's one caused by > ALSA: > > http://bugs.winehq.org/show_bug.cgi?id=4901 > > Getting rid of aRts may cripple Wine on older systems, and it won't > solve the problem. We can't rely on all 3rd party sound libs to be > bug free, especially since there's a lot of dodgy homebrew systems out > there built by people who *think* they know what they're doing... > > Allowing users to use the Audio tab in WineCfg without forcing > possibly buggy libraries to load is a better option. > > Mike > Well, can we at least put in warnings when aRts support is enabled in winecfg (e.g. a popup that states that arts itself is buggy and it's use is not recomended?) Well, if we can't take support out, that there is a hell of a lot better than doing absoutly nothing. at least people get a warning when they do stupid stuff.

March 21, 2006

Re: Known issues area on main wiki page

by Jesse Allen

On 3/20/06, Mike McCormack <mike(a)codeweavers.com> wrote: > > Dimi Paun wrote: > > On Mon, 2006-03-20 at 22:28 -0600, Tom Spear (Dustin Booker, Dustin > > Navea) wrote: > > > >>clicking on the audio tab to check out bug 4051 first? Please! > > > > > > How about we fix the problem instead? :) > > The best way to fix it is probably to rearrange the code so that the > Audio tab shows, then there's a [Detect] button that the user can click > to run the autodetect code that might crash. At least then the user can > set their Wine Audio settings manually. > > Mike > > This is not enough, as when I click the audio tab, it will lock up in the kernel. I already identified where it happens and patch the kernel myself. I told the ALSA devs, but they haven't looked at why certain register usage causes a lockup. So it remains in the stable kernel who knows who else hits it. Jesse

March 21, 2006

Re: Known issues area on main wiki page

by Mike McCormack

Dimi Paun wrote: > On Tue, 2006-03-21 at 15:35 +0900, Mike McCormack wrote: > >>Allowing users to use the Audio tab in WineCfg without forcing >>possibly buggy libraries to load is a better option. > > Sure, but they are not mutually exclusive. If the current > patch also prevents the crash, they can go well hand in hand. Looks to me like the patch in bug #4051 only catches aRts exceptions. Bug 4901 looks like it's caused by libasound problems. Exception handlers can't catch system hangs, which I've seen when some audio drivers are loaded, they can't clean up properly after the buggy library, and the library might leave the stack or heap corrupted. Moving the autodetect feature to a button in the Audio tab seems like a simple design change that will solve the problem once and for all. It allows configuration to be done manually, even if buggy libraries are present, which the current implementation doesn't. Mike

March 21, 2006

Re: Known issues area on main wiki page

by Dimi Paun

On Tue, 2006-03-21 at 15:35 +0900, Mike McCormack wrote: > Allowing users to use the Audio tab in WineCfg without forcing > possibly buggy libraries to load is a better option. Sure, but they are not mutually exclusive. If the current patch also prevents the crash, they can go well hand in hand. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

March 21, 2006

Re: Known issues area on main wiki page

by Segin

Dimi Paun wrote: >On Tue, 2006-03-21 at 14:14 +0900, Mike McCormack wrote: > > >>The best way to fix it is probably to rearrange the code so that the >>Audio tab shows, then there's a [Detect] button that the user can >>click to run the autodetect code that might crash. At least then the >>user can set their Wine Audio settings manually. >> >> > >There is a patch in Bugzilla (posted Sun) that simply catches the >exception and avoids the crash that way. I think it's probably >good enough for the arts business, it's a dead-end anyway. > > > aRts in and of itself is a b/uggy ha/ck, KDE is droipping it in the 4.0 release, Skype crashes if you use artsdsp with it and play sound, arts is also known to just segfault for no reason whatsoever. Best suggestion is to drop support for aRts entirely, it won't be around much longer.

March 21, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime

by Stefan Dösinger

Am Montag, 20. März 2006 23:26 schrieb Lionel Ulmer: > Well, in OpenGL each thread can have its own context (and you can also bind > a context to only one thread which explains why multi-threaded D3D > applications are such a pain to support). So you can have multi-threaded GL > applications with each thread having its own GL context. What says that a gl context can be used by one thread only? In the glxDestroyContext man page it sounds like a context has a sort of reference count, and it can be used by multiple threads. A little bit OT, but related to multi-threaded opengl is a bug in the dri radeon driver(https://bugs.freedesktop.org/show_bug.cgi?id=6240). I've reported it to the dri devs but didn't get any response so far. Stefan

March 21, 2006

Re: Known issues area on main wiki page

by Mike McCormack

Segin wrote: > aRts in and of itself is a b/uggy ha/ck, KDE is droipping it in the 4.0 > release, Skype crashes if you use artsdsp with it and play sound, arts > is also known to just segfault for no reason whatsoever. Best suggestion > is to drop support for aRts entirely, it won't be around much longer. aRts is not the only library giving trouble here. Here's one caused by ALSA: http://bugs.winehq.org/show_bug.cgi?id=4901 Getting rid of aRts may cripple Wine on older systems, and it won't solve the problem. We can't rely on all 3rd party sound libs to be bug free, especially since there's a lot of dodgy homebrew systems out there built by people who *think* they know what they're doing... Allowing users to use the Audio tab in WineCfg without forcing possibly buggy libraries to load is a better option. Mike

March 21, 2006

Re: New Linux System calls (*at) in 2.6.16

by Marcus Meissner

On Tue, Mar 21, 2006 at 10:59:39AM +1100, Troy Rollo wrote: > Google for these combined with keywords related to Wine didn't show anything, > which surprised me since they seem ideal to solve a number of problems. A > bunch of new calls have been added to the Linux kernel 2.6.16 > <http://lwn.net/Articles/164887/> that are mirrors of the existing system > calls but take a file descriptor for a directory that becomes the base point > for relative paths. glibc support is needed too, and not a lot of people use glibc 2.4 yet. Oh, and: $ grep futimesat configure.ac libs/port/futimes.c configure.ac: futimesat \ libs/port/futimes.c: return futimesat( fd, NULL, tv ); $ Ciao, Marcus

March 21, 2006

Re: Known issues area on main wiki page

by Dimi Paun

On Tue, 2006-03-21 at 14:14 +0900, Mike McCormack wrote: > The best way to fix it is probably to rearrange the code so that the > Audio tab shows, then there's a [Detect] button that the user can > click to run the autodetect code that might crash. At least then the > user can set their Wine Audio settings manually. There is a patch in Bugzilla (posted Sun) that simply catches the exception and avoids the crash that way. I think it's probably good enough for the arts business, it's a dead-end anyway. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

March 21, 2006

Re: Known issues area on main wiki page

by Segin

March 21, 2006

Re: Easy applications to write automated tests for?

by Dan Kegel

On 3/19/06, Dan Kegel <dank(a)kegel.com> wrote: > > [Let's use Abiword as the app to test, as I proposed long ago:] But before we do that, let's have a good gui test for wine's own notepad and wordpad. First things first, eh? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 21, 2006

Re: Known issues area on main wiki page

by Mike McCormack

Dimi Paun wrote: > On Mon, 2006-03-20 at 22:28 -0600, Tom Spear (Dustin Booker, Dustin > Navea) wrote: > >>clicking on the audio tab to check out bug 4051 first? Please! > > > How about we fix the problem instead? :) The best way to fix it is probably to rearrange the code so that the Audio tab shows, then there's a [Detect] button that the user can click to run the autodetect code that might crash. At least then the user can set their Wine Audio settings manually. Mike

March 21, 2006

Re: Known issues area on main wiki page

by Dimi Paun

On Mon, 2006-03-20 at 22:28 -0600, Tom Spear (Dustin Booker, Dustin Navea) wrote: > clicking on the audio tab to check out bug 4051 first? Please! How about we fix the problem instead? :) -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

March 21, 2006

Known issues area on main wiki page

by Tom Spear (Dustin Booker, Dustin Navea)

I'm not trying to be a whiner here, but I think enough is enough when it comes to having to close bugs as a duplicate. There has to be some simple solution to cut down on the number of new bugs filed that report that winecfg crashes when clicking on the audio tab. I know that the subject above isn't it, but it is at least a start. I was about to create it myself, but my better judgement said I should ask here first. Can someone please(!) put something on some page that almost everyone sees saying that if you are having a problem with winecfg crashing when clicking on the audio tab to check out bug 4051 first? Please! Thanks Tom

March 21, 2006

Re: disallow networking flag

by Willie Sippel

Am Montag, 20. März 2006 12:55 schrieb n0dalus: > On 3/20/06, rauschenimweltnetz(a)web.de <rauschenimweltnetz(a)web.de> wrote: > > I think it would be very usefull to disallow an application started with > > wine to connect to the network/internet by an options flag. > > > > Unless somebody would help me to find out what I have to change... So I > > would try it by myself. But in consideration of the fact that I need this > > feature as soon as possible I would better like to just watch and > > learn... ;) > > I don't know how much of wine's source would need to be changed to > disallow all network commands, but I know that this kind of thing is > possible using iptables (particularly with the owner extension). > > If you create a new user id (which will be the one you use to start > the application, using su or sudo), something like 'nonet', then run > the following: > > iptables -I OUTPUT -m owner --uid-owner nonet -j REJECT --reject-with > imcp-net-unreachable > > or something like that (I haven't tested it), it will block the > 'nonet' user and any applications started as it from sending network > packets. > I think what Rauschi suggested was a per-application setting to disable network access. A checkbox in winecfg or something. I think iptables won't help there, but I think such a setting could be helpfull - preventing applications from calling home and such...? -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>

March 21, 2006

New Linux System calls (*at) in 2.6.16

by Troy Rollo

Google for these combined with keywords related to Wine didn't show anything, which surprised me since they seem ideal to solve a number of problems. A bunch of new calls have been added to the Linux kernel 2.6.16 <http://lwn.net/Articles/164887/> that are mirrors of the existing system calls but take a file descriptor for a directory that becomes the base point for relative paths. -- Troy Rollo - wine(a)troy.rollo.name

March 20, 2006

Re: function counting script, memcheck.sh

by Segin

attached. Joris Huizer wrote: > Segin wrote: > >> Attached is version 0.2 of this script, with a lot of additional >> functionality. You will need to be able to write to /tmp and make a >> file /tmp/grep to use the extended functionality (default >> functionality needs none of that, and is unmodified.) >> > > Your message does not have the script attached, could you resend > please :-) > > regards, > > Joris > > >

March 20, 2006

Re: function counting script, memcheck.sh

by Joris Huizer

Segin wrote: > Attached is version 0.2 of this script, with a lot of additional > functionality. You will need to be able to write to /tmp and make a file > /tmp/grep to use the extended functionality (default functionality needs > none of that, and is unmodified.) > Your message does not have the script attached, could you resend please :-) regards, Joris

March 20, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime

by Lionel Ulmer

On Mon, Mar 20, 2006 at 05:09:53PM +0100, Leon Freitag wrote: > I don't think it would be that hard to realize. Right now we have the > ENTER_GL() macro that gets called before each opengl call (see opengl_ext.c > and norm.c) where the check and sync occurs. One solution would be to make > two enter_gl functions -- one with the check and one without, and hardcode > some database with the function list in the script that generates the files. I agree, not hard at all to do, but the database needs to be maintained and it would mean that upgrading to new extensions would not be 'automatic' as it is now as one would need to review manually all new extensions to check the one that can modify / access the FB. Lionel -- Lionel Ulmer - http://www.bbrox.org/

March 20, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime

by Lionel Ulmer

On Mon, Mar 20, 2006 at 05:37:50PM +0100, Leon Freitag wrote: > Why thread-local variables? AFAIK OpenGL is single-threaded in its nature. I > don't know if there are applications that draw opengl in multiple threads in > different contents, and if current code would make any problems with these. Well, in OpenGL each thread can have its own context (and you can also bind a context to only one thread which explains why multi-threaded D3D applications are such a pain to support). So you can have multi-threaded GL applications with each thread having its own GL context. So instead of retrieving the context on each ENTER_GL / LEAVE_GL macro using the GLX call, one can simply store the currently bound context for the current thread in a thread-local variable. This is what Mike's patch does. Lionel -- Lionel Ulmer - http://www.bbrox.org/

March 20, 2006

Re: winedbg: resend - add display for floating point status

by Eric Pouech

I'm getting picky, but there are a couple of things you still need to work on: - first, I don't think it's worthwhile to add another method to the CPU backend. Adding a boolean (as parameter) to print_context should do. - you also need to fix all the be_*.c files (for amd, ppc...) as well. Otherwise, they won't compile. The rule of thumb is never commit a patch that breaks compilation on some platforms. - one of the test looks suspicious (shouldn't it be if (!(ctx->loatSave.StatusWord & 0x00000001)) instead ?) > + if (!ctx->FloatSave.StatusWord & 0x00000001) A+ -- Eric Pouech

March 20, 2006

Re: Easy applications to write automated tests for?

by Dan Kegel

On 3/20/06, Molle Bestefich <molle.bestefich(a)gmail.com> wrote: > Dimi Paun wrote: > > Being able to run an emulation layer like msys/cygwin > > In my experience (couple of years worth of different Cygwin versions, > all relatively new stuff), the Cygwin kernel emulation stuff is > extremely unstable itself. unstable in the sense that it changes all the time, yes. msys, on the other hand, is working off a frozen snapshot of cygwin from long ago, and never changes. So it's stable in at least that sense. I have no idea how buggy it is. It works well enough to run configure scripts on real windows, though. > There are a couple of other Windows-->Unix emulation kits readily > available, so shouldn't be hard to find something that both runs > reliably and can make ./configure scripts work... Oh, really? Got URLs? Have you tried any of them on wine? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 20, 2006

Re: Easy applications to write automated tests for?

by Molle Bestefich

Dimi Paun wrote: > Being able to run an emulation layer like msys/cygwin In my experience (couple of years worth of different Cygwin versions, all relatively new stuff), the Cygwin kernel emulation stuff is extremely unstable itself. So that would probably get you a heck of a lot of false positives in terms of faults occurring. There are a couple of other Windows-->Unix emulation kits readily available, so shouldn't be hard to find something that both runs reliably and can make ./configure scripts work...

March 20, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime

by Leon Freitag

P.S. Why thread-local variables? AFAIK OpenGL is single-threaded in its nature. I don't know if there are applications that draw opengl in multiple threads in different contents, and if current code would make any problems with these. Leon

March 20, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime

by Leon Freitag

> Does that work any better? The patch works wonderfully! Thank you very much! The only thing is that you have to modify the Makefile.in in the opengl32 directory and add "ntdll" to the libs list. > Well, to make this work better, one would need a two-tiered approach: > = use thread-local variables to check if it's a 'special' buffer or not > (like this patch does) > = only do this check on GL APIs that actually modify or read from the frame > buffer (basically stuff like glClear, glEnd, gl(Read|Write)Buffer, ...). > The last is easy to do for 'core' stuff, a bit harder for extensions though. > But anyway, this is mandatory if one day we want to fix the 'windowed' > OpenGL code properly (whatever the method we choose as long as we do not > have the GLX extension exporting the clip list feature to the application). I don't think it would be that hard to realize. Right now we have the ENTER_GL() macro that gets called before each opengl call (see opengl_ext.c and norm.c) where the check and sync occurs. One solution would be to make two enter_gl functions -- one with the check and one without, and hardcode some database with the function list in the script that generates the files. This patch does already a great job for fixing Huw's regressions, and me and many Wine users would greatly appreciate its merge into Wine tree. Leon

March 20, 2006