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

Re: Wineconf update, RFC re remote participation

by Ivan Leo Murray-Smith

> One thing I would like to do is to stream audio This would be a regression, the last wineconf had a video stream. Ivan.

Jan. 7, 2004

Re: winewrap: fix wrapper linking

by Richard Cohen

Dimitrie O. Paun wrote: > Richard, > > You patch from Nov 28: > http://www.winehq.org/hypermail/wine-cvs/2003/11/0299.html > says (among other things): > "Compiling with -lwine needs to use the given -L paths." > > In other words, it adds all the -Lxxx libs to the linking step > for the wrapper. I see no reason to do so. At the Windows/DLL > level, we only link with kernel32, and we know exactly where > it is: in DLLDIR. At the Linux/ELF level, we only link with > -lwine, and similarly, we know it resides in LIBDIR. Those libraries only reside there after Wine has been installed. winegcc needs to be able to build programs/* etc. from inside the tree Anyway, it looks like the wrapper will be going away soon ... Richard.

Jan. 7, 2004

Notes on implementing mscms.dll - for anybody who's interested in digital colour management

by Mike McCormack

Hi, For whoever is interested in running Phase One's Capture One software (http://www.phaseone.com/) on Wine, you'll need mscms.dll for Colour Management. Unfortunately Wine has no implementation of it yet. I had a quick look into what is needed to implement mscms.dll (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/icm/icmsta…) It appears the functionality of mscms.dll is mostly defined by the International Color consortium (http://www.color.org) and a free implementation exists(http://www.littlecms.com/, and is available as a (shared?) library on many distros. I think it's feasable to interface that library to an mscms.dll implemented in Wine. I've created a stub library incase anybody wants to have a go at it... mail me if you're interested in working on it. Mike TOPSRCDIR = @top_srcdir@ TOPOBJDIR = ../.. SRCDIR = @srcdir@ VPATH = @srcdir@ MODULE = mscms.dll IMPORTS = user32 advapi32 kernel32 ntdll EXTRALIBS = $(LIBUNICODE) $(LIBUUID) EXTRADEFS = -DCOM_NO_WINDOWS_H C_SRCS = \ mscms.c @MAKE_DLL_RULES@ ### Dependencies: /* * Copyright (C) 2004 Mike McCormack for Codeweavers * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2.1 of the License, or (at your option) any later version. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this library; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include <stdarg.h> #include "windef.h" #include "winbase.h" #include "wingdi.h" #include "icm.h" #include "wine/debug.h" WINE_DEFAULT_DEBUG_CHANNEL(mscms); BOOL WINAPI SetColorProfileElementSize( HPROFILE hProfile, TAGTYPE tag, DWORD cbSize) { FIXME("%p %08lx %ld\n", hProfile, tag, cbSize); return TRUE; } BOOL WINAPI GetColorProfileElement( HPROFILE hProfile, TAGTYPE tag, DWORD dwOffset, DWORD *pcbSize, PVOID pBuffer, PBOOL pbReference) { FIXME("\n"); return TRUE; } BOOL WINAPI GetCountColorProfileElements( HPROFILE hProfile, PDWORD pnCount) { FIXME("\n"); return TRUE; } BOOL WINAPI SetColorProfileElement( HPROFILE hProfile, TAGTYPE tag, DWORD dwOffset, PDWORD pcbSize, PVOID pBuffer) { FIXME("\n"); return TRUE; } BOOL WINAPI DeleteColorTransform( HTRANSFORM hColorTransform ) { FIXME("\n"); return TRUE; } BOOL WINAPI CloseColorProfile( HPROFILE hProfile ) { FIXME("\n"); return TRUE; } BOOL WINAPI GetColorDirectoryA( LPCSTR pMachineName, LPSTR pBuffer, PDWORD pdwSize ) { FIXME("\n"); return TRUE; } BOOL WINAPI TranslateBitmapBits( HTRANSFORM hColorTransform, PVOID pSrcBits, BMFORMAT bmInput, DWORD dwWidth, DWORD dwHeight, DWORD dwInputStride, PVOID pDestBits, BMFORMAT bmOutput, DWORD dwOutputStride, PBMCALLBACKFN pfnCallback, ULONG ulCallbackData) { FIXME("\n"); return TRUE; } HTRANSFORM WINAPI CreateMultiProfileTransform( PHPROFILE pahProfiles, DWORD nProfiles, DWORD *padwIntent, DWORD nIntents, DWORD dwFlags, DWORD indexPreferredCMM ) { FIXME("\n"); return NULL; } HPROFILE WINAPI OpenColorProfileA( PPROFILE pProfile, DWORD dwDesiredAccess, DWORD dwShareMode, DWORD dwCreationMode) { FIXME("\n"); return NULL; } BOOL WINAPI GetColorProfileElementTag( HPROFILE hProfile, DWORD dwIndex, PTAGTYPE pTag ) { FIXME("\n"); return TRUE; } BOOL WINAPI GetColorProfileHeader( HPROFILE hProfile, PPROFILEHEADER pHeader ) { FIXME("\n"); return TRUE; } @ stdcall SetColorProfileElementSize(ptr long long) @ stdcall GetCountColorProfileElements(ptr ptr) @ stdcall SetColorProfileElement(ptr ptr long ptr ptr) @ stdcall GetColorProfileElement(ptr ptr long ptr ptr ptr) @ stdcall DeleteColorTransform(ptr) @ stdcall CloseColorProfile(ptr) @ stdcall GetColorDirectoryA(str ptr ptr) @ stdcall TranslateBitmapBits(ptr ptr ptr long long long ptr ptr long ptr long) @ stdcall CreateMultiProfileTransform(ptr long ptr long long long) @ stdcall OpenColorProfileA(ptr long long long) @ stdcall GetColorProfileElementTag() @ stdcall GetColorProfileHeader(ptr ptr) /* * Copyright (C) the Wine project * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2.1 of the License, or (at your option) any later version. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this library; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #ifndef __WINE_ICM_H #define __WINE_ICM_H typedef HANDLE HPROFILE; typedef HPROFILE *PHPROFILE; typedef HANDLE HTRANSFORM; typedef DWORD TAGTYPE; typedef TAGTYPE *PTAGTYPE,*LPTAGTYPE; typedef enum { BM_x555RGB = 0x00, BM_565RGB = 0x01, BM_RGBTRIPLETS = 0x02, BM_BGRTRIPLETS = 0x04, BM_xRGBQUADS = 0x08, BM_10b_RGB = 0x09, BM_16b_RGB = 0x0a, BM_xBGRQUADS = 0x10, BM_CMYKQUADS = 0x20, BM_x555XYZ = 0x101, BM_x555Yxz, BM_x555Lab, BM_x555G3CH, BM_XYZTRIPLETS = 0x201, BM_YxyTRIPLETS, BM_LabTRIPLETS, BM_G3CHTRIPLETS, BM_5CHANNEL, BM_6CHANNEL, BM_7CHANNEL, BM_8CHANNEL, BM_GRAY, BM_xXYZQUADS = 0x301, BM_xYxyQUADS, BM_xLabQUADS, BM_xG3CHQUADS, BM_KYMCQUADS, BM_10b_XYZ = 0x401, BM_10b_Yxy, BM_10b_Lab, BM_10b_G3CH, BM_NAMED_INDEX, BM_16b_XYZ = 0x501, BM_16b_Yxy, BM_16b_Lab, BM_16b_G3CH, BM_16b_GRAY, } BMFORMAT; typedef BOOL WINAPI (*PBMCALLBACKFN)(ULONG,ULONG,ULONG); typedef PBMCALLBACKFN LPPBMCALLBACKFN; typedef struct tagPROFILEHEADER { DWORD phSize; DWORD phCMMType; DWORD phVersion; DWORD phClass; DWORD phDataColorSpace; DWORD phConnectionSpace; DWORD phDateTime[3]; DWORD phSignature; DWORD phPlatform; DWORD phProfileFlags; DWORD phManufacturer; DWORD phModel; DWORD phAttributes; DWORD phRenderingIntent; CIEXYZ phIlluminant; DWORD phCreator; BYTE phReserved[44]; } PROFILEHEADER; typedef PROFILEHEADER *PPROFILEHEADER,*LPPROFILEHEADER; typedef struct tagPROFILE { DWORD dwType; PVOID pProfileData; DWORD cbDataSize; } PROFILE; typedef PROFILE *PPROFILE,*LPPROFILE; #endif

Jan. 7, 2004

Re: Comment on new file implementation

by Juan Lang

Eric, the sooner the better as far as I'm concerned. In my quick read of the patch I didn't see any translating from the Win32 namespace to the NT namespace; do you plan to do anything there? To pick a (bad) example, the name \\server\share\file is valid in the Win32 namespace, but not in the NT namespace; it must be translated to \??\UNC\server\share\file Since you mentioned SMB, I will too: don't worry too much, it's currently broken anyway. As long as the code's cleaner it should be easier to fix (and this looks much cleaner). --Juan __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

Jan. 7, 2004

Re: my patch is in neverland :-)

by Marcus Meissner

On Tue, Jan 06, 2004 at 07:27:36PM -0800, Duane Clark wrote: > Tom wrote: > >Hi, > > > >I sent a 100k Status Update patch and its been > >around 18 hours now and its still not showed up. > >Is the moderator on strike? :)) > > It probably was simply inadvertently deleted. I sift through an awful > lot of spam (>100 per day per list, down from 150-200 at the end of last > year), and it is certainly possible that I missed it. > > At one point, Jeremy was talking about implementing some Mailman spam > filtering, and I would sure like to see that happen. I am using a handmade filter script on a list I moderate, which just bounces anything with X-Spam: yes. /etc/alias file entry: <list>: "|dropspam /etc/mail/smrsh/wrapper post <list>" /etc/mail/smrsh/wrapper is the path to the mailman wrapper script. dropspam is: #!/usr/bin/perl $inheader = 1; $header = ""; while (<STDIN>) { if ($inheader && /^$/) { open(OUTPUT,"|" . join(" ",@ARGV)) || die "cannot open output: $!"; print OUTPUT $header; print OUTPUT $_; $inheader = 0; next; } if (!$inheader) { print OUTPUT $_; next; } if (/^x-spam: yes$/i) { exit 67; } $header .= $_; } close(OUTPUT); exit 0; (It slurps in the header, if it does not like it, it exit 67; , otherwise it passes the header and the mail one.) You could also adapt it to bounce everything with SpamScore >= 10 or similar. Ciao, Marcus

Jan. 7, 2004

Re: Comment on new file implementation

by Dimitrie O. Paun

On January 6, 2004 04:25 pm, Eric Pouech wrote: > Every volume on each available volume (partition on a physical disk) on > the system will be listed in ${WINEPREFIX}/device directory. Hi Eric, I have to admit I haven't read the patch, but the idea looks good. I personally like the use of the filesystem for this sort of thing (I'm a one-value-per-file kinda guy, and I'd put a lot more into the filesystem, generally speaking, if I had my way :)). Here are a few random thoughts on it: -- it seems we're duplicating a bit stuff like udev/proc, but we can't rely on them, so I guess it's not a big deal. However, somehow we should keep in mind that udev will allow for hotplugging disks etc, and we should keep an open eye to integrate with that in the future. -- I assume ${WINEPREFIX}/{dos,}device point somewhere in the user's home dir (~/...), right? -- I hope Alexandre likes the idea, and we can get it in sooner, rather then later (before WineConf? :)) Cool stuff. -- Dimi.

Jan. 7, 2004

Re: #pre5 - comdlg32 MS_VC + PSDK porting

by Dimitrie O. Paun

On January 6, 2004 03:17 pm, Alexandre Julliard wrote: > Building with MSVC headers will require changing the code to use > macros everywhere we reference the nameless structs. Man, oh man, this will greatly uglify things. Clearly, there is no perfect solution to this problem, we'll have to make a tradeoff. Now, I have tested nameless structs with gcc 2.96 (which comes with RedHat 7.x), and they work just fine. I haven't tested with any of the 2.95.x, but even if they don't work, it's been more than 2.5 years since 3.0 hit the streets. In other words, by now most people have upgraded from 2.95.x. Apparently Dave Miller claims 2.95.x is still desirable on Sparc, but that's not that interesting for us. On the other hand, being able to compile Wine with the PSDK brings real value. We can not look back forever, 2.5 years is long enough. For people who are hell bent to use 2.95, they can install a newer gcc version in a different directory, and use that to build wine. It's unpleasant, but not a big deal. -- Dimi.

Jan. 7, 2004

Re: widl patch

by Alexandre Julliard

Ove Kaaven <ovek(a)arcticnet.no> writes: > You can just add it to the list of these occurrences I keep in the > "ident" rule (around line 494 in parser.y after patching). I see, nice hack <g> I've made the change and put the patch in, thanks. -- Alexandre Julliard julliard(a)winehq.com

Jan. 7, 2004

Re: widl patch

by Ove Kaaven

tir, 06.01.2004 kl. 23.16 skrev Alexandre Julliard: > Ove Kaaven <ovek(a)arcticnet.no> writes: > > > Log: > > Added rules to parse library, coclass, dispinterface, and module > > definitions, and a number of attributes, and cleaned up a few things. > > Started on a typelib generation framework. > > This breaks compilation of shobjidl.idl, because it makes 'id' a > keyword but there are some functions arguments named 'id' in that > file. We could of course change the names, but the Windows version of > that file uses the same names so it looks like an incompatibility > with MIDL. You can just add it to the list of these occurrences I keep in the "ident" rule (around line 494 in parser.y after patching). Or I can resubmit with it added if you like. (And I realize such a list isn't particularly clean, but it's kinda difficult to have an independent namespace for attributes without making the parser a lot more complex.)

Jan. 7, 2004

[Fwd: [unixODBC-DEV] - UnixODBC, Wine, Crystal Report -- would appreciate insight]

by Dan Kegel

Can somebody have a look at this? Thanks, Dan -------- Original Message -------- Subject: [unixODBC-DEV] - UnixODBC, Wine, Crystal Report -- would appreciate insight Date: Tue, 06 Jan 2004 15:07:11 -0500 From: Aurelien Marchand <aurelien.marchand(a)researchcapital.com> Reply-To: unixodbc-dev(a)unixodbc.org To: unixodbc-dev(a)easysoft.com Hi, I am a bit confused as to who I should send this email. Please let me know if this is the wrong place. I am really, really close to making the whole thing work (I'll show in a minute why I think that) but I'm stomped and need some help. I've dumped my WinNT workstation and replaced it with Linux. So far, I can do exactly everything I was able to do (except updating my calendar on the Exchange server used where I work), minus using Crystal Report. I have installed it using CodeWeavers' CrossOver Office and it installed without even a hiccup. I've also installed unixODBC and tested the odbc.ini configuration using isql. It works great when I try to connect to the company's AS400 database. The default library is set to my username and I can query other libraries using the dot (.) as a separator (e.g: SELECT * from OTHERLIB.OTHERTABLE). So far so good: UnixODBC works perfectly to talk to IBM's AS400. Now I need to tell Crystal which drivers to use. I've read on the web that Crystal is not a very good student and thus ignores Windows' ODBC.ini settings but checks what's in the registry. I've also come to understand I must set ODBC.dll = "builtin, native" in my Wine's config file so that it will try to use whatever is set for LIB_ODBC_DRIVER_MANAGER env variable for Windows' ODBC connections. I've come to that point: my system.reg or my user.reg contain one ODBC setting (the same name found on /etc/odbc.ini and ~/.odbc.ini). My wine config file uses "builtin, native" for it's ODBC setting and my ~/.odbc.ini contains proper DSN settings (since I can query from the console using isql). The best part is, when I start Crystal Report, and select ODBC sources, I have in the dropdown that appears all the entries I've put in my ~/.odbc.ini file. As I said earlier, great strides indeed. Now the last missing piece is that it seems Crystal using Wine and unixODBC cannot login properly and retrieve the table list. It just hangs when I expand the "+" box beside a DSN entry. I've enabled sql log (in /etc/odbcinst.ini) but I can't find really relevant information. Let me know if you want to see it. So now I'm stuck. Any ideas on how I can make it work? Note: I've tried to Crystal's DB2 ODBC drivers and also with IBM DB2 ODBC drivers (both for Windows) - although it shouldn't make a difference. Thanks, Aurelien Marchand

Jan. 7, 2004

Re: my patch is in neverland :-)

by Duane Clark

Tom wrote: > Hi, > > I sent a 100k Status Update patch and its been > around 18 hours now and its still not showed up. > Is the moderator on strike? :)) It probably was simply inadvertently deleted. I sift through an awful lot of spam (>100 per day per list, down from 150-200 at the end of last year), and it is certainly possible that I missed it. At one point, Jeremy was talking about implementing some Mailman spam filtering, and I would sure like to see that happen.

Jan. 7, 2004

dll name length (was: Windows dll replacement with Linux library)

by Dan Timis

I finally figured out what my problem was. If the name of the library is "USBUtils" it works, if it is "USBDeviceUtils" it doesn't. Actually the max length I can use is 11 characters. That is probably 15 characters including ".dll" In my config file all filesystems are "win95" The version is "nt40" Is there any way to configure wine to support longer names? Thanks, Dan Timis Sounds Just Right, Inc. > From: Dan Timis <timis(a)museresearch.com> > > On Saturday, January 3, 2004, at 01:07 AM, Dimitrie O. Paun wrote: > >>> I'm new to this so please bear with me. >>> >>> First I edited the Makefile and replaced gcc with winegcc. When I >>> run >>> "make" I get this error when it tries to link: >>> >>> could not open .def file for kernel32 >>> Error: /usr/bin/winebuild failed. >>> Error: /usr/bin/winewrap failed. >> >> Can you please send me the command that generates this? Just to make >> sure that we're on the same page, use winegcc (for now) just for >> building >> the test application, not the DLL. >> >>> Then, I ran ./configure --help and it says that you can use the "CC" >>> var to specify the compiler. I started from scratch, set "export >>> CC=winegcc", then ran configure again. The output looks like this: >>> >>> checking whether make sets {$MAKE}... yes >>> checking for gcc... winegcc >>> checking for C compiler default output... configure: error: C >>> compiler >>> cannot create executables >> >> This is very odd. winegcc should be configure friendly (it does work >> for >> wxWindows BTW). Hey, what version of Wine are you using? I do hope >> it's >> the latest CVS... > > I am using an older version 20030618. It's hard to change, other > people depend on this particular version and I would have to upgrade > several machines. I could try on one machine, but... > > A colleague who dealt with similar problems in the past helped me. He > added this to Makefile.in > > # generate a .def "import library" file from the spec file > $(usbutils_dll_DEF): $(usbutils_dll_SPEC_SRCS) Makefile.in > $(WINEBUILD) --def $(usbutils_dll_SPEC_SRCS) > $(usbutils_dll_DEF) > > Both the .dll.so and the .def go in /usr/lib/wine/wine. Earlier I > noticed that there was no .def file. That was our clue. > > For the test we added the library to the list of wine dlls in > Makefile.in. > > It's working. > > I'm still a little confused, but I understand much more than a week > ago. Thanks. > > Dan Timis > Muse Research, Inc. >

Jan. 7, 2004

Re: Check for null ptr return from RegEnumValue

by Alexandre Julliard

Mike Hearn <mike(a)theoretic.com> writes: > This was crashing IE setup. Dunno where the regression came from, but I > think null returns like this are legal, so we should check for it. data is passed by value, it cannot possibly be set to null by RegEnumValue. -- Alexandre Julliard julliard(a)winehq.com

Jan. 7, 2004

my patch is in neverland :-)

by Tom

Hi, I sent a 100k Status Update patch and its been around 18 hours now and its still not showed up. Is the moderator on strike? :)) Tom

Jan. 7, 2004

Re: PATCH: Editing DLL overrides in winecfg

by Alexandre Julliard

Robert van Herk <robert(a)robertvanherk.nl> writes: > This is a patch that adds a tabsheet to winecfg, that allows the user > to change the dll overrides; both globally and per app. I put this in, but note that there are more possibilities that just builtin or native that will have to be supported too. Altogether there are five possible combinations: "builtin", "native", "builtin,native", "native,builtin", "". -- Alexandre Julliard julliard(a)winehq.com

Jan. 7, 2004

Re: Don't let cabinet Extract() crash IE

by Stefan Leichter

Am Dienstag, 6. Januar 2004 19:10 schrieb Mike Hearn: > On Tue, 2004-01-06 at 17:59, Stefan Leichter wrote: > > No, I didn't, please do it :) > Hi Mike does the patch work for you, or does it break your installer again? Bye Stefan

Jan. 6, 2004

Re: widl patch

by Alexandre Julliard

Ove Kaaven <ovek(a)arcticnet.no> writes: > Log: > Added rules to parse library, coclass, dispinterface, and module > definitions, and a number of attributes, and cleaned up a few things. > Started on a typelib generation framework. This breaks compilation of shobjidl.idl, because it makes 'id' a keyword but there are some functions arguments named 'id' in that file. We could of course change the names, but the Windows version of that file uses the same names so it looks like an incompatibility with MIDL. -- Alexandre Julliard julliard(a)winehq.com

Jan. 6, 2004

Re: Will DCOM98 be pulled?

by Tom

Ivan Leo Murray-Smith wrote: >>can somebody with legal knowledge check the EULA and see if we >>are allowed to redistribute this file? > > No legal knowledge needed, the EULA at > http://www.microsoft.com/com/dcom/dcom98/eula.asp > is very clear, and says that the user cannot distribute the dcom installer. Well if you do a google (dcom98.exe) search its on alot of servers out there. So if MS pulls it off there servers we could just compile a list of working servers :-) Tom > > Ivan. > > > >

Jan. 6, 2004

Comment on new file implementation

by Eric Pouech

I've been working lately on rehauling the file handling in Wine. The current output is a large patch, available here: http://perso.wanadoo.fr/pouech-eric/ep-file.diff.gz (400 KB uncompressed) It's not completly ready yet for inclusion, however some ongoing discussions could overlap with what I've currently done (like how to configure drive without a config file, SMB handling...). So better discuss it widely (yet another flame war). The benefit of the patch: - all file creation, opening, directory browsing is now done in ntdll instead of kernel32 - file IO management can be cleanly separated between kernel32 and ntdll (1) - files/ directory could be removed (not done in the patch (also nuked include/drive.h and include/file.h) - homogenous drive & device handling (we no longer store those objects in the server). Drive and device are now standard file handles (from a Windows point of view). - a few current Wine bugs have been fixed (see the todo_wine removed in the tests subdirs) - we no longer rely on the Wine config dir for the drive settings - partial NT volume management implementation - most of the volume related information (& ioctl) are done on the real unix device attached to the volume What has been removed (from current implementation): - file system options (all FS are considered case insensitive) - per drive code page (all drives are now handled with the wine specfic UNIXCP code page) What still need some improvement - fix all the introduced bugs (even if all the current tests actually pass) - setting a first default environment (even if tools/winefs provides it - see below) Drives (and all their attributes - mount points, labels...) are defined this way: 1 Volumes & drives ------------------ Every volume on each available volume (partition on a physical disk) on the system will be listed in ${WINEPREFIX}/device directory. This directory will also be populated by other needed devices (serial, parallel, physical disks). Each item in this devices list will be stored as a subdirectory of ${WINEPREFIX}/device. Each subdirectory will contain various files & symlinks related to this device. Every volume will be named volume{XXX} where XXX is the actual unix device name. We're using this syntax so that we can distinguish from other (non-volume) devices and because under windows, volumes are named as Volume{<UID>} where <UID> is the unique identifier of the volume. Every DOS drive letter will be known from a (directory) entry in ${WINEPREFIX}/dosdevices. This directory will also contains entries for VxDs. A drive letter entry will in fact be a symlink to $WINEPREFIX/device/volume{XXX}/mount. This later will be another symlink to the actual mount point of volume XXX. This double indirection is needed: a DOS drive can be mounted either at the root of a volume, or as a subdirectory on that volume. The first symlink (in the dosdevices directory) will point to subdirectory we want to mount on, and the second will hold where the volume itself is mounted. For convenience reasons, we also list, for every DOS drive, the volume on which it is mounted, by creating a symlink between ${WINEPREFIX}/device/x: and ${WINEPREFIX}/device/volume{XXX} 2 Example --------- Unix side: /dev/scd0 on /mnt/cdrom /dev/fd0 on /mnt/floppy /dev/hda1 on /mnt/ntfs /dev/hda5 on /mnt/windows /dev/hda6 on / /dev/hda8 on /opt /dev/hda9 on /home Note, from now on, all paths are relative to ${WINEPREFIX} From this, we will define this hierarchy: device/ volume{fd0}/ device -> /dev/fd0 mount -> /mnt/floppy/ volume{hda1}/ device -> /dev/hda1 mount -> /mnt/ntfs/ volume{hda5}/ device -> /dev/hda5 mount -> /mnt/windows/ volume{hda6}/ device -> /dev/hda6 mount -> / volume{hda8}/ device -> /dev/hda8 mount -> /opt/ volume{hda9}/ device -> /dev/hda9 mount -> /home/ volume{scd0}/ device -> /dev/scd0 mount -> /mnt/cdrom/ This hierarchy doesn't depend on what's actually mounted (both on unix side and windows side), it's just the volume definition. We also define a few more disks related entries: device/ harddisk0/ device -> /dev/hda and some other devices as well: device/ null/ device -> /dev/null parallel0/ device -> /dev/lp0 serial0/ device -> /dev/ttyS0 Now, assume we want to define our DOS drives as follow: a: -> /mnt/fd0/ c: -> /home/eric/.wine/c_copy/ d: -> /opt/winapps/ e: -> /mnt/cdrom/ f: -> /tmp g: -> /home/eric/ m: -> /mnt/windows/ We will create two new symlinks per drive: one in $WINEPREFIX/device which will point to the device of the volume, another one in $WINEPREFIX/dosdevices which will point to the unix root we want for the drive. device/ a: -> volume{fd0} c: -> volume{hda9} d: -> volume{hda8} e: -> volume{scd0} f: -> volume{hda6} g: -> volume{hda9} m: -> volume{hda5} dosdevices/ a: -> ../device/volume{fd0}/mount/ c: -> ../device/volume{hda9}/mount/eric/.wine/c_copy/ d: -> ../device/volume{hda8}/mount/winapps/ e: -> ../device/volume{scd0}/mount/ f: -> ../device/volume{hda6}/mount/tmp/ g: -> ../device/volume{hda9}/mount/eric/ m: -> ../device/volume{hda5}/mount/ We also define some more DOS devices (for the other devices we defined): dosdevices/ com1 -> ../device/serial0/device lpt1 -> ../device/parallel0/device nul -> ../device/null/device physicaldrive0 -> ../device/harddisk0/device 3 More details on volumes ------------------------- In a volume subdirectory in ${WINEPREFIX}/volume{XXX} we can also find some other files used for: - getting volume label. We try to get information in the following order: 1/ read it from device (done for disks with FAT partition, and AUDIO or data CDROM - mixed mode is not supported) 2/ if 1/ fails, read the file .windows-label at (unix) root of volume (handy for hard, floppy disks) 3/ if 2/ fails, read the file label from the file ${WINEPREFIX}/device/volume{XXX}/label - getting volume serial number. We try to get information in the following order: 1/ read it from device (done for disks with FAT partition, and CDROMs) 2/ if 1/ fails, read the file .windows-serial at (unix) root of volume (handy for hard, floppy disks) 3/ if 2/ fails, read the file label from the file ${WINEPREFIX}/device/volume{XXX}/serial - some specific attributes are stored in ${WINEPREFIX}/device/volume{XXX}/flags. This file stores an unsigned value, which high word is the device characteristics, while its low word is the device type (from include/winioctl.h FILE_DEVICE_????). The VxDs and TSRs will be defined as an empty file (which name is VxD or TSR name) in ${WINEPREFIX}/dosdevices. Every filename will be case insensitive (device, VxD, TSR...) as we always do case insensitive matching. 4 Example of the full configuration ----------------------------------- -> is a symlink to <> contains device/ a: -> volume{fd0} c: -> volume{hda9} d: -> volume{hda8} e: -> volume{scd0} f: -> volume{hda6} g: -> volume{hda9} harddisk0/ device -> /dev/hda m: -> volume{hda5} null/ device -> /dev/null parallel0/ device -> /dev/lp0 serial0/ device -> /dev/ttyS0 volume{fd0}/ device -> /dev/fd0 flags <> FILE_DEVICE_DISK + FILE_REMOVABLE_MEDIA|FILE_FLOPPY_DISKETTE mount -> /mnt/floppy/ volume{hda1}/ device -> /dev/hda1 flags <> FILE_DEVICE_DISK mount -> /mnt/ntfs/ volume{hda5}/ device -> /dev/hda5 flags <> FILE_DEVICE_DISK label <> VolumeC mount -> /mnt/windows/ volume{hda6}/ device -> /dev/hda6 flags <> FILE_DEVICE_DISK mount -> / volume{hda8}/ device -> /dev/hda8 flags <> FILE_DEVICE_DISK mount -> /opt/ volume{hda9}/ device -> /dev/hda9 flags <> FILE_DEVICE_DISK mount -> /home/ volume{scd0}/ device -> /dev/scd0 flags <> FILE_DEVICE_CD_ROM + FILE_READ_ONLY_DEVICE|FILE_REMOVABLE_DEVICE mount -> /mnt/cdrom/ dosdevices/ a: -> ../device/volume{fd0}/mount/ afilter awredir aux -> ../dosdevices/com1 bios bios_ext bioshook biosxlat blockdev c: -> ../device/volume{hda9}/mount/eric/.wine/standalone/c_copy/ chbios com1 -> ../device/serial0/device configmg d: -> ../device/volume{hda8}/mount/winapps/ debug debugcmd dosmgr dosnet dragcli dragsrv dsvxd dwcfgmg e: -> ../device/volume{scd0}/mount/ ebios efax efilter eisa emmxxxx0 enable eten f: -> ../device/volume{hda6}/mount/tmp/ ffilter filesec g: -> ../device/volume{hda9}/mount/eric/ hasp95 hpscan ifsmgr int13 irlamp isapnp logger lpt1 -> ../device/parallel0/device m: -> ../device/volume{hda5}/mount/ mca_pos memprobe mmdevldr monodebg.vxd mrci2 msodisup ndis ndis2sup nscl nul -> ../device/null/device nwlink nwredir nwserver nwsup pagefile pageswap parity pccard pci peloader perf physicaldrive0 -> ../device/harddisk0/device ppp reboot scsi scsifd scsimgr$ scsiport secprov server shell splitter spooler stat80 tfilter tsrload v86mmgr vasync vbrowse vcache vcd vcdfsd vcomm vcond vdd vdd2 vdhcp vdmad vfat vfbackup vfd vhbiosd vime vip vkd20 vmcpd vmd vmm vmpoll vmsgd vnb vnbt vnetbios vnetsup vnwlink vpd vpend vpicd vpowerd vppid vprod vredir vsd vshare vtcp vtd vtdapi vtdi vudp vwin32 vxdldr win32s windebug winload winsock wsipx wsock wstcp 5 Configuration --------------- All this configuration is done automatically by a new tool: tools/winefs. This tool : a/ creates (in all cases) from the /etc/fstab entries (and the known VxD and TSR) all possible entries in ~/.wine/device and ~/.wine/dosdevice b/ will try to define the DOS drives depending on various sources You can run it in several fashions: 1/ winefs ~/.wine Will get all possible information from the current ~/.wine/config for Wine drive settings (mount points, device, labels, serial number...) 2/ winefs ~/.wine --bios-assign Will do as previously, but creating the DOS drive assignments as the BIOS would do 3/ winefs ~/.wine --no-assign Will only provide step a/ Beware, rerunning winefs will erase all your previous settings. Have fun !! A+ (1): not entirely true in this patch => the volume management (even if most of the code exists in ntdll) doesn't work as expected from ntdll. So the current kernel32 implementation remains

Jan. 6, 2004

Re: install default config files to $PREFIX/share/wine

by Steven Edwards

--- Alexandre Julliard <julliard(a)winehq.org> wrote: > It will be created on the fly by registering the various dlls and > creating the remaining needed keys, most likely through a setupapi > .inf script. We have already added a bunch of stuff from winedefault.reg to a inf script in ReactOS. If you wanted to try and test adding support to WINE for this here is the script: http://cvs.reactos.com/cvsweb.cgi/reactos/bootdata/hivesft.inf?rev=1.17&con… Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

Jan. 6, 2004

Re: minimum timeout for SetTimer should be 10ms

by Alexandre Julliard

Mike McCormack <mike(a)codeweavers.com> writes: > MSDN defines 10ms as the minimum timeout for Win 2000. Win9x is not > defined, but tests show it is slightly different... it's minimum > timeout is longer than 10ms, but setting to 10ms should not hurt. Actually it should have no effect at all, because the timeout is forced to SYS_TIMER_RATE (which is the Win9x minimum AFAIK) a few lines below... -- Alexandre Julliard julliard(a)winehq.com

Jan. 6, 2004

Wineconf update, RFC re remote participation

by Jeremy White

Hi folks, Okay, I've updated the Wineconf page: http://www.winehq.org/wineconf/ One thing I would like to do is to stream audio from the conference out to the web and also work very hard to include folks from #winehq (or maybe #wineconf) in some of the sessions. The sessions I thought made particular sense were the ones around Wine 1.0 as well as on OLE and Games. Does anyone recall being remote to the last Wineconf? Did it work at all? Is there anything we could/should do to enable others to join us, if only virtually? (Please feel free to tell me that it didn't work worth beans and we should just drop it, btw <g>). Other thoughts or comments? Thanks, Jer

Jan. 6, 2004

Re: #pre5 - comdlg32 MS_VC + PSDK porting

by Alexandre Julliard

Steven Edwards <steven_ed4153(a)yahoo.com> writes: > So is there any fix for us? Can we move the NONAMELESS stuff to a > internal header like like port.h? MSVC does even define NONAMLESSONION > in the same place we do with WINE and w32api. That won't really help, it needs to be available in the exported headers since it's used in structure definitions. Building with MSVC headers will require changing the code to use macros everywhere we reference the nameless structs. -- Alexandre Julliard julliard(a)winehq.com

Jan. 6, 2004

Re: #pre5 - comdlg32 MS_VC + PSDK porting

by Steven Edwards

--- Alexandre Julliard <julliard(a)winehq.com> wrote: > > Alexandre, let's just get rid of the NONAMELESSSTRUCT support, > > it just causes problems, and the benefit is a bit dubious. Any > > interesting compiler will probably be compatible with either > > msvc or gcc or both. Should I look at creating a patch? > > I don't think it's a good idea, it will break a lot of things, > including gcc 2.95 support. So is there any fix for us? Can we move the NONAMELESS stuff to a internal header like like port.h? MSVC does even define NONAMLESSONION in the same place we do with WINE and w32api. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

Jan. 6, 2004

Re: #pre5 - comdlg32 MS_VC + PSDK porting

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Alexandre, let's just get rid of the NONAMELESSSTRUCT support, > it just causes problems, and the benefit is a bit dubious. Any > interesting compiler will probably be compatible with either > msvc or gcc or both. Should I look at creating a patch? I don't think it's a good idea, it will break a lot of things, including gcc 2.95 support. -- Alexandre Julliard julliard(a)winehq.com

Jan. 6, 2004