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

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