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

Re: include/winsplp.h added

by Huw D M Davies

On Sun, Aug 07, 2005 at 08:52:08PM +0200, Detlef Riekenberg wrote: > > Changelog: > - File "include/winsplp.h" added > As this is part of the ddk, it should probably go in include/ddk/winsplp.h Huw. -- Huw Davies huw(a)codeweavers.com

Aug. 8, 2005

Re: MSXML3: initial implementation based on libxml2

by Saulius Krasuckas

* On Mon, 8 Aug 2005, Saulius Krasuckas wrote: > > Ok folks, but my hands are off. I just reported for everybody to know. > I am going to upgrade libxml2 packages (to v2.6.16). Heh.. I opened this message to discard it. That Ctrl-C combination is so near to a Ctrl-X. Sorry for a noise, ignore it, please. I see Mike just has implemented this functionality.

Aug. 8, 2005

Re: MSXML3: initial implementation based on libxml2

by Saulius Krasuckas

* On Thu, 4 Aug 2005, Mike McCormack wrote: > > If you don't use xmlReadIO, then you could use xmlReadMemory I guess. > The whole file would need to be read into memory first. * On Thu, 4 Aug 2005, Dmitry Timoshkov wrote: > > Or just mmap'ed. That could be a reasonable workaround. Ok folks, but my hands are off. I just reported for everybody to know. I am going to upgrade libxml2 packages (to v2.6.16). If no any additional configure checks are needed, then fine. But that's strange, as user has to do hard work to discover his libxml2 is too old. So I still think some version checks or so are needed to be implemented.

Aug. 8, 2005

Re: S/GetCommState

by biffer os

--- Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: > >>>>> "biffer" == biffer os <bifferos(a)yahoo.co.uk> > 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 anyone wants I can post them > here. > > biffer> But... > > biffer> Any particular reason why GetCommState > doesn't first zero the > biffer> passed structure, or set the size with > sizeof()? > > biffer> If an app fails to zero its supplied DCB > structure for a Get, > biffer> and Windows *does* then code might work > for Windows and fail for > biffer> Wine? I don't have a windows box to > test this though. > > biffer> It also strikes me that ignored DCB > elements from a Set > biffer> operation should be stored in a map > associated with the > biffer> underlying ports so the values can be > retrieved on the next Get > biffer> call and the 'Set' will appear to have > succeeded, don't know if > biffer> anyone would like to comment on that. > > What happens if you correct what you suspect an > error? Does the application > succeed? No such luck :-( I did something like this: comm.c: ------8<---------------8<---------------8<--------- DCB g_dcb; int g_dcb_set = 0; BOOL WINAPI SetCommState() { memcpy( &g_dcb, lpdcb, sizeof( DCB ) ); g_dcb_set = 1; ----- wine stuff ----- } BOOL WINAPI GetCommState( { if (g_dcb_set) { memcpy( lpdcb, &g_dcb, sizeof( DCB ) ); } else { memset( lpdcb, 0, sizeof( DCB ) ); } ---- wine stuff ----- } ------8<---------------8<---------------8<--------- .. but I'm really fishing here. In fact this isn't a big deal, because choosing the correct baud rate makes it work, but I was just curious. On the face of it, it seemed an odd way to implement the two functions, but if it works for the majority like it is all well and good. cheers, -biff. ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

Aug. 7, 2005

Re: include/winsplp.h added

by Detlef Riekenberg

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

Aug. 7, 2005

Re: S/GetCommState

by Uwe Bonnes

>>>>> "biffer" == biffer os <bifferos(a)yahoo.co.uk> 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 anyone wants I can post them here. biffer> But... biffer> Any particular reason why GetCommState doesn't first zero the biffer> passed structure, or set the size with sizeof()? biffer> If an app fails to zero its supplied DCB structure for a Get, biffer> and Windows *does* then code might work for Windows and fail for biffer> Wine? I don't have a windows box to test this though. biffer> It also strikes me that ignored DCB elements from a Set biffer> operation should be stored in a map associated with the biffer> underlying ports so the values can be retrieved on the next Get biffer> call and the 'Set' will appear to have succeeded, don't know if biffer> anyone would like to comment on that. What happens if you correct what you suspect an error? Does the application succeed? -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Aug. 7, 2005

SMB for FUSE

by Boaz Harrosh

*Is anybody familiar with this project?: SMB for FUSE <http://freshmeat.net/projects/fusesmb/?branch_id=45268&release_id=203494> 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 Life Boaz *

Aug. 7, 2005

re: SMB for FUSE

by Dan Kegel

Boaz wrote: > *Is anybody familiar with this project?: > SMB for FUSE > <http://freshmeat.net/projects/fusesmb/?branch_id=45268&release_id=203494> > > 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. In general, I like the idea of use FUSE from within other projects. e.g. somebody's doing it with KDE; see http://kde.ground.cz/tiki-index.php?page=KIO+Fuse+Gateway But FUSE is not yet part of the standard kernel.org kernels; see http://kerneltrap.org/node/5329 for recent comments on this. It's kind of a shame that there isn't a way to use FUSE without a kernel portion. One ought to be able to run it as a daemon or something, at least. And that would let you use it with Solaris or BSD, not just Linux. Anyway, since FUSE is not widely used or very portable, Wine should be very careful about relying on it. There be dragons here. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

Aug. 7, 2005

Re: Inconsistency/bug with GetProcAddress

by Boaz Harrosh

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 comes to mined is winlib (self contained package). Though I admit I am not that brave. What would you do? a configure switch with alternate make targets. Could you think of a way that would get accepted into the tree and be regularly tested for? Free Life Boaz

Aug. 7, 2005

Re: Inconsistency/bug with GetProcAddress

by Mike McCormack

> 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. 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

Aug. 7, 2005