wine-devel

wine-devel@winehq.org

2 participants
84470 discussions

Re: imm work
by Steven Edwards 07 Jan '04

07 Jan '04

Hiya Aric, --- Aric Stewart <aric(a)codeweavers.com> wrote: > Notes: > I fear this may violate dll separation between Imm32 and X11drv. I > have a very long and bad history of doing that... alot.. so i need to > get better about it. I think it does. We use Imm32 on ReactOS and this wont work for us. Its not the end of the world as we really dont need it atm but we will end up having to rewrite your work down the road. =( Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

2 2

SEH general info
by Jakob Eriksson 07 Jan '04

07 Jan '04

You all probably know, but maybe this is of interest: http://www.jorgon.freeserve.co.uk/ExceptFrame.htm

1 0

Re: wine/ libs/wine/wine.def libs/wine/loader.c in ...
by Ferenc Wagner 07 Jan '04

07 Jan '04

Alexandre Julliard <julliard(a)winehq.org> writes: > ChangeSet ID: 10547 > Changes by: julliard(a)wine.codeweavers.com 2004/01/02 15:08:05 > > Modified files: > libs/wine : wine.def loader.c > include/wine : library.h > > Log message: > Added wine_dll_get_owner function that retrieves the > 32-bit dll containing a given 16-bit dll by reading > the symlink, so that we don't need to dlopen it. This patch broke cross-compilation, as mingw does not have a readlink function. I have got no idea about the proper way, but can emit a wild shot. Feri. Index: include/wine/port.h =================================================================== RCS file: /home/wine/wine/include/wine/port.h,v retrieving revision 1.45 diff -u -r1.45 port.h --- include/wine/port.h 4 Dec 2003 05:48:03 -0000 1.45 +++ include/wine/port.h 7 Jan 2004 20:49:44 -0000 @@ -113,6 +113,7 @@ #ifndef S_ISLNK # define S_ISLNK(mod) (0) +# define readlink(path,buffer,size) (-1) #endif /* S_ISLNK */ /* So we open files in 64 bit access mode on Linux */

1 0

Re: Comment on new file implementation
by Juan Lang 07 Jan '04

07 Jan '04

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

2 1

Comment on new file implementation
by Eric Pouech 07 Jan '04

07 Jan '04

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

2 2

Re: Wineconf update, RFC re remote participation
by Ivan Leo Murray-Smith 07 Jan '04

07 Jan '04

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

2 1

my patch is in neverland :-)
by Tom 07 Jan '04

07 Jan '04

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

5 5

Re: [Fwd: [unixODBC-DEV] - UnixODBC, Wine, Crystal Report -- would appreciate insight]]
by Ulrich Czekalla 07 Jan '04

07 Jan '04

On Wed, Jan 07, 2004 at 07:11:54AM -0800, Bill Medland wrote: > On January 6, 2004 07:35 pm, Dan Kegel wrote: > > Can somebody have a look at this? > > Thanks, > > Dan > > I'll do what I can; everyone else feel free to jump in. > > > > > -------- 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. > > Those instructions were put together in order to get Crystal Reports runtime > working. Do you get anywhere if you change the override to "native"? > This is the way I do it. Switch to native odbc32, install mdac (available with ms office or download from MS site) and then setup the dsns using odbcad32.exe. /Ulrich

1 0

[Fwd: [unixODBC-DEV] - UnixODBC, Wine, Crystal Report -- would appreciate insight]
by Dan Kegel 07 Jan '04

07 Jan '04

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

2 1

Re: winewrap: fix wrapper linking
by Richard Cohen 07 Jan '04

07 Jan '04

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.

1 0

Notes on implementing mscms.dll - for anybody who's interested in digital colour management
by Mike McCormack 07 Jan '04

07 Jan '04

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

1 0

Re: widl patch
by Alexandre Julliard 07 Jan '04

07 Jan '04

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

2 2

Re: Check for null ptr return from RegEnumValue
by Alexandre Julliard 07 Jan '04

07 Jan '04

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

1 0

Re: Don't let cabinet Extract() crash IE
by Stefan Leichter 06 Jan '04

06 Jan '04

Am Freitag, 2. Januar 2004 17:28 schrieb Mike Hearn: > Hi Stefan, > > The attached patch is necessary for IE installer to work again. It seems > the magic value is not always correct: advpack derefs this value so it > probably points to a struct. I'll try and find out what it contains when > using the native DLL (if anything). > > It seems to be optional, making it 0 allows IE to continue. > Hi Mike, your are right. Its a pointer to a structure. By running native cabinet.dll i found that the dll allocates two memory areas per file inside the cabinet that are not freed within the extract function. The first memory area is always 12 bytes. The size of the second one is the length of the filename without path plus 1. The pointer points to a structure like this: struct ExtractFileList { LPSTR filename; struct ExtractFileList *next; DWORD unknown; // always 1L } ; Did your start modifying/fixing the extract function for this item? If not i will do it. Bye Stefan

3 3

RE: Will DCOM98 be pulled?
by Ivan Leo Murray-Smith 06 Jan '04

06 Jan '04

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

2 1

Re: Re: install default config files to $PREFIX/share/wine
by chmorgan＠charter.net 06 Jan '04

06 Jan '04

How do we plan to get rid of having default config files? Where would the default registry go? Chris > > From: Alexandre Julliard <julliard(a)winehq.org> > Date: 2004/01/05 Mon PM 03:19:54 EST > To: Chris Morgan <cmorgan(a)alum.wpi.edu> > CC: wine-devel(a)winehq.com > Subject: Re: install default config files to $PREFIX/share/wine > > Chris Morgan <cmorgan(a)alum.wpi.edu> writes: > > > * configure.ac, Makefile.in, documentation/Makefile.in, documentation/samples/ > > Makefile.in > > Chris Morgan <cmorgan(a)alum.wpi.edu> > > Install default wine configuration files to $PREFIX/share/wine for use by > > packages and by future changes to create a default configuration if none is > > present. > > I don't think we want that. Future changes are supposed to get rid of > the need for a config file, so we don't want to give the impression > that external apps can depend on finding a sample config file. > > -- > Alexandre Julliard > julliard(a)winehq.com > > >

7 8

Re: minimum timeout for SetTimer should be 10ms
by Alexandre Julliard 06 Jan '04

06 Jan '04

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

1 0

Of games and shorcuts [was -> Re:More Games Tested]
by Subhobroto Sinha 06 Jan '04

06 Jan '04

Hello all, I had completed the patch for IPersistFile::Load() and associated functions. In the last patch which I had submitted for review here, Mike McCormack had pointed out an incorrect assumption that I had made about all locales being DBCS. Thanks to him, many of you will not suffer ;) Now that I fixed that last (?) weeny, I had sent it to Mike for a review. However, it seems he's a bit down now, and after waiting for about a week for his reply, I thought maybe I should ask you guys to nitpick ;) I really send this in because I went through Mike Kost's post 'More Games Tested', and I saw lots of 'err:menubuilder' and 'err:menubuilder:WinMain failed to build menu item for C:\windows\Start Menu\Programs\.......\ShortcutName.lnk' messages in his report. Hopefully, this patch should solve it ... If I get any bug reports, I will be happy to fill them out,else this one's going to Alexandre (with a few cosmetic changes of course !) Regards Subhobroto Sinha

2 1

Re: Re: install default config files to $PREFIX/share/wine
by Dimitrie O. Paun 06 Jan '04

06 Jan '04

> Where do you want to have windows/ and windows/system/ > directory? In / of the UNIX filesystem, world writeable? :) OK, fine, you have a point :) But what I'm trying to say is that we can actually get away with a static config of sorts. We don't need a A: drive, it's mostly useless these days anyhow (and can be accessed through other means anyhow). Yes, we need C: to be writable and have the Windows directories, which means it can't point to /. Fine. So we'll need another one (Z is OK) to point to /. For perfect usability however, we would need definitions for CD drives ... So Alexandre seems to be right: something at boot time needs to look for devices. Or we can just have C: point to /, and install a symlink into / for the Windows dir. But then we'll have to always follow symlinks which can be a problem. Darn! -- Dimi.

1 0

event.c freezes on XFilterEvent
by Vik 06 Jan '04

06 Jan '04

Hi, I'm rather new to wine developement, and Xlib coding, and this is my first post to the list so bare with me please.... ;-) dlls/x11drv/event.c seems to freeze at XFilterEvent and brings the app to seizure ever since all the TSX functions have been gotten rid off... This is what happens: I run notepad, and start typing. Everything works fine until I hit shift+space which is the toggle for XIM (kinput in my case). Notepad freezes here. The trace on keyboard tells me that there is no character for the key combination and freezes right after; trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0x0000ffe1 >From my investigation, it seems that XFilterEvent (event.c, function process_events) <code> ignore = XFilterEvent( &event, None ); </code> is causing this. If I get rid of the whole check, and pass all the events to EVENT_ProcessEvent() , notepad would not freeze. XFilterEvent is supposed to return TRUE when the event is filtered by the XIM, but chances are that since the XIM functionalities are currently not really there, XFilterEvent cannot talk to the XIM context. As far as I remember when the TSX functions were there, the XIM window did pop up(despite XIM not working properly). I'm trying to trace the changes to see what might be causing this, but without much luck so far... I'm more than willing to try and fix this, as XIM support is critical for people from my part of the world (Japan, and most likely for Korea & China). We've been coming up with rather crude patches to have XIM work till now(upto 20031118), but can't get it to work because of this strange freezure we are experiencing.... Any pointers or thoughts will be greatly appreciated! Cheers Vik -- ------------ Vikram Kumar vik(a)zone81.com

4 5

Re: Re: install default config files to $PREFIX/share/wine
by chmorgan＠charter.net 06 Jan '04

06 Jan '04

If we also had working defaults for the users cdrom drive(s) and floppy drive then this would work quite well. Many users will want to install applications from cdrom. We could autodetect this at startup. Chris > > From: "Dimitrie O. Paun" <dpaun(a)rogers.com> > Date: 2004/01/06 Tue AM 09:44:05 EST > To: Alexandre Julliard <julliard(a)winehq.org>, > Marcus Meissner <marcus(a)jet.franken.de> > CC: cmorgan(a)alum.WPI.EDU, wine-devel(a)winehq.com > Subject: Re: install default config files to $PREFIX/share/wine > > On January 5, 2004 05:27 pm, Alexandre Julliard wrote: > > We will need a tool (maybe wineboot) to setup the initial drive config > > according to the machine setup. A default config file is not going to > > help with that anyway. > > I'd say we just have a C: drive pointing to / (root). This setup > is definitely the most user friendly, and the one most in the > spirit of Unix (one large tree). A user of a Unix system will be > most confortable with it, and it will create the least unexpected > behavior. > > Thinking about this, I'm not even sure why we encourage people to > define drives (by having a nice UI in winecfg)... What's wrong > with only a C: drive by default? Power users have regedit :) > > -- > Dimi. > > > >

1 0

Re: Re: install default config files to $PREFIX/share/wine
by brettholcomb＠charter.net 06 Jan '04

06 Jan '04

Do you really mean / and not ~? I sure don't want my C: pointing at /. And if there are more than one user how do I keep their stuff separate. What about access permissions to / - a normal user doesn't have it to many places. > > From: "Dimitrie O. Paun" <dpaun(a)rogers.com> > Date: 2004/01/06 Tue AM 09:44:05 EST > To: Alexandre Julliard <julliard(a)winehq.org>, > Marcus Meissner <marcus(a)jet.franken.de> > CC: cmorgan(a)alum.wpi.edu, wine-devel(a)winehq.com > Subject: Re: install default config files to $PREFIX/share/wine > > On January 5, 2004 05:27 pm, Alexandre Julliard wrote: > > We will need a tool (maybe wineboot) to setup the initial drive config > > according to the machine setup. A default config file is not going to > > help with that anyway. > > I'd say we just have a C: drive pointing to / (root). This setup > is definitely the most user friendly, and the one most in the > spirit of Unix (one large tree). A user of a Unix system will be > most confortable with it, and it will create the least unexpected > behavior. > > Thinking about this, I'm not even sure why we encourage people to > define drives (by having a nice UI in winecfg)... What's wrong > with only a C: drive by default? Power users have regedit :) > > -- > Dimi. > > >

1 0

Still having problems with Wine CVS
by Flameeyes 06 Jan '04

06 Jan '04

Hi, I posted before in wine-users, but I haven't had any answer. I compiled, as usual, wine from cvs, but in the last weeks I have this error every file I try to run: err:msg:QUEUE_CreateMsgQueue Cannot get thread queueMain exe initialization for L"C:\\Program Files\\DepWalker\\depends.exe" failed, status c0000142 Only the path changes (correctly), the status code is always the same. Can anyone help me? -- Flameeyes <dgp85(a)users.sourceforge.net> You can find LIRC for 2.6 kernels at http://flameeyes.web.ctonet.it/

2 1

Donations at SourceForge
by Dimitrie O. Paun 06 Jan '04

06 Jan '04

Hi folks, After intense setup work from Alexandre and myself (about 3 clicks per person :P), we've managed to enable donations through our SourceForge page: http://sourceforge.net/projects/wine/ Direct donation link: http://sourceforge.net/donate/index.php?group_id=6241 Now, to test the new facility, we need as many users as possible make all sorts of donations to the project...;) -- Dimi.

2 1

AutoCad 2000 latest status ?
by John 06 Jan '04

06 Jan '04

I know there are interests in autocad 2000 status with wine. I was happy to read in http://appdb.winehq.org/appview.php?appId=86&versionId=102 that autocad 2000 actually starts up now, although there seams to be a file open problem. I just wanted to forward this news in case someone is interested in fixing the details now that it at least starts up. ________________________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel