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

Re: Inconsistency/bug with GetProcAddress

by Mike McCormack

Vitaliy Margolen wrote: >>You could "fix" it for a specific dll by reserving a memory area using >>the wine-preloader, but that would be a hack. > > I think you missing the point. I'm not talking about separate runs of wine. > I'm talking about one instance with parent & child processes. I would assume > that each dll that has been loaded when parent started will have the same entry > points for the child process as well. Because kernel32 is not unloadeble it's > exports should always be in the same place guaranteed until the next reboot. The child and parent processes are seperate runs of Wine. Each process loads and initializes each dll it uses on its own. The kernel makes no guarantees that a .so loaded in one process will be loaded at the same address in other processes. Thinking about it more, even if we reserved an area of memory using wine-preloader, we can't force dlopen to use it :/ Mike

Aug. 7, 2005

Re[2]: Inconsistency/bug with GetProcAddress

by Vitaliy Margolen

Saturday, August 6, 2005, 11:24:05 PM, Mike McCormack wrote: >> app1.exe: GetProcAddress(mKernel32, "LoadLibraryA") returns 0x404FCBCC >> app2.exe: GetProcAddress(mKernel32, "LoadLibraryA") returns 0x404FFBCC >> Is there are any reason why this is happening? Any ways to fix this? > Under Windows 98, you will always get the same address for the same > export from a dll, however that's not garanteed under Windows NT (or Wine). > The problem is that mmap does not garantee that any specific area of > memory will be available, so we can't always load a library at the same > address. > You could "fix" it for a specific dll by reserving a memory area using > the wine-preloader, but that would be a hack. I think you missing the point. I'm not talking about separate runs of wine. I'm talking about one instance with parent & child processes. I would assume that each dll that has been loaded when parent started will have the same entry points for the child process as well. Because kernel32 is not unloadeble it's exports should always be in the same place guaranteed until the next reboot. >> Unfortunately there are some programs that depend on address returned from >> GetProcAddress being the same in parent and child processes. > Which program depends upon that behaviour? It's possible that some old > Windows 98 copy protections schemes depend upon it, but they should work > if you change the version to win2k. For now it's all safedisc protected games. Vitaliy

Aug. 7, 2005

S/GetCommState

by biffer os

I have an application failing to communicate at 19200, but working at 57600. I've got about 40k of logs of DCB dumps for a case it fails (19200 baud) and the case it succeeds (57600 baud). If anyone wants I can post them here. But... Any particular reason why GetCommState doesn't first zero the passed structure, or set the size with sizeof()? If an app fails to zero its supplied DCB structure for a Get, and Windows *does* then code might work for Windows and fail for Wine? I don't have a windows box to test this though. It also strikes me that ignored DCB elements from a Set operation should be stored in a map associated with the underlying ports so the values can be retrieved on the next Get call and the 'Set' will appear to have succeeded, don't know if anyone would like to comment on that. -biff. ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

Aug. 7, 2005

Re: Inconsistency/bug with GetProcAddress

by Felix Nawothnig

Mike McCormack wrote: >> Yes it is. NTDLL and KERNEL32 are both mapped to always the same >> address on >=NT4 (in NT3 only NTDLL was at a fixed address however). > KERNEL32 and NTDLL are special cases because they are loaded first when > the address space is empty, and since the NT kernel has no address space > randomization they will consistently end up at the same address. > > As far as I know, there's no *garantee* of that, it just happens to be > that way. If you know otherwise, please point me to the relevant > documentation. :) 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). Felix

Aug. 7, 2005

Re: Inconsistency/bug with GetProcAddress

by Mike McCormack

Felix Nawothnig wrote: > Yes it is. NTDLL and KERNEL32 are both mapped to always the same address > on >=NT4 (in NT3 only NTDLL was at a fixed address however). KERNEL32 and NTDLL are special cases because they are loaded first when the address space is empty, and since the NT kernel has no address space randomization they will consistently end up at the same address. As far as I know, there's no *garantee* of that, it just happens to be that way. If you know otherwise, please point me to the relevant documentation. :) Mike

Aug. 7, 2005

Re: Inconsistency/bug with GetProcAddress

by Felix Nawothnig

Mike McCormack wrote: >> Is there are any reason why this is happening? Any ways to fix this? > Under Windows 98, you will always get the same address for the same > export from a dll, however that's not garanteed under Windows NT (or Wine). Yes it is. NTDLL and KERNEL32 are both mapped to always the same address on >=NT4 (in NT3 only NTDLL was at a fixed address however). Felix

Aug. 7, 2005

Re: Inconsistency/bug with GetProcAddress

by Mike McCormack

Vitaliy Margolen wrote: > app1.exe: GetProcAddress(mKernel32, "LoadLibraryA") returns 0x404FCBCC > app2.exe: GetProcAddress(mKernel32, "LoadLibraryA") returns 0x404FFBCC > Is there are any reason why this is happening? Any ways to fix this? Under Windows 98, you will always get the same address for the same export from a dll, however that's not garanteed under Windows NT (or Wine). The problem is that mmap does not garantee that any specific area of memory will be available, so we can't always load a library at the same address. You could "fix" it for a specific dll by reserving a memory area using the wine-preloader, but that would be a hack. > Unfortunately there are some programs that depend on address returned from > GetProcAddress being the same in parent and child processes. Which program depends upon that behaviour? It's possible that some old Windows 98 copy protections schemes depend upon it, but they should work if you change the version to win2k. Mike

Aug. 7, 2005

Inconsistency/bug with GetProcAddress

by Vitaliy Margolen

Found an interesting inconsistency with GetProcAddress between wine and native. On windows GetProcAddress of that's say "LoadLibraryA" exported from kernel32 always returns the same address, no matter which process it's called from. On wine it's different. That's say there are two programs app1.exe & app2.exe. app1.exe calls app2.exe (CreateProcess, etc.). Here is what I'm getting: app1.exe: GetProcAddress(mKernel32, "LoadLibraryA") returns 0x404FCBCC app2.exe: GetProcAddress(mKernel32, "LoadLibraryA") returns 0x404FFBCC I have tested this with more then two programs. All consecutive apps return same number as app2.exe. When any of this programs are ran under winedbg they all return same address as app2.exe. Running separate program doesn't change this behavior for parent-child processes. Both programs started in parallel will return the same address as app1.exe. What's more interesting, is that GetModuleHandleA("Kernel32") always returns the same handle. Is there are any reason why this is happening? Any ways to fix this? Unfortunately there are some programs that depend on address returned from GetProcAddress being the same in parent and child processes. -- Best regards, Vitaliy

Aug. 7, 2005

Re: test case demonstrating PeekMessage give up timeslices

by Felix Nawothnig

Oliver Mössinger wrote: > We changed our program to avoid the needless polling (only two PeekMessage are > needet then). We add also the PM_NOYIELD. This gives back the reaction of the > program if some other process consumes process time. But the speed is more > reduced than windows. So we actually got a real world app which depends (depended, but we don't want apps getting fixed for Wine, right?) on PeekMessage not giving away timeslices? Felix

Aug. 6, 2005

Re: compile error in current cvs

by Adam D. Moss

Jacek Caban wrote: > Hello. > > Stefan Leichter wrote: > >> Am Freitag, 5. August 2005 09:05 schrieben Sie: >> >> >> >> Hello Mike, >> >> after removing the link /usr/include/libxml >> >> my config.log has >> ac_cv_lib_xml2_xmlReadIO=no >> >> the patch fixes the problem with the missing header but compiling >> fails still with: >> >> >> > Attached patch is the correct solution. It fixes the compile problem, thanks. However, the other half of the problem is that WINE isn't detecting libxml2 'properly'. It should be using `xml2-config --cflags` etc, which puts the correct -I on the command-line without having to link the libxml2/libxml include directory to libxml. Note that a 'raw' libxml2 make-install doesn't make any such link -- some distros have presumably done it to help really old apps compile. Cheers, --Adam

Aug. 6, 2005