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

Re: Windows version autodetection

by Reece Dunn

2008/12/21 Damjan Jovanovic <damjan.jov(a)gmail.com>: > On Sun, Dec 21, 2008 at 11:49 AM, Reece Dunn <msclrhd(a)googlemail.com> wrote: >> 2008/12/21 Damjan Jovanovic <damjan.jov(a)gmail.com>: >> You can change the version of Windows reported for different >> applications, and the default version using winecfg -> Applications. > > I know, but bugs coming up from the wrong default version aren't > always obvious (in my case they were registry keys that don't get > created during installation). This is where having people contributing to AppDB would be useful. They would know what version of Windows being reported by Wine would work best - even when that changes in the future. This will take some experimentation, but after some investigation it can be figured out. >> I'm not sure that adding heuristics would be the correct approach, as >> those can lead to incorrect results. The winecfg option supports the >> user being able to change the version of Windows reported for the >> specified application. The workflow could be better, though (e.g. >> supporting an option on an exe's right-click menu). > > Heuristics aren't necessarily wrong: > > File Header > Machine: 014C (i386) > Number of Sections: 6 > TimeDateStamp: 31104C75 (Thu Feb 1 07:15:33 1996) offset 136 > > Feb 1 1996 can't be later than Windows 95. Sure. But what if an application was shipped after Vista or Windows Server 2008, but only worked on XP and earlier. Your detection would not work here. Also, what if an application supported XP, but crashed on Wine as it was using some unimplemented call in GDI+. Setting it to Windows 2000, the application works fine. These two cases are where your simple heuristic will break (TimeDateStamp ==> Windows version). >> What would be better is to have AppDB keep track of what version of >> Windows works best with a particular application. This could then be >> queried on install of the application, or downloaded in bulk. It would >> be easy to take the data and create a registry file like what winecfg >> will be saving to. That way, AppDB becomes the place where this is >> maintained (so it is up to the individual maintainers to set the >> Windows version if it doesn't work with the default version) and there >> are no ugly heuristics involved. > > The bulk download would only work if you install applications to their > default location, but it seems like a good idea. IIUC, Wine goes by the executable name (e.g. notepad.exe) and not where the application is installed to. The only problems I can see with this is in different versions of applications requiring different reported versions of Windows and any name clashes (if any). - Reece

Dec. 21, 2008

Re: Windows version autodetection

by Damjan Jovanovic

On Sun, Dec 21, 2008 at 11:49 AM, Reece Dunn <msclrhd(a)googlemail.com> wrote: > 2008/12/21 Damjan Jovanovic <damjan.jov(a)gmail.com>: >> There are some older applications out there, which don't install or >> run correctly unless Wine is emulating the correct Windows version >> (eg. Windows 9x). >> >> At least Windows XP has the ability to use certain heuristics to make >> an educated guess as to which version of Windows the application >> expects, and then lie in GetVersion() and behave like that version in >> relevant APIs. >> >> Should we do something like that for Wine? It would allow many >> applications to work out of the box. > > You can change the version of Windows reported for different > applications, and the default version using winecfg -> Applications. I know, but bugs coming up from the wrong default version aren't always obvious (in my case they were registry keys that don't get created during installation). > I'm not sure that adding heuristics would be the correct approach, as > those can lead to incorrect results. The winecfg option supports the > user being able to change the version of Windows reported for the > specified application. The workflow could be better, though (e.g. > supporting an option on an exe's right-click menu). Heuristics aren't necessarily wrong: File Header Machine: 014C (i386) Number of Sections: 6 TimeDateStamp: 31104C75 (Thu Feb 1 07:15:33 1996) offset 136 Feb 1 1996 can't be later than Windows 95. > What would be better is to have AppDB keep track of what version of > Windows works best with a particular application. This could then be > queried on install of the application, or downloaded in bulk. It would > be easy to take the data and create a registry file like what winecfg > will be saving to. That way, AppDB becomes the place where this is > maintained (so it is up to the individual maintainers to set the > Windows version if it doesn't work with the default version) and there > are no ugly heuristics involved. The bulk download would only work if you install applications to their default location, but it seems like a good idea. > - Reece > Damjan

Dec. 21, 2008

Re: Windows version autodetection

by Marcus Meissner

On Sun, Dec 21, 2008 at 11:19:35AM +0200, Damjan Jovanovic wrote: > Hi > > There are some older applications out there, which don't install or > run correctly unless Wine is emulating the correct Windows version > (eg. Windows 9x). > > At least Windows XP has the ability to use certain heuristics to make > an educated guess as to which version of Windows the application > expects, and then lie in GetVersion() and behave like that version in > relevant APIs. > > Should we do something like that for Wine? It would allow many > applications to work out of the box. We had this ;) It was removed for being mostly unnecessary and that one Wine session should report one Windows version (even when different Windows programs run). Ciao, Marcus

Dec. 21, 2008

Re: Windows version autodetection

by Reece Dunn

2008/12/21 Damjan Jovanovic <damjan.jov(a)gmail.com>: > There are some older applications out there, which don't install or > run correctly unless Wine is emulating the correct Windows version > (eg. Windows 9x). > > At least Windows XP has the ability to use certain heuristics to make > an educated guess as to which version of Windows the application > expects, and then lie in GetVersion() and behave like that version in > relevant APIs. > > Should we do something like that for Wine? It would allow many > applications to work out of the box. You can change the version of Windows reported for different applications, and the default version using winecfg -> Applications. I'm not sure that adding heuristics would be the correct approach, as those can lead to incorrect results. The winecfg option supports the user being able to change the version of Windows reported for the specified application. The workflow could be better, though (e.g. supporting an option on an exe's right-click menu). What would be better is to have AppDB keep track of what version of Windows works best with a particular application. This could then be queried on install of the application, or downloaded in bulk. It would be easy to take the data and create a registry file like what winecfg will be saving to. That way, AppDB becomes the place where this is maintained (so it is up to the individual maintainers to set the Windows version if it doesn't work with the default version) and there are no ugly heuristics involved. - Reece

Dec. 21, 2008

Re: Functions that should be static

by Kai Blin

On Thursday 18 December 2008 10:09:02 Francois Gouget wrote: > dlls/secur32/secur32.dll.so: SECUR32_initNegotiateSP This function would (and at some point did) register the Negotiate security provider. It's not called right now because the provider is not implemented and registering it broke some applications. The better solution here would be to completely remove negotiate.c and readd it once it's implemented. > dlls/secur32/secur32.dll.so: SECUR32_strdupW This should be used by functions like e.g. QueryContextAttributesW. It's just that we cheat and not implement the parts of that function that need to allocate strings yet. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Dec. 21, 2008

Re: ntdll: fix a compiler warning on PC-BSD

by Francois Gouget

I'm a bit surprised that PC-BSD/FreeBSD's mkdir() does not take a mode argument. Are you sure this is really the case? Maybe we are just mising a #include directive on BSD? (Unfortunately I don't really have access to a FreeBSD box right now) -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.

Dec. 21, 2008

Windows version autodetection

by Damjan Jovanovic

Hi There are some older applications out there, which don't install or run correctly unless Wine is emulating the correct Windows version (eg. Windows 9x). At least Windows XP has the ability to use certain heuristics to make an educated guess as to which version of Windows the application expects, and then lie in GetVersion() and behave like that version in relevant APIs. Should we do something like that for Wine? It would allow many applications to work out of the box. Damjan Jovanovic

Dec. 21, 2008

Re: Patchwatcher offline?

by Paul Vriens

Francois Gouget wrote: > On Sat, 20 Dec 2008, Paul Vriens wrote: > >> IneedAname wrote: >>> Looks like Patchwatcher has being offline from 09-Dec-2008. >>> Did I miss something or did someone trip over the mains cable? >>> >>> >> http://www.winehq.org/pipermail/wine-devel/2008-December/071059.html > > Well, obviously that's more than a day (I'm not complaining, just saying > the above post may not explain everything). > You know, I didn't even notice 'a day' :) -- Cheers, Paul.

Dec. 21, 2008

RE: Adding Mac joystick support -- build problem (resend)

by Nick Burns

Resending this due to the terrible hotmail "formatting" Any tips for how to get legible emails out of hotmail without doubling up the newlines would be greatly appreciated Note: I cannot even read the emails I send from hotmail... ------- I have a few tips for running built wine on OS X I have made some Apple specific mods to get wine (ogl) working Most of these are hacks to workaround some issues in xquartz X11 (and they got radars) 1 - Get/install an updated x11 (2.3.1+ has worked well for me) http://xquartz.macosforge.org/trac/wiki 2 - Apply my attached patch (I have others for specific games -- but this is the base) 3 - Open X11 and goto your 'patched' wine tree 4 - (under xterm) Run 'autoconf' to regen yer configure script (my patch mods configure.ac) 5 - (under xterm) Run 'make depend && make && sudo make install' Now you should be able to run d3d and ogl windows apps under wine - Nick

Dec. 21, 2008

RE: [PATCH] Fix glReadPixels call from read_from_framebuffer

by Nick Burns

Thanks for the git advice (still trying to learn git...) I will move the variable declarations up (I am so used to warnings killing my build that I was complacent) (I will also try and see if I can get hotmail to send email with newline characters -- not sure what it is doing to my formatting -- I choose plain text...) - Nick ---------------------------------------- > Date: Sun, 21 Dec 2008 17:03:55 +1100 > From: jeffzaroyko(a)gmail.com > To: adger44(a)hotmail.com > Subject: Re: [PATCH] Fix glReadPixels call from read_from_framebuffer > CC: wine-devel(a)winehq.org > > On Sun, Dec 21, 2008 at 4:40 PM, Nick Burns wrote: >> >> This is my last gfx fix for SHOGOThe readpixels call was putting data into the wrong place in the pbo (fixed with pixelstore)And the y-flip code was flipping the wrong data as well (set the bottom row to the bottom row and not the height'th row) >> The code used to handle fullscreen 2d blits (or blts without any colorkey masking)However sub-blits had issues (in the pbo path) 1 - readpixels read into the wrong part of the pbo 2 - the y-flip code would move around the uninited data (from the readpixels) and it read from the wrong place 3 - After 1 and 2 the pbo is corrupt and the blt code later had no chance... >> This patch fixes 1 and 2 -- letting the blt code shineThis can be seen in the SHOGO menu (now not corrupt!) >> Changelog Fix glReadPixels call from read_from_framebuffer Fix the call to readpixels so that 2d blts going thru the pbo path end up in the right place and get flipped correctly >> >> - Nick >> > > Hi > > + GLint rowLen = 0; > + GLint skipPix = 0; > + GLint skipRow = 0; > > You're declaring variables in a place which is not the start of a > block, this isn't legal in ANSI C/C90 as gcc points out: > surface.c: In function 'read_from_framebuffer': > surface.c:786: warning: ISO C90 forbids mixed declarations and code > > Also it looks like your email address is not correct in this patch? > > From: Nick Burns > git repo-config user.email "me(a)example.com" > > -Jeff

Dec. 21, 2008

Re: [PATCH] Fix glReadPixels call from read_from_framebuffer

by Jeff Zaroyko

On Sun, Dec 21, 2008 at 4:40 PM, Nick Burns <adger44(a)hotmail.com> wrote: > > This is my last gfx fix for SHOGOThe readpixels call was putting data into the wrong place in the pbo (fixed with pixelstore)And the y-flip code was flipping the wrong data as well (set the bottom row to the bottom row and not the height'th row) > The code used to handle fullscreen 2d blits (or blts without any colorkey masking)However sub-blits had issues (in the pbo path) 1 - readpixels read into the wrong part of the pbo 2 - the y-flip code would move around the uninited data (from the readpixels) and it read from the wrong place 3 - After 1 and 2 the pbo is corrupt and the blt code later had no chance... > This patch fixes 1 and 2 -- letting the blt code shineThis can be seen in the SHOGO menu (now not corrupt!) > Changelog Fix glReadPixels call from read_from_framebuffer Fix the call to readpixels so that 2d blts going thru the pbo path end up in the right place and get flipped correctly > > - Nick > Hi + GLint rowLen = 0; + GLint skipPix = 0; + GLint skipRow = 0; You're declaring variables in a place which is not the start of a block, this isn't legal in ANSI C/C90 as gcc points out: surface.c: In function 'read_from_framebuffer': surface.c:786: warning: ISO C90 forbids mixed declarations and code Also it looks like your email address is not correct in this patch? From: Nick Burns <nwburns(a)nwburns2.mshome.net> git repo-config user.email "me(a)example.com" -Jeff

Dec. 21, 2008

RE: Adding Mac joystick support -- build problem

by Nick Burns

I have a few tips for running built wine on OS XI have been working on getting SHOGO to run (I have one more patch to send up) I have made some Apple specific mods to get wine (ogl) workingMost of these are hacks to workaround some issues in X11 (and they got radars) 1 - Get/install an updated x11 (2.3.1+ has worked well for me) http://xquartz.macosforge.org/trac/wiki2 - Apply my attached patch (I have others for specific games -- but this is the base)3 - Open X11 and goto your 'patched' wine tree4 - (under xterm) Run 'autoconf' to regen yer configure script (my patch mods configure.ac)5 - (under xterm) Run 'configure' however you prefer Verify that the config.log says you have ogl6 - (under xterm) Run 'make depend && make && sudo make install' Now you should be able to run d3d and ogl windows apps under wine - Nick > Date: Sat, 20 Dec 2008 17:29:47 -0800 > From: n8gray(a)gmail.com > To: wine-devel(a)winehq.org > Subject: Adding Mac joystick support -- build problem > > Hi wine-devels, > > I've got a simple goal. I want to play IL-2 Sturmovik on my Mac > without rebooting. This flight sim is gold-rated in the app-db, so > this should be a walk in the park, but of course the game does require > a joystick. After a bit of poking I realized that there's no support > for joysticks under Mac OS. I'm willing to write the code for > joystick support, and I've even gotten as far as writing a test app > under OS X that enumerates all joysticks and polls their state. I've > looked at the linux joystick code in wine and think I can write the > equivalent code for OS X. > > What I *can't* seem to do is build a wine that can run IL-2. I've had > no problem installing and playing the demo using the 1.1.9 build at > http://www.kronenberg.org/darwine/ and using crossover games, but when > I build wine myself the IL-2 demo installer fails to run. I've tried > building the 1.1.9 and 1.1.10 tarballs and using macports to install > 1.1.10, all with the same result: > > --- begin log output --- > Could not load Mozilla. HTML rendering will be disabled. > err:wgl:has_opengl glx_version is 1.2 and GLX_SGIX_fbconfig extension > is unsupported. Expect problems. > wine: configuration in '/Users/n8gray/.wine' has been updated. > err:ntdll:RtlpWaitForCriticalSection section 0x7bc8a384 "loader.c: > loader_section" wait timed out in thread 0024, blocked by 0023, > retrying (60 sec) > wine: Unhandled page fault on read access to 0xffffffff at address > 0x1017:0x00000c1d (thread 0025), starting debugger... > couldn't load main module (2) > Unhandled exception: page fault on read access to 0xffffffff in 32-bit > code (1017:00000c1d). > In 32 bit mode. > Register dump: > CS:1017 SS:1217 DS:1217 ES:11ef FS:11ff GS:0037 > EIP:00000c1d ESP:000056ee EBP:00000000 EFLAGS:00010202( - 00 - -RI1) > EAX:00000001 EBX:00000080 ECX:000019b0 EDX:00000001 > ESI:00000000 EDI:00001217 > Stack dump: > 0x1217:0x56ee: f160 7b88 0000 7597 120f 0000 0000 0468 > 0x1217:0x56fe: 1027 0000 0000 0000 0000 0000 0000 0000 > 0x1217:0x570e: 0000 0000 0000 0000 0000 0000 0000 0000 > 023f: sel=11ff base=7eed0000 limit=0000ffff 32-bit rw- > Backtrace: > =>1 0x1017:0x00000c1d (0x1217:0x0000) > 0x1017:0x00000c1d: call 0x0000fffe > Modules: > Module Address Debug info Name (7 modules) > PE 60180000-60184000 Deferred advapi32 > PE 60310000-60325000 Deferred user32 > PE 604b0000-604b4000 Deferred gdi32 > PE 61cc0000-61d0d000 Deferred winmm > PE 622a0000-622a4000 Deferred version > PE 7b810000-7b889000 Deferred kernel32 > PE 7bc10000-7bc14000 Deferred ntdll > Threads: > process tid prio (all id:s are in hex) > 0000000c > 0000001f 0 > 0000001e 0 > 00000018 0 > 00000017 0 > 0000000e 0 > 0000000d 0 > 00000010 > 00000011 0 > 0000001b > 00000021 0 > 00000020 0 > 0000001d 0 > 0000001c 0 > 00000022 (D) C:\windows\system32\winevdm.exe > 00000025 0 <== > 00000024 0 > 00000023 0 > Backtrace: > =>1 0x1017:0x00000c1d (0x1217:0x0000) > err:ntdll:RtlpWaitForCriticalSection section 0x7b92c250 "syslevel.c: > Win16Mutex" wait timed out in thread 0023, blocked by 0025, retrying > (60 sec) > --- end log output --- > > If I use Mike's build I only get these messages: > wine: created the configuration directory '/Users/n8gray/.wine' > Could not load Mozilla. HTML rendering will be disabled. > wine: configuration in '/Users/n8gray/.wine' has been updated. > > Clearly there's some magic build juju that I don't have, perhaps > related to opengl. I've read the wiki, but I haven't found anything > that I haven't already tried. Can anybody provide a hint as to how to > get this working? BTW, I'm using the latest XQuartz 2.3.2_rc3 > (xorg-server 1.4.2-apple27). > > Thanks, > -n8 > > -- > Nathan Gray > http://www.n8gray.org/ >

Dec. 20, 2008

RE: [PATCH] Fix ddraw surface version setting

by Stefan Dösinger

Maybe I messed something up, but I noticed that the mail was from monday, while I am sure that I did not see it until Thurday. Maybe you forgot to subscribe to the mailing list, which forces the mails to go through moderation. A patch sent on Monday may be outdated on Thursday, although ddraw.dll is generally a static DLL. Can you check if you're subscribed to wine-patches properly?

Dec. 20, 2008

Re: wine-1.2 release criteria?

by Massimo Del Fedele

Vitaly Lipatov ha scritto: > В сообщении от 15 декабря 2008 Massimo Del Fedele написал(a): > > ... >> I'm (slowly) going on with dib engine, I choose at first Jesse's one as >> starting point because it had a source file structure I liked more. > Please if you do something with DIB Engine, publish your git repository. > We (Etersoft) do some tests and patches too, and I am wondering why do not > contact with our developer chi(a)etersoft.ru > > ... DIB engine is progressing a bit... solved the (I hope) last crash problem, now BitBlt works, but still unoptimized. Fonts partially work too. I can run Autocad with DIB engine and, even with slow bitblt and unoptimized font rendering, the speed gain on True Type font display is impressive. I' ve not published the git because I'm still changing some core stuffs, and I want it useable and stable enough before publishing. StretchBlt is still not done, and that's a must, IMHO. When I'll get these stuffs ready : Optimized BitBlt StretchBlt Completed font rendering Clipping, maybe... I'll publish the git. A note : my DIB engine now includes both Jesse Allen's and Huw Davies ones, merged to take the best of both. BTW, i'll finish it following this way, but I still think the best way would be to include it in wineX11.drv. Using the mixed driver approach, with different function pointers and physical devices depending on bitmap content is, imho, an ugly way to solve the problem..... Ciao Max

Dec. 20, 2008

RE: [PATCH] Fix ddraw surface version setting

by Nick Burns

Thanks for reviewing this patchI have one more for SHOGO (w.r.t. 2d surface blitting) - Nick> From: stefan(a)codeweavers.com> To: wine-devel(a)winehq.org> Subject: RE: [PATCH] Fix ddraw surface version setting> Date: Fri, 19 Dec 2008 01:17:13 +0100> > The patch looks ok to me

Dec. 20, 2008

RE: [PATCH] wined3d_gl.h minor typo fix

by Nick Burns

Whow I sure did mess that upI had my patch -- then fixed it up and made a new patchAnd for some dumb reason I uploaded the OLD version...SighI will resubmit that patch(Sorry about my git newbie-ness) - Nick> From: stefan(a)codeweavers.com> To: wine-devel(a)winehq.org> Subject: RE: [PATCH] wined3d_gl.h minor typo fix> Date: Fri, 19 Dec 2008 01:17:13 +0100> >> - USE_GL_FUNC(PGLFNGLFOGCOORDDVEXTPROC,> glFogCoordvEXT, EXT_FOG_COORD, NULL )\>> + USE_GL_FUNC(PGLFNGLFOGCOORDDVEXTPROC,> glFogCoorddvEXT, EXT_FOG_COORD, NULL )\> I think I fixed that one with a patch in my glFogCoord emulation patchset a> few days ago. Did you forget to update your git tree, or did I miss> something?> > Other than that, the patch breaks the alignment of the 3rd and 4th column> because a 'v' was added to the function name, but no space removed to keep> the alignment.

Dec. 20, 2008

Re: Adding Mac joystick support -- build problem

by Nathaniel Gray

Sorry to reply to self, but I forgot to mention I'm running OS X 10.5.5. -- Nathan Gray http://www.n8gray.org/

Dec. 20, 2008

Adding Mac joystick support -- build problem

by Nathaniel Gray

Hi wine-devels, I've got a simple goal. I want to play IL-2 Sturmovik on my Mac without rebooting. This flight sim is gold-rated in the app-db, so this should be a walk in the park, but of course the game does require a joystick. After a bit of poking I realized that there's no support for joysticks under Mac OS. I'm willing to write the code for joystick support, and I've even gotten as far as writing a test app under OS X that enumerates all joysticks and polls their state. I've looked at the linux joystick code in wine and think I can write the equivalent code for OS X. What I *can't* seem to do is build a wine that can run IL-2. I've had no problem installing and playing the demo using the 1.1.9 build at http://www.kronenberg.org/darwine/ and using crossover games, but when I build wine myself the IL-2 demo installer fails to run. I've tried building the 1.1.9 and 1.1.10 tarballs and using macports to install 1.1.10, all with the same result: --- begin log output --- Could not load Mozilla. HTML rendering will be disabled. err:wgl:has_opengl glx_version is 1.2 and GLX_SGIX_fbconfig extension is unsupported. Expect problems. wine: configuration in '/Users/n8gray/.wine' has been updated. err:ntdll:RtlpWaitForCriticalSection section 0x7bc8a384 "loader.c: loader_section" wait timed out in thread 0024, blocked by 0023, retrying (60 sec) wine: Unhandled page fault on read access to 0xffffffff at address 0x1017:0x00000c1d (thread 0025), starting debugger... couldn't load main module (2) Unhandled exception: page fault on read access to 0xffffffff in 32-bit code (1017:00000c1d). In 32 bit mode. Register dump: CS:1017 SS:1217 DS:1217 ES:11ef FS:11ff GS:0037 EIP:00000c1d ESP:000056ee EBP:00000000 EFLAGS:00010202( - 00 - -RI1) EAX:00000001 EBX:00000080 ECX:000019b0 EDX:00000001 ESI:00000000 EDI:00001217 Stack dump: 0x1217:0x56ee: f160 7b88 0000 7597 120f 0000 0000 0468 0x1217:0x56fe: 1027 0000 0000 0000 0000 0000 0000 0000 0x1217:0x570e: 0000 0000 0000 0000 0000 0000 0000 0000 023f: sel=11ff base=7eed0000 limit=0000ffff 32-bit rw- Backtrace: =>1 0x1017:0x00000c1d (0x1217:0x0000) 0x1017:0x00000c1d: call 0x0000fffe Modules: Module Address Debug info Name (7 modules) PE 60180000-60184000 Deferred advapi32 PE 60310000-60325000 Deferred user32 PE 604b0000-604b4000 Deferred gdi32 PE 61cc0000-61d0d000 Deferred winmm PE 622a0000-622a4000 Deferred version PE 7b810000-7b889000 Deferred kernel32 PE 7bc10000-7bc14000 Deferred ntdll Threads: process tid prio (all id:s are in hex) 0000000c 0000001f 0 0000001e 0 00000018 0 00000017 0 0000000e 0 0000000d 0 00000010 00000011 0 0000001b 00000021 0 00000020 0 0000001d 0 0000001c 0 00000022 (D) C:\windows\system32\winevdm.exe 00000025 0 <== 00000024 0 00000023 0 Backtrace: =>1 0x1017:0x00000c1d (0x1217:0x0000) err:ntdll:RtlpWaitForCriticalSection section 0x7b92c250 "syslevel.c: Win16Mutex" wait timed out in thread 0023, blocked by 0025, retrying (60 sec) --- end log output --- If I use Mike's build I only get these messages: wine: created the configuration directory '/Users/n8gray/.wine' Could not load Mozilla. HTML rendering will be disabled. wine: configuration in '/Users/n8gray/.wine' has been updated. Clearly there's some magic build juju that I don't have, perhaps related to opengl. I've read the wiki, but I haven't found anything that I haven't already tried. Can anybody provide a hint as to how to get this working? BTW, I'm using the latest XQuartz 2.3.2_rc3 (xorg-server 1.4.2-apple27). Thanks, -n8 -- Nathan Gray http://www.n8gray.org/

Dec. 20, 2008

Re: Patchwatcher offline?

by Francois Gouget

On Sat, 20 Dec 2008, Paul Vriens wrote: > IneedAname wrote: > > Looks like Patchwatcher has being offline from 09-Dec-2008. > > Did I miss something or did someone trip over the mains cable? > > > > > http://www.winehq.org/pipermail/wine-devel/2008-December/071059.html Well, obviously that's more than a day (I'm not complaining, just saying the above post may not explain everything). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ There are 10 types of people in the world... those who understand binary and those who don't.

Dec. 20, 2008

Re: wow, there are more win64 apps than I thought...

by Francois Gouget

On Sat, 20 Dec 2008, Roderick Colenbrander wrote: > > Dan Kegel a écrit : > > > I updated http://wiki.winehq.org/Wine64 with a list > > > of some win64 apps. There are lots more than I > > > expected. > > > > > > > > > > From the Wiki: > > > > "One of the major differences is the size of the "long" type, which is > > 64 bit in Linux but 32 bit in Windows" > > > > Why is that so ? Shouldn't a "long" be always 32 bits ? > > > > On Windows the size is constant so 32-bit but on linux it is 64-bit. And it's not just Linux. As far as I know a long is 64bits on every 64bit platform out there, except for Windows. It's certainly true for all the Unices (HP-UX, Dec, Solaris, FreeBSD, etc). And really that's the way long is meant to be. But Microsoft decided that since Windows application programmers have never encountered the word 'portability' even once in their life, they could not be expected to have understood the difference between 'int' and 'long', and thus would likely be so upset if 'long' where ever to change size that they might commit suicide in droves. So they decided that 'long' would remain 32bits. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science.

Dec. 20, 2008

Re: Functions that should be static

by Francois Gouget

On Sat, 20 Dec 2008, Christian Costa wrote: [...] > If you have a class A (with methods implemented in file 1) that inherits from > another class B (methods in file B). > The class A may overrides some methods of B which may become unused if B is > never instanciated and B methods not reused. > They will be tracked by your script then. > We could make these functions static or worst remove then but from object > programming pov is not good. I don't see any reason not to make the methods of B static, whether class A exists or not. Note that 'static' does not prevent a function from being called from another object file if you give a pointer to them to that other file (as you do with the virtual table). Also the compiler will not complain that these functions are unused because they are indeed used: you take their address. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The last time religion ruled, it was called the dark ages.

Dec. 20, 2008

Re: Wine integration with native (Gtk, Qt, Cocoa/Carbon) themes

by Vitaliy Margolen

buu700 wrote: > > Roderick Colenbrander wrote: >> This is technically not possible. We can't use native APIs for drawing. >> > > Ah, that sucks. Out of curiosity, why is that? As a non-dev, logically it > seems like Wine, which translates Win32 calls for the kernel and X11, would > be able to do the same for Qt, but then again I know next to nothing about > the internals of Wine. Is it that doing so would require a major redesign, > isn't feasible for whatever reason, or just isn't possible at all? Windows' standard controls, windows, fonts, etc work completely different from QT ones. Win32 API exposes a lot of inner-workings of each control. And lots of applications depend on that. I'm not even talking about how the pieces fit together. In short - for most windows apps to work controls have to behave in a very particular way which dramatically differs from any other toolkit. And no Wine doesn't just "translates win calls to kernel and X". Wine re-implements all of the windows' user space on top of X, kernel and other libraries. Vitaliy

Dec. 20, 2008

Re: Wine integration with native (Gtk, Qt, Cocoa/Carbon) themes

by buu700

Roderick Colenbrander wrote: > > This is technically not possible. We can't use native APIs for drawing. > Ah, that sucks. Out of curiosity, why is that? As a non-dev, logically it seems like Wine, which translates Win32 calls for the kernel and X11, would be able to do the same for Qt, but then again I know next to nothing about the internals of Wine. Is it that doing so would require a major redesign, isn't feasible for whatever reason, or just isn't possible at all? -- View this message in context: http://www.nabble.com/Wine-integration-with-native-%28Gtk%2C-Qt%2C-Cocoa-Ca… Sent from the Wine - Devel mailing list archive at Nabble.com.

Dec. 20, 2008

Re: Wine integration with native (Gtk, Qt, Cocoa/Carbon) themes

by Roderick Colenbrander

> > > Reece Dunn-2 wrote: > > > > Thoughts? Ideas? > > > > I'm just a user, not a dev, so forgive me if this sounds stupid, but it > seems to me like it would be simpler to just create some sort of layer > that > forwards all calls to the Win32 theming API to Qt, and make Wine dependent > on Qt (perhaps as a GSoC project?). Qt bends over backwards to maintain a > native look and feel on all major platforms, including Windows, OS X, > KDE/X11, and GNOME/Xfce/BBQ/X11 (in 4.5), so Wine's codebase wouldn't have > to be overly complicated by hacks to support each platform. This approach > would also have the benefit of rendering the QuartzDriver planned for Wine > 1.2 completely unnecessary, if I'm not mistaken. Since Qt is maintained by > a > ton of devs unrelated to the Wine project, this would also allow Wine to > ignore changes in this area specific to each platform, whereas with other > approaches I've seen in this thread Wine would have to constantly adapt to > each change and put in the work necessary to port the native theming to a > new platform; of course, Wine would still have to adapt to changes in the > Qt > API, but that would be much more predictable and presumably less to deal > with. > -- > View this message in context: > http://www.nabble.com/Wine-integration-with-native-%28Gtk%2C-Qt%2C-Cocoa-Ca… > Sent from the Wine - Devel mailing list archive at Nabble.com. > > This is technically not possible. We can't use native APIs for drawing. Roderick -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

Dec. 20, 2008

Re: [PATCH] winedbg: add a crash dialog for --auto mode

by Juan Lang

Hi Mikolaj, there are a few typos in your patch: + /* we waist some memory for the full path and UNICODE_STRING header, but s/waist/waste/ Sorry, I wouldn't ordinarily comment on something so minor, but there are a few typos in the resources too: + LTEXT "The program %s has met a serious problem and needs to close. We are sorry for the inconvinience.", s/inconvinience/inconvenience/ Also, using "encountered" rather than "met" seems a little more idiomatic. + You may want to check http://appdb.winehq.org if there are some \ + tips about running this applicaiton.\n\n\ s/applicaiton/application/ Also, the following wording seems better: You may want to check http://appdb.winehq.org for tips about running this application. Thanks, --Juan

Dec. 20, 2008

Re: ntoskrnl.exe: Add a redirect for IoGetCurrentProcess

by Chris Wulff

You're right, ignore this patch. It happens to work for my particular application but then I think it is just passed as a parameter to another function (which happens to ignore it.) -- Chris Wulff On Sat, 2008-12-20 at 13:29 +0200, Paul Chitescu wrote: > On Saturday 20 December 2008 13:12:53 Paul Chitescu wrote: > > On Saturday 20 December 2008 07:31:53 Chris Wulff wrote: > > > Redirect for IoGetCurrentProcess to kernel32.GetCurrentProcess > > > > > > -- Chris Wulff > > > > This is incorrect. Please provide a separate stub for IoGetCurrentProcess > > as it returns something else: > > [...] > > Actually, investigating further it would be better to NOT provide at all a > stub for this function since the _EPROCESS structure is huge and different on > each Windows version (and sometimes service pack). > > IMHO it's better to have the driver abort in a controlled way (calling this > function) than crashing later trying to access some obscure location in the > structure returned by it. > > Paul Chitescu > >

Dec. 20, 2008

Re: qedit: tests/mediadet.c test skips sometimes

by Rico Schüller

Francois Gouget schrieb: > On Sat, 20 Dec 2008, Rico Schüller wrote: > [...] > >> I think I've found the problem ... it is in UINT WINAPI >> GetTempFileNameW( LPCWSTR path, LPCWSTR prefix, UINT unique, LPWSTR >> buffer ) in line UINT num = GetTickCount() & 0xffff; . >> On fast machines GetTickCount has the same value when it is called two >> times in a short time. Therefore it generates the same time and as a >> result the same file, which isn't the case on windows. On windows it >> looks like there is a number increasing each run by one, something like this >> static UINT num; >> num = num++ & 0xffff; >> should be the solution. >> >> To make the qedit test happy a Sleep(...) between the two calls should >> be enough. >> > > In either cases, shouldn't we worry about the filename being predictable > with the security issues this implies? I know this very issue has > generated a lot of security issues on Unix... > > The filename which is generated by GetTempFileName is always predictable. You simply have to generate 0xffff-1 files in the temp folder which match this name "prefix{xxxx}.tmp" and then GetTempFileName could only return the missing one! So I didn't see a security reason here. Security could only be given by generating the file with the correct rights. So no other app/user could change the files. We should use the generated tmp file as it is, because there is a chance, when the qedit test deletes and generates a new one another app could have opened a file with this name already. Then the test would be skipped without a real reason. Any suggestions how to fix the test? Should I also change the behaviour for GetTempFileName so that it matches the one from XP? Cheers Rico

Dec. 20, 2008

Re: Wine integration with native (Gtk, Qt, Cocoa/Carbon) themes

by buu700

Reece Dunn-2 wrote: > > Thoughts? Ideas? > I'm just a user, not a dev, so forgive me if this sounds stupid, but it seems to me like it would be simpler to just create some sort of layer that forwards all calls to the Win32 theming API to Qt, and make Wine dependent on Qt (perhaps as a GSoC project?). Qt bends over backwards to maintain a native look and feel on all major platforms, including Windows, OS X, KDE/X11, and GNOME/Xfce/BBQ/X11 (in 4.5), so Wine's codebase wouldn't have to be overly complicated by hacks to support each platform. This approach would also have the benefit of rendering the QuartzDriver planned for Wine 1.2 completely unnecessary, if I'm not mistaken. Since Qt is maintained by a ton of devs unrelated to the Wine project, this would also allow Wine to ignore changes in this area specific to each platform, whereas with other approaches I've seen in this thread Wine would have to constantly adapt to each change and put in the work necessary to port the native theming to a new platform; of course, Wine would still have to adapt to changes in the Qt API, but that would be much more predictable and presumably less to deal with. -- View this message in context: http://www.nabble.com/Wine-integration-with-native-%28Gtk%2C-Qt%2C-Cocoa-Ca… Sent from the Wine - Devel mailing list archive at Nabble.com.

Dec. 20, 2008

Re: include/wine: Header only implementation of generic redblack binary search tree.

by Henri Verbeet

2008/12/20 Marcus Meissner <marcus(a)jet.franken.de>: > On Sat, Dec 20, 2008 at 07:30:53PM +0200, Pauli Nieminen wrote: >> This implementation provides easy access to rb-tree which should be used instead of hashmap >> if number of entries changes a lot of over time of execution. >> It should be simple to write hashtree based on this which uses hash value of the key instead of >> key it self. (Which would speed up tree operations a lot if key is long string) >> >> Note: I have also code to test the tree functionality but I don't know where to put >> internal test cases. > > For what functionality in Wine is this intended? We do not seem > to be using hashmap either? > We use hash maps in a couple of places in wined3d. I think using a rbtree could be useful there, but I don't particularly like this implementation. If other people agree that a generic rbtree would be useful outside of wined3d, I'm pretty sure I can write something that's less heavy on macros.

Dec. 20, 2008

Re: include/wine: Header only implementation of generic redblack binary search tree.

by Marcus Meissner

On Sat, Dec 20, 2008 at 07:30:53PM +0200, Pauli Nieminen wrote: > This implementation provides easy access to rb-tree which should be used instead of hashmap > if number of entries changes a lot of over time of execution. > It should be simple to write hashtree based on this which uses hash value of the key instead of > key it self. (Which would speed up tree operations a lot if key is long string) > > Note: I have also code to test the tree functionality but I don't know where to put > internal test cases. For what functionality in Wine is this intended? We do not seem to be using hashmap either? Ciao, Marcus

Dec. 20, 2008

Re: jscript: Do not call memcpy() with a NULL pointer argument

by Andrew Talbot

Jacek Caban wrote: > I'm not fan of such fixes, but if you want to fix it, you should check > len, not str, in your patch and you may move zero-terminating outside > if..else statement. > > > Jacek Thank you, I shall fix it in the better way that you describe here. -- Andy.

Dec. 20, 2008

Re: wow, there are more win64 apps than I thought...

by Roderick Colenbrander

> Dan Kegel a écrit : > > I updated http://wiki.winehq.org/Wine64 with a list > > of some win64 apps. There are lots more than I > > expected. > > > > > > From the Wiki: > > "One of the major differences is the size of the "long" type, which is > 64 bit in Linux but 32 bit in Windows" > > Why is that so ? Shouldn't a "long" be always 32 bits ? > On Windows the size is constant so 32-bit but on linux it is 64-bit. Roderick -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a

Dec. 20, 2008

Re: wow, there are more win64 apps than I thought...

by Frank Richter

On 20.12.2008 13:42, Dan Kegel wrote: > I updated http://wiki.winehq.org/Wine64 with a list > of some win64 apps. There are lots more than I > expected. I also recall that Far Cry (1) is available as 64-bit version, tho someone who actually possesses that game should check back. So it could also serve as a test case for DirectX in 64 bit ;) -f.r.

Dec. 20, 2008

Re: wow, there are more win64 apps than I thought...

by Juan Lang

> Shouldn't a "long" be always 32 bits ? The answer is pretty obviously no, if it isn't 32 bits everywhere. According to the C standard, long need only be at least as big as int. --Juan

Dec. 20, 2008

Re: jscript: Do not call memcpy() with a NULL pointer argument

by Jacek Caban

Hi Andrew, Andrew Talbot wrote: > Jacek Caban wrote: > > >> The string was always zero-terminated without your patch. It's fine to >> call create_string with NULL str argument as long as len is 0 and >> current implementation works fine in this case. >> >> >> Jacek >> > > Hi Jacek, > > Technically, behavior is undefined if the pointers do not each point to an > object, even if the size parameter has a value of zero (see > http://tinyurl.com/6eqo3n, third post). Though I concede that it would be a > rare implementation that touched its pointers (or copies of them) in that > case. > I'm not fan of such fixes, but if you want to fix it, you should check len, not str, in your patch and you may move zero-terminating outside if..else statement. Jacek

Dec. 20, 2008

Re: wow, there are more win64 apps than I thought...

by Michael Pujos

Dan Kegel a écrit : > I updated http://wiki.winehq.org/Wine64 with a list > of some win64 apps. There are lots more than I > expected. > > From the Wiki: "One of the major differences is the size of the "long" type, which is 64 bit in Linux but 32 bit in Windows" Why is that so ? Shouldn't a "long" be always 32 bits ?

Dec. 20, 2008

Re: Patchwatcher offline?

by Paul Vriens

IneedAname wrote: > Looks like Patchwatcher has being offline from 09-Dec-2008. > Did I miss something or did someone trip over the mains cable? > > http://www.winehq.org/pipermail/wine-devel/2008-December/071059.html -- Cheers, Paul.

Dec. 20, 2008

Re: Functions that should be static

by Christian Costa

Francois Gouget a écrit : > On Thu, 18 Dec 2008, Christian Costa wrote: > [...] > >> For 1) Why not adding a keyword to mark these functions. Something like >> WINAPI which resolve to nothing but that can be tracked by your script. >> > > We could potentially go this way if I merge these checks with > winapi_check one day. But for now I prefer not to touch Wine's code. > Besides there's really only about a handful of these. > > >> I would add another item for more object oriented stuff. Some default >> implentations can be written but not always used. >> This is sort of templates. This is used in quartz for example. >> > > Do you have a specific example of this? > > If you have a class A (with methods implemented in file 1) that inherits from another class B (methods in file B). The class A may overrides some methods of B which may become unused if B is never instanciated and B methods not reused. They wil be tracked by your script then. We could make these functions static or worst remove then but from object programming pov is not good. Implement objects or interfaces in C is a little messy. Haven't something more consistent would be more convenient I think. That would we good if we could treat a class as a whole rather that just independants C functions. That said, in quartz only pins use that currently (maybe more base classes could be written like what's done in Direct Show base classes (through strmbase.lib)). And if we move that code to a separate static lib (strmbase like in DirectShow), functions will be exported and the problem will disappear. Maybe it isn't worth the trouble. Christian

Dec. 20, 2008

Re: wow, there are more win64 apps than I thought...

by Markus Hitter

Am 20.12.2008 um 13:42 schrieb Dan Kegel: > I updated http://wiki.winehq.org/Wine64 with a list > of some win64 apps. There are lots more than I > expected. Well, Catia comes with a 64-bit flavour as well, like probably any serious CAD or FEA package. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/

Dec. 20, 2008

Re: wow, there are more win64 apps than I thought...

by Roderick Colenbrander

> Von: "Dan Kegel" <dank(a)kegel.com> > An: "Wine Devel" <wine-devel(a)winehq.org> > Betreff: wow, there are more win64 apps than I thought... > I updated http://wiki.winehq.org/Wine64 with a list > of some win64 apps. There are lots more than I > expected. > I guess it is time to make 64-bit Photoshop CS4 a requirement for Wine 1.2 ;) Roderick -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a

Dec. 20, 2008

Re: wow, there are more win64 apps than I thought...

by Andrew Talbot

Dan Kegel wrote: > I updated http://wiki.winehq.org/Wine64 with a list > of some win64 apps. There are lots more than I > expected. Some of the top chess engines, such as Rybka (www.rybkachess.com) have 64-bit versions.

Dec. 20, 2008

Re: Andrei Derevyanko : mshtml: Updated test of QueryInterface.

by Vitaly Lipatov

В следующий раз - если ты добавляешь тест на интерфейс IMarshal, так и пиши. Просто Updated test - бессмысленно. В сообщении от 20 декабря 2008 Вы написали: > Module: wine > Branch: master > Commit: 2afc8fcd5a788b94c64de654823bf2f8b262338e > URL: > http://source.winehq.org/git/wine.git/?a=commit;h=2afc8fcd5a788b94c64de6548 >23bf2f8b262338e > > Author: Andrei Derevyanko <and(a)etersoft.ru> > Date: Thu Dec 18 14:59:57 2008 +0300 > > mshtml: Updated test of QueryInterface. > > --- > > dlls/mshtml/tests/htmldoc.c | 5 +++++ > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/dlls/mshtml/tests/htmldoc.c b/dlls/mshtml/tests/htmldoc.c > index 84803fb..ed69725 100644 > --- a/dlls/mshtml/tests/htmldoc.c > +++ b/dlls/mshtml/tests/htmldoc.c > @@ -3766,6 +3766,11 @@ static void test_QueryInterface(IUnknown *unk) > hres = IUnknown_QueryInterface(unk, &IID_UndocumentedScriptIface, > (void**)&qi); ok(hres == E_NOINTERFACE, "QueryInterface returned %08x, > expected E_NOINTERFACE\n", hres); ok(qi == NULL, "qi=%p, expected NULL\n", > qi); > + > + qi = (void*)0xdeadbeef; > + hres = IUnknown_QueryInterface(unk, &IID_IMarshal, (void**)&qi); > + ok(hres == E_NOINTERFACE, "QueryInterface returned %08x, expected > E_NOINTERFACE\n", hres); + ok(qi == NULL, "qi=%p, expected NULL\n", qi); > } > > static void init_test(enum load_state_t ls) { -- С уважением, Виталий Липатов Россия, Санкт-Петербург. www.etersoft.ru GNU! ALT Linux Team! WINE! WIKI! LaTeX! LyX!

Dec. 20, 2008

wow, there are more win64 apps than I thought...

by Dan Kegel

I updated http://wiki.winehq.org/Wine64 with a list of some win64 apps. There are lots more than I expected.

Dec. 20, 2008

question about translating winehq.org

by Maik Schulz

Hi, how can I translate the top navigation bar ("Forums" would be "Foren" in German) and the word "Search" (would be "Suche" in German) next to the search box? Cheers, -Maik

Dec. 20, 2008

Re: wine-1.2 release criteria?

by Vitaly Lipatov

В сообщении от 15 декабря 2008 Massimo Del Fedele написал(a): ... > I'm (slowly) going on with dib engine, I choose at first Jesse's one as > starting point because it had a source file structure I liked more. Please if you do something with DIB Engine, publish your git repository. We (Etersoft) do some tests and patches too, and I am wondering why do not contact with our developer chi(a)etersoft.ru ... > When I'll get something stable I'll post the code somewhere. > About disabling/enabling the engine, there are 4 choices : > 1-by registry > 2-by environment variable > 3-by ./configure > 4-simply removing winedib.dll.so; driver goes thru x11 if it doesn't exist. I guess it is a wrong way. Just use engine's function if you are sure it works good. -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

Dec. 20, 2008

Re: ntoskrnl.exe: Add a redirect for IoGetCurrentProcess

by Paul Chitescu

On Saturday 20 December 2008 13:12:53 Paul Chitescu wrote: > On Saturday 20 December 2008 07:31:53 Chris Wulff wrote: > > Redirect for IoGetCurrentProcess to kernel32.GetCurrentProcess > > > > -- Chris Wulff > > This is incorrect. Please provide a separate stub for IoGetCurrentProcess > as it returns something else: > [...] Actually, investigating further it would be better to NOT provide at all a stub for this function since the _EPROCESS structure is huge and different on each Windows version (and sometimes service pack). IMHO it's better to have the driver abort in a controlled way (calling this function) than crashing later trying to access some obscure location in the structure returned by it. Paul Chitescu

Dec. 20, 2008

Re: ntoskrnl.exe: Add a redirect for IoGetCurrentProcess

by Paul Chitescu

On Saturday 20 December 2008 07:31:53 Chris Wulff wrote: > Redirect for IoGetCurrentProcess to kernel32.GetCurrentProcess > > -- Chris Wulff This is incorrect. Please provide a separate stub for IoGetCurrentProcess as it returns something else: "The IoGetCurrentProcess routine returns a pointer to the current process." - needs to be a valid pointer to some undocumented structure _EPROCESS "GetCurrentProcess Function Retrieves a pseudo handle for the current process." - essentially (HANDLE)-1 FYI I use a stub that returns (PEPROCESS)"System" since I traced some Sysinternals utility comparing the first 6 bytes to that string: TRACE(": semi-stub\n"); return (PEPROCESS)"System"; /* Sysinternals portmon expects this one */ http://www.winehq.org/pipermail/wine-patches/2008-February/049784.html This patch was not accepted for unknown reason. Paul Chitescu

Dec. 20, 2008

Re: wine-1.2 release criteria?

by Vitaly Lipatov

В сообщении от 15 декабря 2008 Pavel Troller написал(a): ... > All these things have a common denominator: proprietary USB drivers. It's > fine that wine can use USB scanners/cameras/printers etc, which can be > interfaced though native Linux drivers/libraries, but these are almost > always usable directly from Linux, while those proprietary devices aren't. > Is there any chance that wine will progress in this area ? I'm ready to > supply a bounty for a volunteer making some progress here. We (Etersoft) are realized USB support in wine via libusb and do many fixes in ntoskrnl.exe to load and run proprietary drivers for protection keys (like HASP). AS I know, this improvements is not acceptable by Alexandre. If anyone is interested to consult us to do our code more acceptable, you are welcome. -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

Dec. 20, 2008

Re: qedit: tests/mediadet.c test skips sometimes

by Francois Gouget

On Sat, 20 Dec 2008, Rico Schüller wrote: [...] > I think I've found the problem ... it is in UINT WINAPI > GetTempFileNameW( LPCWSTR path, LPCWSTR prefix, UINT unique, LPWSTR > buffer ) in line UINT num = GetTickCount() & 0xffff; . > > On fast machines GetTickCount has the same value when it is called two > times in a short time. Therefore it generates the same time and as a > result the same file, which isn't the case on windows. On windows it > looks like there is a number increasing each run by one, something like this > static UINT num; > num = num++ & 0xffff; > should be the solution. > > To make the qedit test happy a Sleep(...) between the two calls should > be enough. In either cases, shouldn't we worry about the filename being predictable with the security issues this implies? I know this very issue has generated a lot of security issues on Unix... -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different.

Dec. 20, 2008

Re: ntoskrnl.exe: Add a redirect for IoGetCurrentProcess

by Andrey Turkin

I believe this is wrong - IoGetCurrentProcess return pointer to kernel EPROCESS structure instance, and GetCurrentProcess return constant (HANDLE)-1 . The structure is declared opaque so drivers must not dereference it, but some drivers surely won't obey. 2008/12/20 Chris Wulff <crwulff(a)rochester.rr.com> > Redirect for IoGetCurrentProcess to kernel32.GetCurrentProcess > > -- Chris Wulff > > > >

Dec. 20, 2008