Re: S/GetCommState

--- Uwe Bonnes <[EMAIL PROTECTED]> wrote: > > "biffer" == biffer os <[EMAIL PROTECTED]> > writes: > > biffer> I have an application failing to > communicate at 19200, but > biffer> working at 57600. I've got about 40k of > logs of DCB dumps for a > biffer> case it fails (19200 b

Re: include/winsplp.h added

Am Sonntag, den 07.08.2005, 20:52 +0200 schrieb Detlef Riekenberg: > Changelog: > - File "include/winsplp.h" added Upps.. I did not remove an unneeded pair of: #if 1 #endif Is a resend needed? -- By By ... ... Detlef

Re: S/GetCommState

> "biffer" == biffer os <[EMAIL PROTECTED]> writes: biffer> I have an application failing to communicate at 19200, but biffer> working at 57600. I've got about 40k of logs of DCB dumps for a biffer> case it fails (19200 baud) and the case it succeeds (57600 biffer> baud). If

re: SMB for FUSE

Boaz wrote: *Is anybody familiar with this project?: SMB for FUSE It looks like a way to send users who need (Semi-transparent) UNC support. I was thinking of linking the .wine/dosdevices/unc to the above mount point.

SMB for FUSE

*Is anybody familiar with this project?: SMB for FUSE It looks like a way to send users who need (Semi-transparent) UNC support. I was thinking of linking the .wine/dosdevices/unc to the above mount point. ** Free Lif

Re: Inconsistency/bug with GetProcAddress

Mike McCormack wrote: You might be able to do it by staticly linking ntdll, kernel32 and user32 with wine-pthread/wine-kthread, and fixing the binary's address in memory, though that would probably be quite a bit of work. Mike This is not a bad Idea for other stuff as well one thing that

Re: Inconsistency/bug with GetProcAddress

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 e

Re: Inconsistency/bug with GetProcAddress

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

Re[2]: Inconsistency/bug with GetProcAddress

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

S/GetCommState

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 th

Re: Inconsistency/bug with GetProcAddress

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

Re: Inconsistency/bug with GetProcAddress

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 add

Re: Inconsistency/bug with GetProcAddress

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