January 2003 - Wine-Devel - list.winehq.org

Re: Add filesytem type NTFS to config

by Tony Lambregts

Francois Gouget wrote: >On Tue, 14 Jan 2003, Tony Lambregts wrote: >[...] > > >>I am however curious what file system types the various implementations >>of windows will return. These are the ones I am aware of: >> >>HPFS (from OS2's High Performance File System) >>NTFS >>FAT Floppies and older (small) hard drives >>FAT32 >>CDFS (CD-ROMS) >> >>What else am I missing such as what does Novell or Samba return for one >>of thier mounted drives? What do DVD's report as thier file system on >>windows? What about zip drives and other removable drives? Any other >>thing I missed? >> >> > >AFAIK, read-write CDs use a special filesystem so they probably get >their own value. Samba probably reports whatever the share's underlying >filesystem is (at least if the server is a Windows machine). I suspect >zip drives just use what the user chooses, i.e. FAT or VFAT, maybe FAT32 >though that seems quite unnecessary given their limited size. > > > <bewilderment> err... ahem.. Oh come on... I appreciate you want to help but... How do I say this nicely... AFAICS you are just guessing. I can do that... but it is not a good way to build specs. I recall we got better specs on compile times. </bewilderment> -- Tony Lambregts

Jan. 15, 2003

Re: Add filesytem type NTFS to config

by Francois Gouget

On Tue, 14 Jan 2003, Tony Lambregts wrote: [...] > I am however curious what file system types the various implementations > of windows will return. These are the ones I am aware of: > > HPFS (from OS2's High Performance File System) > NTFS > FAT Floppies and older (small) hard drives > FAT32 > CDFS (CD-ROMS) > > What else am I missing such as what does Novell or Samba return for one > of thier mounted drives? What do DVD's report as thier file system on > windows? What about zip drives and other removable drives? Any other > thing I missed? AFAIK, read-write CDs use a special filesystem so they probably get their own value. Samba probably reports whatever the share's underlying filesystem is (at least if the server is a Windows machine). I suspect zip drives just use what the user chooses, i.e. FAT or VFAT, maybe FAT32 though that seems quite unnecessary given their limited size. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.

Jan. 15, 2003

Re: Add filesytem type NTFS to config

by Tony Lambregts

Andreas Mohr wrote: >On Mon, Jan 13, 2003 at 09:06:28PM -0700, Tony Lambregts wrote: > > >>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. >> >> >Hmm, I'm not sure whether we should increase the preexisting Filesystem >type mess by doing that. >I've hated the "win95", "vfat" etc. syntax almost from the beginning >(well, to be fair, I think I'm not too innocent when it comes to its >implementation, but at some time I just came to the conclusion >that it sucked) > >After all we're running on *Unix* file systems in many cases, >so "win95" does have no place here at all ! (neither does "vfat") >Not to mention that "win95" awfully collides with the "win95" winver... > >And adding yet another "incorrect" "ntfs" setting makes my head >want to go bonkey ;-) > Well windows programs don't know what to do with ext3 et al so we tell them what they need to hear. Hell that _IS_ what wine does in general. You can go bonkey about it all you want.<g> > >So I guess that it might be a good idea to think about how to solve this >configuration issue in a nicer way (and of course keep the old config >capabilities for about 2 years in order to have backward compatibility). > >We might even want to think of introducing "nameless" filesystem type >settings (instead of having "broken" conflicting and "wrong" FS type names). >And of course it seems as if we also need a separate FS *name* setting >in order to have Wine return "NTFS" instead of "FAT" in your case... > >So could we start a discussion about that perhaps ? > This is what I knew I was capable implementing. There was a thread about this when I took up the project and there was very little in it that made me want to do it another way. http://www.winehq.com/hypermail/wine-devel/2002/12/0833.html The thing is how many programs even care what file system is being used. At least one checks for CDFS and another checks for NTFS but I think that the vast majority couldn't care. This fixes the problem in a general way and I don't see an advantage to doing it in a more elegant way unless the need arises. I am however curious what file system types the various implementations of windows will return. These are the ones I am aware of: HPFS (from OS2's High Performance File System) NTFS FAT Floppies and older (small) hard drives FAT32 CDFS (CD-ROMS) What else am I missing such as what does Novell or Samba return for one of thier mounted drives? What do DVD's report as thier file system on windows? What about zip drives and other removable drives? Any other thing I missed? IMO The "right" fix is to have Wine query the file system and report back what the current directory's file system is capable of emulating. If it is a unix fs or similar then "NTFS" if its a FAT or VFAT then "FAT" or FAT32. This solution is what _I_ would like to see. However unless I get a better handle on how to achieve _and_ there is a real need I am not about to put the effort into implementing it. So there...<G> > > > >>Files changed: documentation/samples/config >> documnetation/configuring.sgml >> files/drive.c >> >> >Finally a beautifully implemented patch ! I hate having to clean up the >docu "after the fact". > Well I am on the documentation team. (Its where I started working on Wine BTW) > > > >>-;; DON'T use "unix" unless you intend to port programs using Winelib ! >>+;; - "ntfs" for ext2fs (some program need this to write files > 2GB) >> >> > ^^^^^^^^ urks ! a significant portion of unix FS users >don't even use ext2fs... > What would you want it to say?? Unix FS? a non exaustive list such as "ext2, ext3, Rieser eg:"? > > > >>+;; - "unix" DO NOT USE unless you intend to port programs using Winelib ! >> >> >Somehow that setting is also quite some pain... > Yes and we tell the application that it is a "FAT" drive currently but we deal with filenames in a case sensitive way. I am not about to "FIX" this though, unless the wine-lib guys come up with some specs about what it sould really do. -- Tony Lambregts

Jan. 15, 2003

Re: Two Simple Qs ?

by Dimitrie O. Paun

On January 14, 2003 04:31 pm, mohanad al-shayeb wrote: > As most of you know, the client needs to send some requests to > accomplish some special tasks which could not be handled by the client > itself. *What* are you talking about? -- Dimi.

Jan. 15, 2003

Re: Change Russian keyboard codepage (bug #1213)

by Dmitry Timoshkov

"Andreas Mohr" <andi(a)rhlx01.fht-esslingen.de> wrote: > change main Russian keyboard layout to use codepage 1251 instead of > 20866. See bug #1213. This is completely wrong. The bug reporter (and it seems you too) doesn't understand the difference between the code page which is used by the underlying system (and therefore by the keyboard driver) and the code page in which characters are sent to the aplication. -- Dmitry.

Jan. 14, 2003

Re: Help wanted: Implementing Wine dlls that need access to X11 commands.

by Robert North

Lionel Ulmer lionel.ulmer-at-free.fr |Wine Mailing Lists| wrote: >>I tried to make sense of this issue by referring to direct draw and open >>gl dlls, but just got more confused. > > > Do NOT look at DirectDraw or OpenGL for references as how it is done... The > current stuff there are mostly hacks to get the DLL separation to work (ie > for DDraw, it should go through a proper HAL and for OpenGL, it's not > documented how Windows did it, so we did our own hacks). > So, that explains why I got confused ;-) But I face a similar problem of dll separation. Infact anyone who has to access X11 features not exposed in x11drv will face dll separation problems. So, in hindsight, what advice would the DirectDraw or OpenGL developers give to someomne facing dll separation problems? Thanks -Rob.

Jan. 14, 2003

Two Simple Qs ?

by mohanad al-shayeb

Hi all, As most of you know, the client needs to send some requests to accomplish some special tasks which could not be handled by the client itself. Qs: 1. Why this could not by the client itself ? [may be it is better to save memory by centelizing the shared code in the server ] 2. How and when the server is loaded? Thanx for your help in advance, _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

Jan. 14, 2003

Re: Help wanted: Implementing Wine dlls that need access to X11 commands.

by Lionel Ulmer

> I tried to make sense of this issue by referring to direct draw and open > gl dlls, but just got more confused. Do NOT look at DirectDraw or OpenGL for references as how it is done... The current stuff there are mostly hacks to get the DLL separation to work (ie for DDraw, it should go through a proper HAL and for OpenGL, it's not documented how Windows did it, so we did our own hacks). Lionel -- Lionel Ulmer - http://www.bbrox.org/

Jan. 14, 2003

Re: Winedbg: Open Xterm when Controlling console no more available

by Eric POUECH

> When the starting application spawns off other processes and exec itself, > with the other spawned processes still running, and one of these > processes crashes, and winedbg is configured to work on the starting > console, winedbg starts, loads all dll, but then exits > immediate due to the missing console. can you be a bit more precise in the description. there are two possible cases : A/ either winedbg (in fact the debugging state of the debuggee) is set so that the debugger will only debug the debuggee and not its child processes B/ or winedbg is set up to debug the debuggee and all its children in case A, the situation you describe shouldn't be a problem, as the crash in the child should open another debugger with another console in case B, you may have problem because winedbg is likely not to like the second loading of a process (see my previous mail on winedbg). I'd rather see being a problem (perhaps because of overlapping DLLs...) does the loading dll message appears in the console as the first debugger or another one ? (you can turn on an option in the console which keeps the console opened after the program - here the debugger - has terminated) A+

Jan. 14, 2003

Re: Help wanted: Implementing Wine dlls that need access to X11 commands.

by Robert North

Thanks for your reply... It's really got me thinking, and unforunately, has caused more questions than answers. Luckily many of the questions may be useful to the wine developer community at large. Alexandre Julliard julliard-at-winehq.com |Wine Mailing Lists| wrote: > Robert North <7ownq0k402(a)sneakemail.com> writes: > > >> But note that this would reqire some patching to the x11drv >>dll to do the following >> 1. decode the messages. >> 2. enable the messages for a given window and display. >> But I'm assuming that changing the x11drv code could cause >>severe regressions to wine. >> I'm therefore assuming that it's good manners to avoid >>fiddling with x11drv code till the >> wintab driver implementation is known to be adequate. > > > I don't think it would necessarily cause regressions to simply add > handling for new events, since it shouldn't require changing the > existing event handling. But anyway writing a separate prototype first > is certainly a good idea. Hmm. Interesting.... This raises the issue of code separation: For any new wine dll, that needs new X11 calls, what code should go into x11drv dll and what into the new dll? I tried to make sense of this issue by referring to direct draw and open gl dlls, but just got more confused. The danger I see is that 90% of the wintab code, (and there could be quite a bit) might end up in x11drv, and 10% in wintab! This is especially likely if the policy is expose no X11 structs through the dll exports of x11drv. The issue of prototyping brings me to issues about how to release patches to wine, which I think I'll discuss in a future e-mail. > > >> Now, as it turns out, the methods to interrogate a wintab >>message queue are extremely similar to those to interrogate an X11 >>message queue. >> So that's +1 to giving wintab it's own X11 message >>queue. (Or possibly even one X11 msg queue per tablet context!). >> A simple X11<->wintab mapping can be implemented, and no >>additional queue data structs are needed in the wintab >>implementation. > > > I'm not convinced you can avoid managing an event queue for wintab > events; from a quick look at the spec I doubt you can simply map the > wintab functions to X11 queue functions. I'm about to have a final look at this, see if there is a clear mapping from X11 functions to wintab. More on this once I've completed my investigations. One mismatch is that wintab uses a fixed size message queue which can be defined as, as opposed to Wine or X11. (I'm assuming wine or X11 are either extremely large queues, or dynamically sized.). > > >> I think after all that complexity, that's +4 or more to >>X11 message queue implementation, and for wintab at least, avoid the >>wine message queue. > > > I agree you probably don't want to store wintab events in the Windows > message queue. But that doesn't mean you have to create your own X > connection and event loop, you can simply retrieve the events from the > normal X event loop and store them into the wintab queue. > Which is initially how I was going to implement it. The issue I came up against is how to inject the messages into the wintab queue? In wine, messages are currently injected into the for each thread, when GetMessage() is called. As wintab has it's own equivalent of GetMessage (named WTPacketsGet) the which seems to have direct access to the driver, it would look like wintab needs an alternative method to inject messages into it's queue. The only one I could come up with, in wine style, was to have a worker thread whose sole purpose is to inject messages into the wintab message queue. It might call GetMessage(), but all this would do is cause the wine message loop to insert a message into the wintab loop. The problem with this system is that it means that the queue has to be accessed by multiple threads, and therefore will lead to the usual thread synchronisation hassles. It was the fact that I could avoid synchronisation which lead me to think about building my own message loop.

Jan. 14, 2003