December 2007 - Wine-Devel - list.winehq.org

Re: [patch 1/2, try 2] wined3d: rewrite IWineD3DSurfaceImpl_BltOverride colorfill codepath
by Stefan Dösinger Dec. 20, 2007

Dec. 20, 2007

Hi Alexander, I had a look at your patches again, and another issue came to my mind: I am not sure how the scissor rectangle and viewport affects ColorFill blits. IDirect3DDevice::Clear is limited by the viewport, the scissor test and the rectangles passed in, but I think that this doesn't apply to ColorFills. If that is true, I think there isn't much point in having a common codepath, and we should just put the glClear() call into COLORFILL itself - Dealing with the differences of those two calls will be more effort than the code shared. But I think we need a test for this. There is a clear() test in dlls/ddraw/tests/visual.c, but the d3d9 test tests a few more things. It should be possible to add a COLORFILL test to the visual.c clear test in ddraw as well, this will show if Windows honors the scissor and viewport in COLORFILL or not. Yes, I know... Start fixing one bug, and you'll run into a lot more. Happens to me all the time as well :-) Stefan

2 1

Re: [5/6] WineD3D: Move the GL info structure into the adapter
by H. Verbeet Dec. 20, 2007

Dec. 20, 2007

On 20/12/2007, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +#define WINED3D_ATR_TYPE(type) GLINFO_LOCATION.glTypeLookup[type].d3dType > +#define WINED3D_ATR_SIZE(type) GLINFO_LOCATION.glTypeLookup[type].size > +#define WINED3D_ATR_GLTYPE(type) GLINFO_LOCATION.glTypeLookup[type].glType > +#define WINED3D_ATR_NORMALIZED(type) GLINFO_LOCATION.glTypeLookup[type].normalized > +#define WINED3D_ATR_TYPESIZE(type) GLINFO_LOCATION.glTypeLookup[type].typesize Unrelated to the actual patch, but I think it wouldn't hurt to get rid of these macros. They're pretty much unnecessary.

1 0

Re: The BS_GROUPBOX style should only be used if the HasBorderattribute is set
by Dmitry Timoshkov Dec. 20, 2007

Dec. 20, 2007

"James Hawkins" <truiken(a)gmail.com> wrote: > Changelog: > * The BS_GROUPBOX style should only be used if the HasBorder attribute is set. Alexandre, please don't apply this patch. I sent another patch that reverts commit 96e4320feb22b3a2c9564de100c09990622edb59 which is the real source of the problem. Perhaps James' patch is going in the right direction when a group box should really be displayed by a WM_DRAWITEM handler, or BS_GROUPBOX should be used instead in that case. But that needs a test case. -- Dmitry.

1 0

Today's git won't hunt. Server crash, lots of other problems?
by Dan Kegel Dec. 20, 2007

Dec. 20, 2007

On Dec 18, 2007 10:29 AM, Susan Cragin <susancragin(a)earthlink.net> wrote: > My git won't install DNS9P any more, as of today's git. > Any suggestions? > > susan(a)ubuntu:~/DNS9$ wine setup > fixme:advapi:LookupAccountNameW (null) L"susan" (nil) 0x34b944 (nil) 0x34b948 0x34b93c - stub > fixme:advapi:LookupAccountNameW (null) L"susan" 0x1463f0 0x34b944 0x146998 0x34b948 0x34b93c - stub > fixme:msi:ITERATE_DuplicateFiles We should track these duplicate files as well > fixme:msi:msi_unimplemented_action_stub RemoveFolders -> 2 ignored L"CreateFolder" table values > fixme:advapi:LookupAccountNameW (null) L"susan" (nil) 0x34f7fc (nil) 0x34f800 0x34f7f4 - stub > fixme:advapi:LookupAccountNameW (null) L"susan" 0x1423a0 0x34f7fc 0x13ce80 0x34f800 0x34f7f4 - stub > fixme:atl:AtlModuleInit SEMI-STUB (0x40eb40 0x40c040 0x400000) > wineserver crashed, please enable coredumps (ulimit -c unlimited) and restart. I just ran into that myself. ALVIN!!!!!!!!! But it doesn't seem easy to repeat; I keep getting other errors now. Roy next to me says he ran into another regression, he's doing a bisect, maybe it's the same thing. He should be done shortly. - Dan

3 3

Early wine history
by Dan Kegel Dec. 19, 2007

Dec. 19, 2007

winehq.org doesn't seem to have a link to the message that launched the wine project, so I went looking. The first message I found contemplating it was dated 1 Jun 1993, http://groups.google.com/group/comp.os.linux/msg/0a7c3867abdb4a76 Is that about the right estimate for Wine's birthday? A roughly 1995 writeup about Wine is at http://www.softlookup.com/tutorial/redhat/rhl58.asp It has a screen shot of a game Pipe Dream running under Wine. I just checked; the game is still online at http://members.chello.at/theodor.lauppert/games/pipe1.htm and runs well on today's wine :-)

4 3

Re: [msiexec] A nicer icon
by Alexandre Julliard Dec. 19, 2007

Dec. 19, 2007

Hervÿffffe9 Chanal <chanal_herve(a)yahoo.fr> writes: > Hello, > > It's a larger nicer icon for msiexec with the svg source. Having icons in .svg format is a nice improvement, but we'll need a tool to build the .ico from the .svg. We also need to include multiple sizes in the .ico, most places want a 32x32 icon, and scaling down the 48x48 looks bad. Of course we should also look into taking advantage of the larger size where that's possible without breaking compatibility. -- Alexandre Julliard julliard(a)winehq.org

2 1

Piddly little erratic valgrind warning in ole32_moniker
by Dan Kegel Dec. 19, 2007

Dec. 19, 2007

Nothing really new yesterday or today. This one's annoying: http://kegel.com/wine/valgrind/logs-2007-12-19/vg-ole32_moniker-diff.txt + Syscall param write(buf) points to uninitialised byte(s) + at (within /lib/ld-2.5.so) + by WriteFile (file.c:512) + by RPCSS_BecomePipeServer (np_server.c:379) + by main (rpcss_main.c:101) because it keeps looking like it's new every other day $ grep RPCSS_BecomePipeServer logs-*/vg-ole32_mon*diff.txt logs-2007-12-06/vg-ole32_moniker-diff.txt:+ by RPCSS_BecomePipeServer (np_server.c:379) logs-2007-12-06/vg-ole32_moniker-diff.txt:+ fun:RPCSS_BecomePipeServer logs-2007-12-06/vg-ole32_moniker-diff.txt:- by RPCSS_BecomePipeServer (np_server.c:379) logs-2007-12-06/vg-ole32_moniker-diff.txt:- fun:RPCSS_BecomePipeServer logs-2007-12-07/vg-ole32_moniker-diff.txt: fun:RPCSS_BecomePipeServer logs-2007-12-08/vg-ole32_moniker-diff.txt:+ by RPCSS_BecomePipeServer (np_server.c:379) logs-2007-12-08/vg-ole32_moniker-diff.txt:+ fun:RPCSS_BecomePipeServer logs-2007-12-08/vg-ole32_moniker-diff.txt:- by RPCSS_BecomePipeServer (np_server.c:379) logs-2007-12-08/vg-ole32_moniker-diff.txt:- fun:RPCSS_BecomePipeServer logs-2007-12-10/vg-ole32_moniker-diff.txt:- by RPCSS_BecomePipeServer (np_server.c:379) logs-2007-12-10/vg-ole32_moniker-diff.txt:- fun:RPCSS_BecomePipeServer logs-2007-12-10/vg-ole32_moniker-diff.txt:+ by RPCSS_BecomePipeServer (np_server.c:379) logs-2007-12-10/vg-ole32_moniker-diff.txt:+ fun:RPCSS_BecomePipeServer logs-2007-12-12/vg-ole32_moniker-diff.txt:+ by RPCSS_BecomePipeServer (np_server.c:379) logs-2007-12-12/vg-ole32_moniker-diff.txt:+ fun:RPCSS_BecomePipeServer logs-2007-12-12/vg-ole32_moniker-diff.txt:- by RPCSS_BecomePipeServer (np_server.c:379) logs-2007-12-12/vg-ole32_moniker-diff.txt:- fun:RPCSS_BecomePipeServer logs-2007-12-13/vg-ole32_moniker-diff.txt:- by RPCSS_BecomePipeServer (np_server.c:379) logs-2007-12-13/vg-ole32_moniker-diff.txt:- fun:RPCSS_BecomePipeServer logs-2007-12-14/vg-ole32_moniker-diff.txt:+ by RPCSS_BecomePipeServer (np_server.c:379) logs-2007-12-14/vg-ole32_moniker-diff.txt:+ fun:RPCSS_BecomePipeServer logs-2007-12-17/vg-ole32_moniker-diff.txt:- by RPCSS_BecomePipeServer (np_server.c:379) logs-2007-12-17/vg-ole32_moniker-diff.txt:- fun:RPCSS_BecomePipeServer logs-2007-12-17/vg-ole32_moniker-diff.txt:+ by RPCSS_BecomePipeServer (np_server.c:379) logs-2007-12-17/vg-ole32_moniker-diff.txt:+ fun:RPCSS_BecomePipeServer logs-2007-12-18/vg-ole32_moniker-diff.txt:- by RPCSS_BecomePipeServer (np_server.c:379) logs-2007-12-18/vg-ole32_moniker-diff.txt:- fun:RPCSS_BecomePipeServer logs-2007-12-19/vg-ole32_moniker-diff.txt:+ by RPCSS_BecomePipeServer (np_server.c:379) logs-2007-12-19/vg-ole32_moniker-diff.txt:+ fun:RPCSS_BecomePipeServer

1 0

Re: Patch for process title on FreeBSD
by Alexandre Julliard Dec. 19, 2007

Dec. 19, 2007

Kris Moore <kris(a)pcbsd.com> writes: > --- dlls/kernel32/process.c.orig 2007-12-12 12:34:45.000000000 -0500 > +++ dlls/kernel32/process.c 2007-12-12 12:35:17.000000000 -0500 > @@ -853,6 +853,11 @@ > */ > static void set_process_name( int argc, char *argv[] ) > { > + > +#if defined(__FreeBSD__) > + setproctitle("-%s", argv[1]); > +#endif You should add a configure check for this function, instead of checking for __FreeBSD__. -- Alexandre Julliard julliard(a)winehq.org

3 2

Re: [PATCH 2/3] qmgr: AddRef, QueryInterface, and stub functions for queue manager interface.
by Alexandre Julliard Dec. 19, 2007

Dec. 19, 2007

Roy Shea <roy(a)cs.hmc.edu> writes: > +static ULONG WINAPI BITS_IBackgroundCopyManager_AddRef( > + IBackgroundCopyManager* iface) > +{ > + ICOM_THIS_MULTI(BackgroundCopyManagerImpl, lpVtbl, iface); There's no reason to use ICOM_THIS_MULTI with a single vtbl. > + if (This == NULL) > + { > + return E_POINTER; > + } Checking This for NULL is a waste of time. -- Alexandre Julliard julliard(a)winehq.org

1 0

RE: [PATCH] Implement BindIoCompletionCallback
by Rolf Kalbermatter Dec. 19, 2007

Dec. 19, 2007

Andrey Turkin wrote: >diff --git a/dlls/kernel32/tests/sync.c b/dlls/kernel32/tests/sync.c >index e402fed..7bbb3e2 100644 >--- a/dlls/kernel32/tests/sync.c >+++ b/dlls/kernel32/tests/sync.c >@@ -327,7 +327,7 @@ static void test_iocp_callback(void) > retb = p_BindIoCompletionCallback(hFile, iocp_callback, 0); > ok(retb == FALSE, "BindIoCompletionCallback succeeded on a file that wasn't created with FILE_FLAG_OVERLAPPED\n"); > if(retb == FALSE && GetLastError() == ERROR_CALL_NOT_IMPLEMENTED) { >- todo_wine ok (0, "BindIoCompletionCallback returned ERROR_CALL_NOT_IMPLEMENTED\n"); >+ ok (0, "BindIoCompletionCallback returned ERROR_CALL_NOT_IMPLEMENTED\n"); > return; > } I don't think this check makes much sense after the change anymore. It's at best a skip() for older Windows versions. Rolf Kalbermatter

1 0

[Fwd: Re: About the WWN]
by kubrick＠fgv6.net Dec. 19, 2007

Dec. 19, 2007

Hello. As indicated by Zachary, I post the suggestion I made him on the wine-devel list. The suggestion was : "what do you think about writing in the WWN an article about what did the last changes of the last release brought? I mean, knowing that there is "a ton of rpcrt4 fixes" or "New Bidi text implementation that doesn't depend on libicu" is really great, but from a user point of view it doesn't mean anything. It would be great if you'd explain us the problems it solves and which opportunities it gives." What he replies is that he need your help ! Thanks. François. ------------------------------------------------------- Original Message ------------------------------------------------------- Subject: Re: About the WWN From: "Zachary Goldberg" <zgold(a)bluesata.com> Date: Tue, December 18, 2007 19:50 To: François Guerraz <kubrick(a)fgv6.net> -------------------------------------------------------------------------------------------------------------------------------- Francois, If you could do me a favor of suggesting your second point on the wine-devel mailing list then we could start a discussion for it. I think it would be a good idea; however It would require perhaps a bit more detail being made in the commit comments to WINE so that I can go through them and put together the real changes. --Zach On Dec 18, 2007 1:47 PM, François Guerraz <kubrick(a)fgv6.net> wrote: > Hello. > > First of all : thank you so much for being the new author of the WWN. I am a > fervent reader and I was really upset that it was almost never written. I > hope you'll find this task interesting and that you won't be fed up with it > too quick :) > Second I have a suggestion to make : what do you think about writing in the > WWN an article about what did the last changes of the last release brought? > I mean, knowing that there is "a ton of rpcrt4 fixes" or "New Bidi text > implementation that doesn't depend on libicu" is really great, but from a > user point of view it doesn't mean anything. It would be great if you'd > explain us the problems it solves and which opportunities it gives. > > Thank you for your time and implication. > > Regards, > > > François Guerraz > kubrick(a)fgv6.net > > > > -- Zachary Goldberg Computer Science & Engineering Electrical Captain of Penn Electric Race Team School of Engineering at the University of Pennsylvania

1 0

Interview with Alexandre on Lug Radio
by Dan Kegel Dec. 19, 2007

Dec. 19, 2007

http://www.lugradio.org/episodes/90 "Alexandre Juillard from the Wine Project talks about where Wine is, why it isn't finished, and what's coming next (2.02)" In which we learn that Wine now has a release manager, and that the plan is to release 1.0 for the 15th anniversary of the project. - Dan

1 0

Re: ntoskrnl: Implement or add stubs for several functions.
by Dmitry Timoshkov Dec. 19, 2007

Dec. 19, 2007

"Chris Wulff" <crwulff(a)rochester.rr.com> wrote: > NOTE: This is required for the "hal: Stubs for ExAcquireFastMutex and > ExReleaseFastMutex" patch to build. (it contains the fast mutex > typedefs.) I apologize for submitting them out of order. You need to send every API implementation as a separate self contained patch, and avoid not necessary white space changes. -- Dmitry.

1 0

Re: WineX11.drv: Add an X11 window for the client area [attempt2]
by Chris Robinson Dec. 18, 2007

Dec. 18, 2007

On Tuesday 18 December 2007 01:52:11 am Roderick Colenbrander wrote: > > This is an updated version of the previous patch. It contains the > > following changes: > > - the client window is set to the whole window in case of the desktop I think you also need to set the desktop hwnd's client_window_prop too, so GetDC and friends will get the right window when not using the DCX_WINDOW flag. > > - the client window is destroyed in SetParent together with the other X11 > > windows In the case of data->whole_window == data->client_window, you should probably make sure the client_window (and it's prop) are both set back to 0, too.

1 0

DTrace instrumentation
by Damian Wojsław Dec. 18, 2007

Dec. 18, 2007

Hi I have an idea that I can put some time into. Since Leopard, FreeBSD and, of course, Solaris, now all have DTrace, I thought of implementing some simple probes. Function entry/return for starters. However, I'd firstly need to know two things: - would anyone be interested in it? - would it be legal (it wold link with dtrace library, which on Solaris is CDDL). Regards -- Damian Wojsław OpenSolaris Core Contributor SCA No. OS00073

2 1

Re: gdi32: Add a GdiConvertToDevmodeW test, make it pass under Wine
by Robert Shearman Dec. 18, 2007

Dec. 18, 2007

Dmitry Timoshkov wrote: > DEVMODEW *dmW; > WORD dmW_size; > > - dmW_size = dmA->dmSize + CCHDEVICENAME; > - if (dmA->dmSize >= (const char *)dmA->dmFormName - (const char *)dmA + CCHFORMNAME) > + dmW_size = dmA->dmSize; > + if (dmW_size > sizeof(DEVMODEA)) > + dmW_size = sizeof(DEVMODEA); > Shouldn't this be sizeof(DEVMODEW)? > + > + dmW_size += CCHDEVICENAME; > Shouldn't this be CCDEVICENAME * sizeof(WCHAR)? > + if (dmA->dmSize >= FIELD_OFFSET(DEVMODEA, dmFormName) + CCHFORMNAME) > dmW_size += CCHFORMNAME; > Shouldn't this be CCHFORMNAME * sizeof(WCHAR)? -- Rob Shearman

2 1

Re: [10/10] WineD3D: Implement blits from the active render target to swapchains
by Stefan Dösinger Dec. 18, 2007

Dec. 18, 2007

Am Montag, 17. Dezember 2007 21:04:46 schrieb Stefan Dösinger: Do not apply this patch yet, it has some problems

2 1

Re: WineX11.drv: Add an X11 window for the client area [attempt2]
by Roderick Colenbrander Dec. 18, 2007

Dec. 18, 2007

By accident I discovered that with this patch the wine desktop window doesn't work properly if there are multiple windows around (you notice redrawing issues). I haven't seen those before, so there is something wrong in this patch but I don't know where to look (I guess it is the client_window = whole_window code). Roderick > The previous patch accidently undid one of Stefan's changes and prevented > it from compiling. This patch should be fine. > > Roderick > > > > Hi, > > > > This is an updated version of the previous patch. It contains the > > following changes: > > - the client window is set to the whole window in case of the desktop > > - NortWestGravity is used when creating the client window > > - the client window is destroyed in SetParent together with the other > X11 > > windows > > > > The patch was tested using the user32 tests and various opengl / d3d > test > > apps. All worked correctly. > > > > Regards, > > Roderick Colenbrander > > > > -- > > GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. > > Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail > > -- > GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. > Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

1 0

Re: wined3d: Bind device framebuffer in ActivateContext
by Stefan Dösinger Dec. 18, 2007

Dec. 18, 2007

Am Sonntag, 25. November 2007 00:07:15 schrieb Allan Tong: > Fixes failures in visual tests for ddraw and d3d8 when using FBO > offscreen rendering mode. > > - Allan This doesn't look right to me. It will most likely break overall FBO support. There is indeed a problem with the fbo and ActivateContext integration, but fixing this is more involved than just setting the framebuffer to 0.

4 9

Vector NTI on Mac, WinHelp improvements
by Misha Koshelev Dec. 18, 2007

Dec. 18, 2007

Hi guys, It's been a bit since I wrote to the list (or contributed anything... been somewhat busy I guess with lab/school/life). Anyhow I just wanted to acknowledge the new WinHelp fixes (Kirill thanks in particular). Although there is still no Contents or Search, which would make the Vector NTI help more usable, the bug where it would complain about not being able to open help when it was requested even though help would open just fine has now been fixed. Thanks! Also, I've been starting to play some with Wine on Mac and may in time end up contributing some patches for this goal, provided I will have to acquaint myself with some more Mac specific coding ideas first. Specifically though, I'd like to point out that I think the Mac is a hugely important platform for Wine I believe in terms of end-user adoption, and although I understand the rationale for not having binary packages available because Apple's X11 is buggy (which it clearly is), I think it would still be nice to have the Mac at least be an important focus. And yes my thought initially was "well there's usually a Mac version of the Windows program." But alas unfortunately this seems to not quite be the case a lot of times. For example, even Vector NTI, which has both "mac and windows" versions, actually has a Mac version that does not work on MacOS 10.4 and higher (the company reports they are working on a code rewrite for Mac versions, but meanwhile there are tons of people out there on Google looking for ways around this/alternatives as Vector NTI is very common in molecular biology and Macs are traditionally the platform of choice in the field)... Wine would find a very nice niche here with a bunch of people that otherwise prob would not end up using it. Another program we use a lot, Kodak Molecular Imaging, also actually has problems with MacOS 10.4+ on Intel (not PowerPC) Macs, although this has to do with the dongle drivers (USB dongle = Sentinel SuperPro), so likely Wine would need a little more improvement to be of use here. Anyway, just wanted to point out my observations about the Mac and that although others might be thinking along the same lines I was... "well most programs available for Windows are available for Mac", in two examples I've discovered that upon careful examination this actually turns out to be quite opposite of the actual case. Thanks for you time Misha

1 0

Re: msi [2/2]: Sort each table of the join separately
by James Hawkins Dec. 18, 2007

Dec. 18, 2007

On Dec 17, 2007 7:35 PM, James Hawkins <truiken(a)gmail.com> wrote: > Hi, > > This is another fix for the National Instruments LabView mega-installer. > > Changelog: > * Sort each table of the join separately. > Oops, ignore this patch (first one can go in). I forgot to add the freeing code for the order. I'll have to resend it tomorrow. -- James Hawkins

1 0

New valgrind regressions in riched20, rpcrt4
by Dan Kegel Dec. 17, 2007

Dec. 17, 2007

http://kegel.com/wine/valgrind/logs-2007-12-17-summary.txt shows interesting things happened since Friday in riched20. See http://kegel.com/wine/valgrind/logs-2007-12-17/vg-riched20_editor-diff.txt for a whole heap of new errors. The only change since Friday was Maarten's, http://www.winehq.org/pipermail/wine-cvs/2007-December/038829.html, which seems somewhat unrelated, maybe he's getting slagged unfairly here. (But it would still be nice if he could have a look.) There's also the somewhat questionable new warning + Source and destination overlap in memcpy(0x7F00F844, 0x7F00F844, 22) in http://kegel.com/wine/valgrind/logs-2007-12-17/vg-rpcrt4_ndr_marshall-diff.… which would be Rob's if it turns out to be a real problem. - Dan

2 1

[Fwd: Re: New bugzilla components.]
by James McKenzie Dec. 17, 2007

Dec. 17, 2007

-------- Original Message -------- Subject: Re: New bugzilla components. Date: Sun, 16 Dec 2007 18:52:40 -0700 From: James McKenzie <jjmckenzie51(a)sprintpcs.com> To: Dmitry Timoshkov <dmitry(a)codeweavers.com> References: <47640A28.7080701(a)kievinfo.com> <004f01c83f9a$cae2e500$a600fea9(a)DMITRY> <22821af30712152034t1ee5318ai38eba71df919d38f(a)mail.gmail.com> <200712160933.09187.kai.blin(a)gmail.com> <001101c83fcc$2b6cd490$a600fea9(a)DMITRY> Dmitry Timoshkov wrote: > > Users are not supposed to set a category the bug belongs to, this requires > an investigation and knowledge of a developer. Personally I'd prefer to have > "default" in the list instead of "wine-misc". > > Better choice: Unknown or intial report. This will allow a user to file a bug without having to get technical. This also allows bug triage and for the appropriate developer or development team to be notified of a new bug. As to listing each and every dll, that would be a mess. Keep it to components and parts and use keywords if necessary to identify offending dlls. James McKenzie

3 3

Re: Unimplemented function KERNEL32.dll.FindFirstVolumeW
by devzero＠web.de Dec. 17, 2007

Dec. 17, 2007

mhhh - since it cost me more then one hour to find out why my machine reboots and triggering a reboot by just _reading_ a file on my system, device node or not is at least very weird behaviour from a user`s perspective. >waiting for an user-space daemon to start handling of /dev/watchdog file (opening it and manipulating it from time to time to show that it's still alive. >When you cat the file, kernel recognizes it as that such an app is taking over control of the watchdog and starts it. it`s looks a little bit too simple for me. triggering a reboot just by some simple open() and read() and close() ? let`s wait what the maintainer has to tell. regards roland > Hi! > I think it's not a bug, it's a normal behaviour. > The kernel watchdog is normally not active when the machine is booted, > waiting for an user-space daemon to start handling of /dev/watchdog file > (opening it and manipulating it from time to time to show that it's still > alive). When you cat the file, kernel recognizes it as that such an app > is taking over control of the watchdog and starts it. However, because > cat closes the file immediately, it is not handled anymore and kernel > recognizes it as a userspace problem, thus rebooting the machine after > the timeout expires. > With regards, Pavel Troller > > -----Ursprüngliche Nachricht----- > Von: Pavel Troller <patrol(a)sinus.cz> > Gesendet: 20.11.07 08:49:53 > An: devzero(a)web.de > CC: Hans Leidekker <hans(a)it.vu.nl>, wine-devel(a)winehq.org > Betreff: Re: Unimplemented function KERNEL32.dll.FindFirstVolumeW > > > i`ve tracked this down to a watchdog issue. > > > > whenever i do "cat /dev/watchdog" - my system reboots after ~1 minute. > > > > i`ve contacted the maintainer of the watchdog subsystem. > > > > looks like a bug to me. > > > > thanks > > roland > > > Hi! > I think it's not a bug, it's a normal behaviour. > The kernel watchdog is normally not active when the machine is booted, > waiting for an user-space daemon to start handling of /dev/watchdog file > (opening it and manipulating it from time to time to show that it's still > alive). When you cat the file, kernel recognizes it as that such an app > is taking over control of the watchdog and starts it. However, because > cat closes the file immediately, it is not handled anymore and kernel > recognizes it as a userspace problem, thus rebooting the machine after > the timeout expires. > With regards, Pavel Troller > ______________________________________________________________________________ Jetzt neu! Im riesigen WEB.DE Club SmartDrive Dateien freigeben und mit Freunden teilen! http://www.freemail.web.de/club/smartdrive_ttc.htm/?mc=021134

3 2

Re: Unimplemented function KERNEL32.dll.FindFirstVolumeW
by devzero＠web.de Dec. 17, 2007

Dec. 17, 2007

> Yes, Wine shouldn't be able to do that. You're not running Wine > as root are you? whoops - i did. shame on me :) i retried with ordinary account and the crash didn`t happen there. anyway - should i expect such problems with root ? >Does your system log reveal anything about the crash? no, unfortunately not regards roland > -----Ursprüngliche Nachricht----- > Von: "Hans Leidekker" <hans(a)it.vu.nl> > Gesendet: 19.11.07 21:22:20 > An: "http://freemail.web.de/" <devzero(a)web.de> > Betreff: Re: Unimplemented function KERNEL32.dll.FindFirstVolumeW > > On Monday 19 November 2007 20:59:46 devzero(a)web.de wrote: > > > when scannnig trough drive z:\ , my notebook reboots ! > > wasn`t wine a userspace application with no kernel related stuff ? > > so it`s weird, that windirstat is crashing my notebook, isn`t it ? > > Yes, Wine shouldn't be able to do that. You're not running Wine > as root are you? Does your system log reveal anything about the crash? > > -Hans > ______________________________________________________________________ XXL-Speicher, PC-Virenschutz, Spartarife & mehr: Nur im WEB.DE Club! Jetzt testen! http://produkte.web.de/club/?mc=021130

3 2