August 2005 - Wine-Devel - list.winehq.org

Re: pf_vsnprintf implementatnion of 'I', 'I32' and 'I64' prefixes for type specifiers

by Aneurin Price

David Laight wrote: > On Tue, Aug 02, 2005 at 10:35:59PM +0900, Mike McCormack wrote: > >>It's a little more complicated than you think, after you start handling >>all the width modifiers, various floating point formats, etc. > > > Not to mention coding in the 'brokenness'! > On windows: > _snprintf(buff, 3, "ab" ) returns 2, buff = "ab<0>" > _snprintf(buff, 3, "abcd" ) returns -1, buff = "ab<0>" > but: > _snprintf(buff, 3, "abc" ) returns 3, buff = "abc" > without NUL terminating the string. > > Do you replicate that? > > David > I believe my attempt at this was entirely compatible with Windows' behaviour (modulo some potential undiscovered bugs), including deviations from MSDN. Unfortunately, it wasn't very well written, and I can never seem to find the time to get the experience necessary to become competent. If anyone wants to look at it though, try the archive for wine-devel and wine-patches. If anyone has a *particular* interest, I might even have a look at it again with the benefit of at least *some* additional coding practice :). At least I could reduce the number of HeapAllocs, though I imagine there are more fundamental problems... Aneurin Price

Aug. 9, 2005

Printing Problems

by josie＠mbstemps.com

I have been trying to print reports in Landscape and every time a line hits about 122 characters it cuts out 5 characters and then picks up with the rest of the line, example 'Wine Printing Problems' would be 'Wine ing Problems.' Is anybody familiar with this kind of problem and what I can do to remedy this? I'm not sure if it has to do with the line buffer or the printer driver. Thanks All, Josie

Aug. 8, 2005

Re: wine/ server/trace.c server/request.h server/p ...

by Vincent Béron

Le lun 08/08/2005 à 11:11, Alexandre Julliard a écrit : [snip] > Modified files: > server : trace.c request.h protocol.def mapping.c file.c > fd.c change.c > include/wine : server_protocol.h > > Log message: > Added an unmount_device request that invalidates all file descriptors > open on a given Unix device. > > Patch: http://cvs.winehq.org/patch.py?id=19368 [snip] Does that mean we can now eject a CD even if an installer program keeps a file open on it? If so, should we have a wineeject to call that server request, or is it planned to be taken care of in some other way? Vincent

Aug. 8, 2005

Re[2]: Inconsistency/bug with GetProcAddress

by Vitaliy Margolen

>> >>>It's a common technique to rely on the fact that exports from kernel32 >> >>>reside at the same address to use CreateRemoteThread calling LoadLibrary >> >>>for remote code injection (this is not what Vitaliy's App is doing here >> >>>but the assertions are the same). >> >>It's hard to implement that in Wine, because dlls are loaded using >> >>dlopen() and there's no way to specify which address to load the dll at. >> >I would say that the only relatively sane way to do it is to re-implement >> >dlopen to support such functionality. The ELF tables that dlopen needs are >> >documented. It doesn't seem like a trivial task to reimplement it, but it >> >should be doable. Last time I checked, ELF tables are at least manageable >> > to deal with given a rainy afternoon: >> >http://hrabia.ibib.waw.pl/~winnie/qtbeheader.html >> There is also other way to do it. Wine could create the jump table >> (I don't know if it's good name in English) that would look like: >> jmp <func1> >> jmp <func2> >> ... >> where func1 is what dlsym returns and GetProcAddress could return >> address to this jump instruction. This table could be mmaped in fixed >> place. > That's clever too! I didn't think of it. Now the question is if the copy > protection guys didn't think of doing checksumming of the actual functions in > question, or if they won't eventually. That'd firmly lock their products to > Windows, unless their checksumming was insecure. Then code could be > fabricated to match the signature while doing the jump that one needs. One > hopes they don't read wine-devel ;) Well they actually took care of that. They don't really use GetProcAddress. At least safedisc doesn't. They pretty much implemented their own GetProcAddress that does work on wine. I don't know details of it but it suffers form the same problem :-( Something tells me that their GetProcAddress will not work with such a jump table. Vitaliy

Aug. 8, 2005

Re: [Bug 3148] Mouse: multi-file "selection" & drag behavior broken

by Hiji

> > Anybody on this list make any changes to listview > or > > treeview in the last few months? > I wouldn't even find it hard to believe that they > already forgot about it... > > If you want hard, definitive data, then I I cannot > find any reason why you > wouldn't want to look at ChangeLog... > How about this: I didn't know about ChangeLog! LOL! I'm looking through it now... ;) Thanks! Hiji ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs

Aug. 8, 2005

Re: Help debugging GLXUnsupportedPrivateRequest failure

by Alex Villacís Lasso

Lionel Ulmer wrote: >On Wed, Aug 03, 2005 at 12:13:00PM -0500, Alex Villacís Lasso wrote: > > >>No luck. The patch did not change a thing in my configuration. It still >>fails with the exact same failed request. >> >> > >Did you test any other OpenGL application (except 'glxinfo') with your >set-up to see if this is Wine specific or generic to GL ? > > Lionel > > > I updated my Fedora 4 setup with a new version of gcc (4.0.1 instead of 4.0.0), then compiled a vanilla 2.6.12 kernel and the Wine CVS tree. This made the issue magically disappear. Now I have an unrelated crash *after* a setup screen, but this is definitely a progress. I would recommend staying away from gcc 4.0.0 and update to 4.0.1 or higher before compiling Wine, since this obviously indicates a miscompiling of Wine source code. Alex Villacís Lasso

Aug. 8, 2005

Re: Inconsistency/bug with GetProcAddress

by Kuba Ober

> >>>It's a common technique to rely on the fact that exports from kernel32 > >>>reside at the same address to use CreateRemoteThread calling LoadLibrary > >>>for remote code injection (this is not what Vitaliy's App is doing here > >>>but the assertions are the same). > >>It's hard to implement that in Wine, because dlls are loaded using > >>dlopen() and there's no way to specify which address to load the dll at. > >I would say that the only relatively sane way to do it is to re-implement > >dlopen to support such functionality. The ELF tables that dlopen needs are > >documented. It doesn't seem like a trivial task to reimplement it, but it > >should be doable. Last time I checked, ELF tables are at least manageable > > to deal with given a rainy afternoon: > >http://hrabia.ibib.waw.pl/~winnie/qtbeheader.html > There is also other way to do it. Wine could create the jump table > (I don't know if it's good name in English) that would look like: > jmp <func1> > jmp <func2> > ... > where func1 is what dlsym returns and GetProcAddress could return > address to this jump instruction. This table could be mmaped in fixed > place. That's clever too! I didn't think of it. Now the question is if the copy protection guys didn't think of doing checksumming of the actual functions in question, or if they won't eventually. That'd firmly lock their products to Windows, unless their checksumming was insecure. Then code could be fabricated to match the signature while doing the jump that one needs. One hopes they don't read wine-devel ;) Kuba

Aug. 8, 2005

Re: Inconsistency/bug with GetProcAddress

by Jacek Caban

Kuba Ober wrote: >On Sunday 07 August 2005 10:13, Mike McCormack wrote: > > >>>http://www.codeguru.com/Cpp/W-P/system/processesmodules/article.php/c5767 >>>/ >>> >>>says: >>> > When creating a process, the loader on Win 2000, Win XP and Win 2003 >>> > checks if kernel32.dll and user32.dll (their names are hardcoded into >>> > the loader) are mapped at their preferred bases; if not, a hard error >>> > is raised. In WinNT 4 ole32.dll was also checked. In WinNT 3.51 and >>> > lower such checks were not present, so kernel32.dll and user32.dll >>> > could be anywhere. Anyway, the only module that is always at its base >>> > is ntdll.dll. The loader doesn't check it, but if ntdll.dll is not at >>> > its base, the process just can't be created. >>> >>>It's a common technique to rely on the fact that exports from kernel32 >>>reside at the same address to use CreateRemoteThread calling LoadLibrary >>>for remote code injection (this is not what Vitaliy's App is doing here >>>but the assertions are the same). >>> >>> >>OK, fair enough. >> >>It's hard to implement that in Wine, because dlls are loaded using >>dlopen() and there's no way to specify which address to load the dll at. >> >> > >I would say that the only relatively sane way to do it is to re-implement >dlopen to support such functionality. The ELF tables that dlopen needs are >documented. It doesn't seem like a trivial task to reimplement it, but it >should be doable. Last time I checked, ELF tables are at least manageable to >deal with given a rainy afternoon: >http://hrabia.ibib.waw.pl/~winnie/qtbeheader.html > >Kuba > > Hello. There is also other way to do it. Wine could create the jump table (I don't know if it's good name in English) that would look like: jmp <func1> jmp <func2> ... where func1 is what dlsym returns and GetProcAddress could return address to this jump instruction. This table could be mmaped in fixed place. Jacek

Aug. 8, 2005

Re: Inconsistency/bug with GetProcAddress

by Kuba Ober

On Sunday 07 August 2005 10:13, Mike McCormack wrote: > > http://www.codeguru.com/Cpp/W-P/system/processesmodules/article.php/c5767 > >/ > > > > says: > > > When creating a process, the loader on Win 2000, Win XP and Win 2003 > > > checks if kernel32.dll and user32.dll (their names are hardcoded into > > > the loader) are mapped at their preferred bases; if not, a hard error > > > is raised. In WinNT 4 ole32.dll was also checked. In WinNT 3.51 and > > > lower such checks were not present, so kernel32.dll and user32.dll > > > could be anywhere. Anyway, the only module that is always at its base > > > is ntdll.dll. The loader doesn't check it, but if ntdll.dll is not at > > > its base, the process just can't be created. > > > > It's a common technique to rely on the fact that exports from kernel32 > > reside at the same address to use CreateRemoteThread calling LoadLibrary > > for remote code injection (this is not what Vitaliy's App is doing here > > but the assertions are the same). > > OK, fair enough. > > It's hard to implement that in Wine, because dlls are loaded using > dlopen() and there's no way to specify which address to load the dll at. I would say that the only relatively sane way to do it is to re-implement dlopen to support such functionality. The ELF tables that dlopen needs are documented. It doesn't seem like a trivial task to reimplement it, but it should be doable. Last time I checked, ELF tables are at least manageable to deal with given a rainy afternoon: http://hrabia.ibib.waw.pl/~winnie/qtbeheader.html Kuba

Aug. 8, 2005

Re: include/winsplp.h added (create "include/ddk/" ?)

by Detlef Riekenberg

Am Montag, den 08.08.2005, 11:32 +0100 schrieb Huw D M Davies: > > Changelog: > > - File "include/winsplp.h" added > As this is part of the ddk, it should probably go in > include/ddk/winsplp.h We do not have include/ddk/ yet. While comparing directories, some Files are present in mingw:include/ddk and in wine:include/ -- cut -- cfgmgr32.h ddkmapi.h ndistapi.h ntapi.h ntddcdrm.h ntddscsi.h ntddstor.h ntstatus.h -- cut -- Do we need to move them also? -- By By ... ... Detlef

Aug. 8, 2005