- Wine-Devel - list.winehq.org

TTYDRV woes :/
by Kye Lewis June 17, 2003

June 17, 2003

Heyas, Firstly, (for those of you who really care - or who even have a clue who I am.)... I'm back again, and ready for some wine action :) Anyway.... I'm having a bit of a problem with *running* wine stuff - more specifically TTYDRV... I'm getting lots of messages like "fixme:ttydrv:TTYDRV_CreateWindow (10045): stub" (obviously with different actual functions blah blah...) And I have no idea... And yes, before you ask, I am running this in X :) - I've tried CVS, i've tried compiling from a tar.gz, i've tried RPM's, and all seem to produce the same result. I'm using the latest nVidia drivers (from www.nvidia.com) if that would make any difference. Anyone else experienced this problem? Thanks, Kye Lewis ========================= kye(a)lewislan.id.au or, if that doesn't work: kyethespy(a)softhome.net will!

2 1

Re: TypeLib containment refcounting
by Alexandre Julliard June 17, 2003

June 17, 2003

Mike Hearn <mike(a)theoretic.com> writes: > ChangeLog: > When providing a TypeInfo object, inc/dec the refcount so that programs > don't call GetContainingTypeLib and crash as the container has been > destroyed. This doesn't look right, you increment the refcount on every GetTypeInfo but only decrement when the typeinfo object is destroyed. -- Alexandre Julliard julliard(a)winehq.com

5 10

RPMs and fake windows drive
by Mike Hearn June 17, 2003

June 17, 2003

Hi, How many of the RPMs up on the download section create a fake windows drive? If the answer is all of them, then we should probably remove the part of the howto that tells people to manually create their drive, as it causes confusion in newbies who don't understand why they are told in one place that they need it, and told in another that they don't. -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

1 0

vfat utf8 read problems
by olivier June 17, 2003

June 17, 2003

Hello, I'm using environment with gtk 2.x..x - gnome 2.x.x e.g. RedHat 9. gtk 2.x work (only) with charset UTF-8. I share documents on a vfat disk. To see correctly the file name with gnome, I must use the utf8 option in the fstab. But in this case, I can't see the files bigger than 8 chars with the Wine DialogFileOpen. Sorry for my poor English. Regards, Olivier the windebug messages: -------------------------------------------------- err:dosfs:DRIVE_ReadSuperblock Couldn't open device for drive I: ! (not available, symlink not valid or no permission) Perhaps you have not properly edited or created your Wine configuration file. This is (supposed to be) '.wine/config' err:dosfs:DRIVE_GetLabel Invalid or unreadable superblock on (I:). err:dosfs:DRIVE_ReadSuperblock Couldn't open device for drive I: ! (not available, symlink not valid or no permission) Perhaps you have not properly edited or created your Wine configuration file. This is (supposed to be) '.wine/config' Invalid or unreadable superblock on (I:). Maybe not FAT?

1 0

Re: Re: [DMUSIC07] more
by fenix＠club-internet.fr June 17, 2003

June 17, 2003

Hi >> PS: Christian with your last patch dmusic crash when WinMM is disabled (no >> sound drivers => DirectSoundCreate8 returns an error) >> >Ok, I will do more checks. :) >But how do you disable WinMM explicitely? By removing the driver >name in the config file? "Drivers" = "" >Bye, >Christian Regards, Raphael

1 0

Re: [DMUSIC07] more
by Christian Costa June 17, 2003

June 17, 2003

> Message du 17/06/03 02:30 > De : Raphaël Junqueira <fenix(a)club-internet.fr> > A : wine-patches(a)winehq.com > Copie à : Christian Costa <titan.costa(a)wanadoo.fr>, Rok Mandeljc <rok.mandeljc(a)gimb.org> > Objet : [DMUSIC07] more > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Changelog: > - add IDirectMusicContainer support in > IDirectMusicLoader8Impl::LoadObjectFromFile > - don't use IDirectMusicSegment*Impl when IDirectMusicSegment*8Impl can be > used instead (avoir code duplication) > > Regards, > Raphael > > PS: Christian with your last patch dmusic crash when WinMM is disabled (no > sound drivers => DirectSoundCreate8 returns an error) > Ok, I will do more checks. But how do you disable WinMM explicitely? By removing the driver name in the config file? Bye, Christian

1 0

Not to bring up a (probably) long-dead subject, but...
by Dustin Navea June 16, 2003

June 16, 2003

I was looking thru the archives of WWN and found this: Tony Lambregts submitted a patch that added a new filesystem type: Some program (VirtualDub) checks the fsname returned by GetVolumeInformation, to find the name of the file system, when it needs to write files that are larger than 2GB. It refuses to create the file when we return FAT but will successfully write the file when NTSF is returned. Change Log: add configuration option to report NTFS as the file system type for a drive. Mike Hearn thought it might just be a good idea to always return NTFS if asked. Andreas Mohr disagreed and felt the whole concept was flawed: -snip- >From there the discussion delved into exactly what type of filesystems Windows knows about. There was some speculation on exactly how and when they differ. For example, what type of filesystem is reported on DVD's? Tony summed it up: So we The way I see it Windows knows about the following file systems. CDFS, FAT, FAT23, NTFS and HPFS. HPFS is irrelevent. CDFS covers all CD like Media. FAT will deal with all drives less that 2 GB. NTFS can be used with drive over 10MB. FAT32 can be ignored. -end- I just figured that you should know that the best bet would be to have wine return vfat instead of fat or ntfs, as fat == fat16 which has a 2 GB limit, while vfat == fat32 which has a 4 GB limit.. This is actually referenced on microsoft's website (although I couldnt give you the exact address) and can also be found on winnetmag.com thru google.. As always I'm not subscribed to the list, so please CC me with any replies.. __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com

1 0

wIntegrate on Linux: continued....
by cartel＠cryptocracy.hn.org June 16, 2003

June 16, 2003

Hey All, Still working on getting wIntegrate running under Linux. I'm running into problems running the program either in builtin mode or with native dlls. Here are the dlloverrides that I'm trying: -dll WSOCK32.DLL=native -dll WS2_32.DLL=native -dll NETAPI32.DLL=native -dll ADVAPI32.DLL=native -dll OLEAUT32.DLL=native -dll OLEPRO32.DLL=native -dll OLE32.DLL=native -dll RPCRT4.DLL=native -dll COMCTL32.DLL=native -dll COMDLG32.DLL=native -dll SHLWAPI.DLL=native -dll IMM32.DLL=native -dll IMM32.DLL=native Running with -debugmsg +fixme, I get the following interesting messages: fixme:file:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:file:DeviceIoControl Unimplemented control 256 for VxD device NWLINK Once the app starts and I attempt to create a connection, I get this feedback: [Connecting to 127.0.0.1...] [Windows Sockets error 183] Am I correct in interpreting this (net helpmsg 183) in that wine is attempting to create a pipe that already exists? If I take the other approach and run wInteg with no dll overrides (builtin mode), i get the following messages fixme:ole:CoRegisterMessageFilter stub fixme:ole:CFProxy_QueryInterface Unhandled interface: {00000126-0000-0000-c000-000000000046}fixme:ole:CFProxy_QueryInterface Unhandled interface: {00020400-0000-0000-c000-000000000046}fixme:ole:PIPE_GetNewPipeBuf Could not open named pipe \\.\pipe\WINE_OLE_StubMgr_00000013, le is 2err:ole:StdMarshalImpl_UnmarshalInterface Failed to get an rpc channel buffer for {00000001-0000-0000-c000-000000000046}fixme:ole:CoUnmarshalInterface Failed to Unmarshal the interface, 80004005? fixme:ole:CoCreateInstance no classfactory created for CLSID {4fbf4bd9-a454-11d1-ab39-00a024709830}, hres is 0x80004005 This is what prompted me to try running the app in native mode (since this message goes away if im using native ole dlls.) When running in builtin mode and creating a connection, wInteg sits on the [Connecting to 127.0.0.1] message. But netstat -nap reports: tcp 12 0 127.0.0.1:1220 127.0.0.1:23 ESTABLISHED 8079/wine Of note is that wInteg uses an ActiveX control called wWinSock.ocx. This is in keeping with its modular approach to transports (having plugins for PicLan, Novell etc). Correct me if I'm wrong, but from the error messages concerning OLE, I'm thinking that my problem lies with an incomplete implementation of OLE (or at least ActiveX controls) in Wine. Specifically, I beleive the actual problem is that the wWinSock object is not receiving a signal from Wine that tells it that the connection has been opened. Anybody have any further suggestions/comments? Thanks Tom

2 1

Re: Resend PATCH - setupapi add support for both Windows and Unix style line endings to setupapi parser
by Alexandre Julliard June 16, 2003

June 16, 2003

Steven Edwards <Steven_Ed4153(a)yahoo.com> writes: > Does this need to be changed or is there something else wrong with > this patch? This shouldn't be needed AFAICT, \r should already be treated as a space character. There may be another bug here though, do you have an example file showing the problem? -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Resend PATCH - setupapi add support for both Windows and Unix style line endings to setupapi parser
by Todd Vierling June 16, 2003

June 16, 2003

On Mon, 16 Jun 2003, Steven Edwards wrote: : Does this need to be changed or is there something else wrong with this : patch? : - return (ptr >= parser->end || *ptr == CONTROL_Z || *ptr == '\n'); : + return (ptr >= parser->end || *ptr == CONTROL_Z || *ptr == '\n' || : (*ptr == '\r'&& *(ptr + 1) == '\n')); Could overrun the buffer by looking one char too far if the last character of the file is '\r'. -- -- Todd Vierling <tv(a)pobox.com>

1 0