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

Re: Tab Ctrl fix

by Dimitrie O. Paun

On Sat, 26 Jan 2002, Dimitrie O. Paun wrote: > [extracted from office2.diff] > > ChangeLog > Tab Control: forward the notification message to the parent. Oops, never mind this one, it's already in the tree. -- Dimi.

Jan. 26, 2002

Re: Patch that broke SetFileAttributes

by Jukka Heinonen

On Sat, Jan 26, 2002 at 06:49:53PM +0100, Marcus Meissner wrote: > The problem is more that file attribute settings just doesnt work that well > on VFAT. > > So you basically break some more installers. > > I don't remember what installer it was however. :( Marcus, can you give some detailed information about cases where SetFileAttributes must succeed even though chattr fails? As far as I understand the original reason for your patch to SetFileAttributes was because users in some Wine installation shared large parts of windows and system directories and these shared parts were readonly, which makes chattr and thus SetFileAttributes fail. Now you are talking about some VFAT related problem. Is this problem in Linux VFAT drivers, Wine VFAT support or VFAT itself? If you can give enough details I could try to make a patch that would make SetFileAttributes behaviour closer to Windows behaviour and which would have proper comments about incompatibilities (unless you want to do the patch yourself, of course). -- Jukka Heinonen <http://www.iki.fi/jhei/>

Jan. 26, 2002

Re: Patch that broke SetFileAttributes

by Andreas Mohr

On Sat, Jan 26, 2002 at 06:55:52PM +0100, Andreas Mohr wrote: > Anyway, the installer shouldn't matter at all. > What matters is writing a very good test program to find a way > to support every possible combination as well as possible. Hmm, I think the solution here would be to simply add a check for a read-only medium at this place and to conditionally return FALSE or TRUE. Just use DRIVE_FindDriveRoot() on full_name.long_name to get the drive, then check its flags for read-only e.g. via DRIVE_GetFlags(). -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Jan. 26, 2002

Re: Patch that broke SetFileAttributes

by Andreas Mohr

On Sat, Jan 26, 2002 at 06:49:53PM +0100, Marcus Meissner wrote: > On Sat, Jan 26, 2002 at 06:44:12PM +0100, Andreas Mohr wrote: > > Simply reverting the patch done by Marcus does no good at all. > > Either invest enough time to fully understand read-only > > file/directory/device behaviour (and possibly fix Wine to handle everything > > 150% correctly :) or forget it, I'd say. > > The problem is more that file attribute settings just doesnt work that well > on VFAT. > > So you basically break some more installers. > > I don't remember what installer it was however. :( Hmm, like always ;-) That's why I'm particularly fond of adding program information to Changelogs I create :) Anyway, the installer shouldn't matter at all. What matters is writing a very good test program to find a way to support every possible combination as well as possible. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Jan. 26, 2002

Re: int 33

by Andreas Mohr

On Sat, Jan 26, 2002 at 05:34:33PM +0200, Nog wrote: > With this patch I can get into the copy protection screen in monkey > island 2 but the keyboard still doesn't work. > > Changelog: > * dlls/winedos/int33.c > Implement function number 0x5 (Return mouse button press information) > > nog > > P.S. Does anyone know how the Mouse motion counters (function 0xb) work? >From Ralf Brown's Intlist: --------M-33000B----------------------------- INT 33 - MS MOUSE v1.0+ - READ MOTION COUNTERS AX = 000Bh Return: CX = number of mickeys mouse moved horizontally since last call DX = number of mickeys mouse moved vertically Notes: a mickey is the smallest increment the mouse can sense positive values indicate down/right SeeAlso: AX=0003h,AX=001Bh,AX=0027h -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Jan. 26, 2002

Re: Patch that broke SetFileAttributes

by Marcus Meissner

On Sat, Jan 26, 2002 at 06:44:12PM +0100, Andreas Mohr wrote: > On Sat, Jan 26, 2002 at 06:58:31AM +0200, Jukka Heinonen wrote: > > Fallout II requires that a certain file is located > > on a CDROM drive. For some reason it checks this using > > SetFileAttributes, which is supposed to fail on readonly > > drives. This used to work until the following patch broke > > this behaviour (message continues after the patch): > > > > Index: file.c > > =================================================================== > > RCS file: /home/wine/wine/win32/file.c,v > > retrieving revision 1.26 > > retrieving revision 1.27 > > diff -u -r1.26 -r1.27 > > --- file.c 2001/05/14 20:09:39 1.26 > > +++ file.c 2001/05/18 23:18:25 1.27 > > @@ -104,7 +104,7 @@ > > { > > FILE_SetDosError(); > > MESSAGE("Wine ERROR: Couldn't set file attributes for existing file \"%s\". Check permissions or set VFAT \"quiet\" flag !\n", full_name.long_name); > > - return FALSE; > > + return TRUE; > > } > > return TRUE; > > } > > > > The above patch obviously breaks Windows compatibility (and likely has a > > bug related to FILE_SetDosError). I would like to suggest that this patch > > is either removed or replaced with a patch that includes a C comment that > > properly documents reasons for this deliberate incompatibility and that > > either only affects non-CDROM drives or drives configured using > > some magic flag in Wine configuration file. > NO !! :-) > > Note that read-only handling in general is *very* problematic. > (and Marcus *did* have a reason for changing it the other way around, > I suppose !) > There is the issue of read-only *drives* vs. read-only *files*, too ! > > Wine should make sure that it returns proper values in all cases. > > Simply reverting the patch done by Marcus does no good at all. > Either invest enough time to fully understand read-only > file/directory/device behaviour (and possibly fix Wine to handle everything > 150% correctly :) or forget it, I'd say. The problem is more that file attribute settings just doesnt work that well on VFAT. So you basically break some more installers. I don't remember what installer it was however. :( Ciao, Marcus

Jan. 26, 2002

Re: Patch that broke SetFileAttributes

by Andreas Mohr

On Sat, Jan 26, 2002 at 06:58:31AM +0200, Jukka Heinonen wrote: > Fallout II requires that a certain file is located > on a CDROM drive. For some reason it checks this using > SetFileAttributes, which is supposed to fail on readonly > drives. This used to work until the following patch broke > this behaviour (message continues after the patch): > > Index: file.c > =================================================================== > RCS file: /home/wine/wine/win32/file.c,v > retrieving revision 1.26 > retrieving revision 1.27 > diff -u -r1.26 -r1.27 > --- file.c 2001/05/14 20:09:39 1.26 > +++ file.c 2001/05/18 23:18:25 1.27 > @@ -104,7 +104,7 @@ > { > FILE_SetDosError(); > MESSAGE("Wine ERROR: Couldn't set file attributes for existing file \"%s\". Check permissions or set VFAT \"quiet\" flag !\n", full_name.long_name); > - return FALSE; > + return TRUE; > } > return TRUE; > } > > The above patch obviously breaks Windows compatibility (and likely has a > bug related to FILE_SetDosError). I would like to suggest that this patch > is either removed or replaced with a patch that includes a C comment that > properly documents reasons for this deliberate incompatibility and that > either only affects non-CDROM drives or drives configured using > some magic flag in Wine configuration file. NO !! :-) Note that read-only handling in general is *very* problematic. (and Marcus *did* have a reason for changing it the other way around, I suppose !) There is the issue of read-only *drives* vs. read-only *files*, too ! Wine should make sure that it returns proper values in all cases. Simply reverting the patch done by Marcus does no good at all. Either invest enough time to fully understand read-only file/directory/device behaviour (and possibly fix Wine to handle everything 150% correctly :) or forget it, I'd say. So either submit a patch that adds a comment to SFA() documenting the reason for the current behaviour and where/why it breaks sometimes, or write a "real" patch correctly fixing it. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Jan. 26, 2002

Re: Driver critical section changes from CW

by Duane Clark

Duane Clark wrote: > Modified files: > dlls/gdi : driver.c > loader : module.c Sorry, my bad.

Jan. 26, 2002

Driver critical section changes from CW

by Duane Clark

Modified files: dlls/gdi : driver.c loader : module.c Log message: Codeweavers Replace Rtl...PebLock with Rtl...CriticalSection. Slight change to library loading. Index: dlls/gdi/driver.c =================================================================== RCS file: /home/wine/wine/dlls/gdi/driver.c,v retrieving revision 1.6 diff -u -r1.6 driver.c --- dlls/gdi/driver.c 2001/09/14 01:00:57 1.6 +++ dlls/gdi/driver.c 2002/01/26 15:02:42 @@ -27,8 +27,8 @@ static struct graphics_driver *first_driver; static struct graphics_driver *display_driver; static const DC_FUNCTIONS *win16_driver; +static CRITICAL_SECTION driver_section = CRITICAL_SECTION_INIT( "driver_section" ); - /********************************************************************** * create_driver * @@ -207,13 +207,13 @@ HMODULE module; struct graphics_driver *driver; - RtlAcquirePebLock(); + RtlEnterCriticalSection( &driver_section ); /* display driver is a special case */ if (!strcasecmp( name, "display" )) { driver = load_display_driver(); - RtlReleasePebLock(); + RtlLeaveCriticalSection( &driver_section ); return &driver->funcs; } @@ -224,7 +224,7 @@ if (driver->module == module) { driver->count++; - RtlReleasePebLock(); + RtlLeaveCriticalSection( &driver_section ); return &driver->funcs; } } @@ -233,19 +233,19 @@ if (!(module = LoadLibraryA( name ))) { if (!win16_driver) win16_driver = WIN16DRV_Init(); - RtlReleasePebLock(); + RtlLeaveCriticalSection( &driver_section ); return win16_driver; } if (!(driver = create_driver( module ))) { FreeLibrary( module ); - RtlReleasePebLock(); + RtlLeaveCriticalSection( &driver_section ); return NULL; } TRACE( "loaded driver %p for %s\n", driver, name ); - RtlReleasePebLock(); + RtlLeaveCriticalSection( &driver_section ); return &driver->funcs; } @@ -259,7 +259,7 @@ { struct graphics_driver *driver; - RtlAcquirePebLock(); + RtlEnterCriticalSection( &driver_section ); if (funcs != win16_driver) { for (driver = first_driver; driver; driver = driver->next) @@ -267,7 +267,7 @@ if (!driver) ERR( "driver not found, trouble ahead\n" ); driver->count++; } - RtlReleasePebLock(); + RtlLeaveCriticalSection( &driver_section ); return funcs; } @@ -281,7 +281,7 @@ { struct graphics_driver *driver; - RtlAcquirePebLock(); + RtlEnterCriticalSection( &driver_section ); if (funcs == win16_driver) goto done; @@ -300,7 +300,7 @@ FreeLibrary( driver->module ); HeapFree( GetProcessHeap(), 0, driver ); done: - RtlReleasePebLock(); + RtlLeaveCriticalSection( &driver_section ); } Index: loader/module.c =================================================================== RCS file: /home/wine/wine/loader/module.c,v retrieving revision 1.145 diff -u -r1.145 module.c --- loader/module.c 2002/01/18 18:58:08 1.145 +++ loader/module.c 2002/01/26 15:02:43 @@ -29,6 +29,8 @@ static int free_lib_count; /* recursion depth of FreeLibrary calls */ static int process_detaching; /* set on process detach to avoid deadlocks with thread detach */ +static CRITICAL_SECTION loader_section = CRITICAL_SECTION_INIT( "loader_section" ); + /*********************************************************************** * wait_input_idle * @@ -176,9 +178,13 @@ BOOL retv = TRUE; int i; - RtlAcquirePebLock(); + RtlEnterCriticalSection( &loader_section ); - if (!wm) wm = exe_modref; + if (!wm) + { + wm = exe_modref; + PE_InitTls(); + } assert( wm ); /* prevent infinite recursion in case of cyclical dependencies */ @@ -221,7 +227,7 @@ TRACE("(%s,%p) - END\n", wm->modname, lpReserved ); done: - RtlReleasePebLock(); + RtlLeaveCriticalSection( &loader_section ); return retv; } @@ -236,7 +242,7 @@ { WINE_MODREF *wm; - RtlAcquirePebLock(); + RtlEnterCriticalSection( &loader_section ); if (bForceDetach) process_detaching = 1; do { @@ -258,7 +264,7 @@ } } while ( wm ); - RtlReleasePebLock(); + RtlLeaveCriticalSection( &loader_section ); } /************************************************************************* @@ -276,8 +282,10 @@ if (process_detaching) return; /* FIXME: there is still a race here */ - RtlAcquirePebLock(); + RtlEnterCriticalSection( &loader_section ); + PE_InitTls(); + for ( wm = MODULE_modref_list; wm; wm = wm->next ) if ( !wm->next ) break; @@ -292,7 +300,7 @@ MODULE_InitDLL( wm, DLL_THREAD_ATTACH, lpReserved ); } - RtlReleasePebLock(); + RtlLeaveCriticalSection( &loader_section ); } /************************************************************************* @@ -310,7 +318,7 @@ if (process_detaching) return; /* FIXME: there is still a race here */ - RtlAcquirePebLock(); + RtlEnterCriticalSection( &loader_section ); for ( wm = MODULE_modref_list; wm; wm = wm->next ) { @@ -322,7 +330,7 @@ MODULE_InitDLL( wm, DLL_THREAD_DETACH, lpReserved ); } - RtlReleasePebLock(); + RtlLeaveCriticalSection( &loader_section ); } /**************************************************************************** @@ -335,7 +343,7 @@ WINE_MODREF *wm; BOOL retval = TRUE; - RtlAcquirePebLock(); + RtlEnterCriticalSection( &loader_section ); wm = MODULE32_LookupHMODULE( hModule ); if ( !wm ) @@ -343,7 +351,7 @@ else wm->flags |= WINE_MODREF_NO_DLL_CALLS; - RtlReleasePebLock(); + RtlLeaveCriticalSection( &loader_section ); return retval; } @@ -1231,13 +1239,13 @@ { WINE_MODREF *wm; - RtlAcquirePebLock(); + RtlEnterCriticalSection( &loader_section ); lpFileName[0] = 0; if ((wm = MODULE32_LookupHMODULE( hModule ))) lstrcpynA( lpFileName, wm->filename, size ); - RtlReleasePebLock(); + RtlLeaveCriticalSection( &loader_section ); TRACE("%s\n", lpFileName ); return strlen(lpFileName); } @@ -1284,7 +1292,18 @@ NULL, OPEN_EXISTING, 0, 0 ); if (hFile != INVALID_HANDLE_VALUE) { - hmod = PE_LoadImage( hFile, filename, flags ); + DWORD type; + MODULE_GetBinaryType( hFile, filename, &type ); + if (type == SCS_32BIT_BINARY) + { + HANDLE mapping = CreateFileMappingA( hFile, NULL, PAGE_READONLY, + 0, 0, NULL ); + if (mapping) + { + hmod = (HMODULE)MapViewOfFile( mapping, FILE_MAP_READ, 0, 0, 0 ); + CloseHandle( mapping ); + } + } CloseHandle( hFile ); } if (hmod) return (HMODULE)((ULONG_PTR)hmod + 1); @@ -1293,7 +1312,7 @@ /* Fallback to normal behaviour */ } - RtlAcquirePebLock(); + RtlEnterCriticalSection( &loader_section ); wm = MODULE_LoadLibraryExA( libname, hfile, flags ); if ( wm ) @@ -1307,7 +1326,7 @@ } } - RtlReleasePebLock(); + RtlLeaveCriticalSection( &loader_section ); return wm ? wm->module : 0; } @@ -1381,7 +1400,7 @@ if ( !filename ) return NULL; *filename = 0; /* Just in case we don't set it before goto error */ - RtlAcquirePebLock(); + RtlEnterCriticalSection( &loader_section ); if ((flags & LOAD_WITH_ALTERED_SEARCH_PATH) && FILE_contains_path(libname)) { @@ -1459,7 +1478,7 @@ HeapFree ( GetProcessHeap(), 0, (LPSTR)libdir ); libdir = NULL; } - RtlReleasePebLock(); + RtlLeaveCriticalSection( &loader_section ); HeapFree ( GetProcessHeap(), 0, filename ); return pwm; } @@ -1511,7 +1530,7 @@ HeapFree ( GetProcessHeap(), 0, (LPSTR)libdir ); libdir = NULL; } - RtlReleasePebLock(); + RtlLeaveCriticalSection( &loader_section ); SetLastError( err ); /* restore last error */ HeapFree ( GetProcessHeap(), 0, filename ); return pwm; @@ -1527,7 +1546,7 @@ HeapFree ( GetProcessHeap(), 0, (LPSTR)libdir ); libdir = NULL; } - RtlReleasePebLock(); + RtlLeaveCriticalSection( &loader_section ); WARN("Failed to load module '%s'; error=0x%08lx\n", filename, GetLastError()); HeapFree ( GetProcessHeap(), 0, filename ); return NULL; @@ -1634,13 +1653,13 @@ return TRUE; } - RtlAcquirePebLock(); + RtlEnterCriticalSection( &loader_section ); free_lib_count++; if ((wm = MODULE32_LookupHMODULE( hLibModule ))) retv = MODULE_FreeLibrary( wm ); free_lib_count--; - RtlReleasePebLock(); + RtlLeaveCriticalSection( &loader_section ); return retv; } @@ -1818,13 +1837,13 @@ else TRACE_(win32)("(%08lx,%p)\n",(DWORD)hModule,function); - RtlAcquirePebLock(); + RtlEnterCriticalSection( &loader_section ); if ((wm = MODULE32_LookupHMODULE( hModule ))) { retproc = wm->find_export( wm, function, snoop ); if (!retproc) SetLastError(ERROR_PROC_NOT_FOUND); } - RtlReleasePebLock(); + RtlLeaveCriticalSection( &loader_section ); return retproc; }

Jan. 26, 2002

Re: int 33

by Nog

Sorry forgot the file. Nog wrote: > With this patch I can get into the copy protection screen in monkey > island 2 but the keyboard still doesn't work. > > Changelog: > * dlls/winedos/int33.c > Implement function number 0x5 (Return mouse button press > information) > > nog > > P.S. Does anyone know how the Mouse motion counters (function 0xb) work? > > > > > Index: dlls/winedos/int33.c =================================================================== RCS file: /home/wine/wine/dlls/winedos/int33.c,v retrieving revision 1.1 diff -u -r1.1 int33.c --- dlls/winedos/int33.c 2001/12/04 19:54:45 1.1 +++ dlls/winedos/int33.c 2002/01/26 15:17:29 @@ -19,6 +19,7 @@ static struct { DWORD x, y, but; + WORD lbcount, rbcount, rlastx, rlasty, llastx, llasty; FARPROC16 callback; WORD callmask; } mouse_info; @@ -52,6 +53,22 @@ case 0x04: FIXME("Position mouse cursor\n"); break; + case 0x05: + TRACE("Return Mouse button press Information for %s mouse button\n", + BX_reg(context) ? "right" : "left"); + if (BX_reg(context)) { + BX_reg(context) = mouse_info.rbcount; + mouse_info.rbcount = 0; + CX_reg(context) = mouse_info.rlastx; + DX_reg(context) = mouse_info.rlasty; + } else { + BX_reg(context) = mouse_info.lbcount; + mouse_info.lbcount = 0; + CX_reg(context) = mouse_info.llastx; + DX_reg(context) = mouse_info.llasty; + } + AX_reg(context) = mouse_info.but; + break; case 0x07: FIXME("Define horizontal mouse cursor range\n"); break; @@ -106,7 +123,8 @@ if (!VGA_GetMode(&Height,&Width,NULL)) { /* may need to do some coordinate scaling */ - SX = 640/Width; + if (Width) + SX = 640/Width; if (!SX) SX=1; } mouse_info.x = LOWORD(lParam) * SX; @@ -119,6 +137,9 @@ case WM_LBUTTONDBLCLK: mouse_info.but |= 0x01; mask |= 0x02; + mouse_info.llastx = mouse_info.x; + mouse_info.llasty = mouse_info.y; + mouse_info.lbcount++; break; case WM_LBUTTONUP: mouse_info.but &= ~0x01; @@ -128,6 +149,9 @@ case WM_RBUTTONDBLCLK: mouse_info.but |= 0x02; mask |= 0x08; + mouse_info.rlastx = mouse_info.x; + mouse_info.rlasty = mouse_info.y; + mouse_info.rbcount++; break; case WM_RBUTTONUP: mouse_info.but &= ~0x02;

Jan. 26, 2002

Filename parsing

by Duane Clark

Modified files: dlls/commdlg : file.c Log message: Codeweavers Add SHGDN_FORPARSING flag when looking for filenames. Index: dlls/commdlg/filedlg95.c =================================================================== RCS file: /home/wine/wine/dlls/commdlg/filedlg95.c,v retrieving revision 1.62 diff -u -r1.62 filedlg95.c --- dlls/commdlg/filedlg95.c 2001/12/04 19:39:33 1.62 +++ dlls/commdlg/filedlg95.c 2002/01/26 14:54:17 @@ -2374,7 +2374,7 @@ { /* get the total length of the selected file names*/ lpstrTemp[0] = '\0'; - GetName( fodInfos->Shell.FOIShellFolder, pidl, SHGDN_INFOLDER, lpstrTemp ); + GetName( fodInfos->Shell.FOIShellFolder, pidl, SHGDN_INFOLDER|SHGDN_FORPARSING, lpstrTemp ); if ( ! IsPidlFolder(fodInfos->Shell.FOIShellFolder, pidl) ) /* Ignore folders */ { @@ -2403,7 +2403,7 @@ { /* get the file name */ lpstrTemp[0] = '\0'; - GetName( fodInfos->Shell.FOIShellFolder, pidl, SHGDN_INFOLDER, lpstrTemp ); + GetName( fodInfos->Shell.FOIShellFolder, pidl, SHGDN_INFOLDER|SHGDN_FORPARSING, lpstrTemp ); if (! IsPidlFolder(fodInfos->Shell.FOIShellFolder, pidl)) /* Ignore folders */ {

Jan. 26, 2002

Re: SetEndOfFile fix

by Duane Clark

Rein Klazes wrote: > > BTW, what goes wrong exactly? From the snippet above I understand that > either ftruncate() moves the filepointer when it fails or that the > sequence: lseek(fd,-1,SEEK_CUR);write(fd,&buf,1) moves the file > pointer. For your perusal, codeweavers also had a reimplementation of this, so I split that out and posted it.

Jan. 26, 2002

Re: SetEndOfFile fix

by Rein Klazes

On Sat, 26 Jan 2002 01:48:06 -0500, you wrote: > > This was a great catch. It was the reason Scandisk complained about > OutlookExpress's files (see my message from 1/11/2001). However your fix > still fails on my outdated kernel (2.2.12-20). The attached version seems to > work better on this kernel. [...] > + > + if( (oldoff = lseek( fd, 0, SEEK_CUR)) == -1) return -1; > + if( lseek( fd, length - 1, SEEK_SET) == -1) return -1; > + /* write one byte, filepointer is back at the orig. position. */ > + if( write( fd, &buf, 1) == -1) return -1; > + if( lseek( fd, oldoff, SEEK_SET) == -1) return -1; You should not have to use the oldoff offset. When this function is entered the filepointer is already set to the desired length: length. BTW, what goes wrong exactly? From the snippet above I understand that either ftruncate() moves the filepointer when it fails or that the sequence: lseek(fd,-1,SEEK_CUR);write(fd,&buf,1) moves the file pointer. Rein. -- Rein Klazes rklazes(a)xs4all.nl

Jan. 26, 2002

Patch for OLEClipbrd_IDataObject_GetData

by Sander van Leeuwen

Hi, Forte Agent was unable to copy text from the clipboard into the message body window because of a bug in this method. I'm not sure how Wine's clipboard implementation works, but handles returned by GetClipboardData are not supposed to be valid after the app calls CloseClipboard (see MS docs). The attached patch makes a copy of the clipboard handle and passes that to the application. Forte Agent frees this handle after it has extracted the clipboard data, so there's no memory leak. Sander

Jan. 26, 2002

Re: SetEndOfFile fix

by Guy L. Albertelli

----- Original Message ----- From: "Rein Klazes" <rklazes(a)xs4all.nl> To: <wine-patches(a)winehq.com> Sent: Sunday, January 20, 2002 2:13 PM Subject: SetEndOfFile fix > hi, > > This fixes office 97 MSword error (disk full or write protected) when > saving files on a vfat partition. MSword calls SetEndOfFile() which > uses ftruncate() that, in Linux, cannot grow files in this filesystem. > > BTW. A google search shows that the ftruncate problem has been > mentioned at least 3 times on c.e.m.w. in the last 6 months Since > nobody entered a fix, I could be overlooking something... This was a great catch. It was the reason Scandisk complained about OutlookExpress's files (see my message from 1/11/2001). However your fix still fails on my outdated kernel (2.2.12-20). The attached version seems to work better on this kernel. Guy

Jan. 26, 2002

Patch that broke SetFileAttributes

by Jukka Heinonen

Fallout II requires that a certain file is located on a CDROM drive. For some reason it checks this using SetFileAttributes, which is supposed to fail on readonly drives. This used to work until the following patch broke this behaviour (message continues after the patch): Index: file.c =================================================================== RCS file: /home/wine/wine/win32/file.c,v retrieving revision 1.26 retrieving revision 1.27 diff -u -r1.26 -r1.27 --- file.c 2001/05/14 20:09:39 1.26 +++ file.c 2001/05/18 23:18:25 1.27 @@ -104,7 +104,7 @@ { FILE_SetDosError(); MESSAGE("Wine ERROR: Couldn't set file attributes for existing file \"%s\". Check permissions or set VFAT \"quiet\" flag !\n", full_name.long_name); - return FALSE; + return TRUE; } return TRUE; } The above patch obviously breaks Windows compatibility (and likely has a bug related to FILE_SetDosError). I would like to suggest that this patch is either removed or replaced with a patch that includes a C comment that properly documents reasons for this deliberate incompatibility and that either only affects non-CDROM drives or drives configured using some magic flag in Wine configuration file. -- Jukka Heinonen <http://www.iki.fi/jhei/>

Jan. 25, 2002

Re: The cat is out of the bag (Lindows)

by Hetz Ben Hamo

And it's on slashdot - and boy oh boy - they really don't like the root user approach (and I kinda agree with them)... Hetz On Saturday 26 January 2002 01:33, Hetz Ben Hamo wrote: > Hi People, > > In case you didn't see - Lindows "preview" review is on > www.newsforge.com... > > Hetz

Jan. 25, 2002

Re: cvs run

by lawson_whitney＠juno.com

On 25 Jan 2002, lee johnson wrote: > just got wine cvs but it refuses to run even with copying missing shared > file from $HOME to say /usr/lib Yes, and did you have root run /sbin/ldconfig after copying shared files to, say /usr/lib? > > here is error: > --------------- > > > [codewind(a)imyourhandiman codewind]$ wine > wine: error while loading shared libraries: libwine.so: cannot open > shared object file: No such file or directory > [codewind(a)imyourhandiman codewind]$ > > thx > lee > -==== ldd is a very handy tool for sorting out shared library problems. ldd wine if none of those end with => not found, recurse until one does: ldd ./wine|cut -d \> -f 2|cut -f 2 -d " "|xargs ldd ldd ./wine|cut -d \> -f 2|cut -f 2 -d " "|xargs ldd \ |cut -d \> -f 2|cut -f 2 -d " "|xargs ldd You don't have to copy anything to run wine from <wine>, btw, just set LD_LUBRARY_PATH to <wine>:<wine>/dlls and WINESERVER to <wine>/server/wineserver. With bash, the usual way is to export those values before running ./wine You might like to make a script to do it. Lawson Probable user head space error. - Dennis A. Moore

Jan. 25, 2002

The cat is out of the bag (Lindows)

by Hetz Ben Hamo

Hi People, In case you didn't see - Lindows "preview" review is on www.newsforge.com... Hetz

Jan. 25, 2002

cvs run

by lee johnson

just got wine cvs but it refuses to run even with copying missing shared file from $HOME to say /usr/lib here is error: --------------- [codewind(a)imyourhandiman codewind]$ wine wine: error while loading shared libraries: libwine.so: cannot open shared object file: No such file or directory [codewind(a)imyourhandiman codewind]$ thx lee -====

Jan. 25, 2002

Does Windows have one of these?

by Bill Medland

As I look deeper into the DrawText boundary behaviour it becomes clear to me that the Microsoft version must actually keep the & symbols in the string until the very last moment. In particular it looks to me like they actually measure strings that contain them. I can't see how they can do that with GetTextExtent and its relatives; I can't see where to hide a flag as to whether to interpret the & or not. Does anyone know if there are Microsoft undocumented functions or undocumented ways to measure and output a text that includes & symbols with a way of specifying whether they count as prefix characters or not? Personally it seems silly to me and I don't intend doing so myself unless there is a good reason to duplicate all of Microsoft's weird bugs. Bill

Jan. 25, 2002

Re: Excessive clipping of text in listview

by Dimitrie O. Paun

On Fri, 25 Jan 2002, Bill Medland wrote: > Search at www.microsoft.com fpor rowlist; it's about the third hit > (msdn.microsoft.com/msdn-files) Download and compile under VC++ 6 That's great, but I don't even have a Windows partition, let alone VC++! But nevermind the request, if the code works now... -- Dimi.

Jan. 25, 2002

Re: Excessive clipping of text in listview

by Dimitrie O. Paun

On Fri, 25 Jan 2002, Bill Medland wrote: > Fine (after satisfying the compiler). Cool. What was wrong? Nevermind, I'll check the patch. > Shall I submit it or do you want the glory? Sure I want the glory, but you can submit it. :) -- Dimi.

Jan. 25, 2002

Re: Excessive clipping of text in listview

by Bill Medland

"Dimitrie O. Paun" <dimi(a)cs.toronto.edu> wrote in message news:Pine.GSO.4.21.0201251342440.14925-200000(a)dvp.cs... > On Fri, 25 Jan 2002, Medland, Bill wrote: > > > p.s. what is going on in DrawLargeItem with the ellipsification; it looks > > like it ellipsifies it and then throws the result away. > > Bill, > > Can you try the attached (uncompiled, untested) patch? It simplifies the > code quite a bit IMO. BTW, the previous code did not throw away the > ellipsification since szDispText == lvItem.pszText. Fine (after satisfying the compiler). Shall I submit it or do you want the glory? Bill

Jan. 25, 2002

Re: Excessive clipping of text in listview

by Bill Medland

"Dimitrie O. Paun" <dimi(a)cs.toronto.edu> wrote in message news:Pine.GSO.4.21.0201251308080.14925-100000(a)dvp.cs... > On Fri, 25 Jan 2002, Medland, Bill wrote: > > > Do you have access to the Microsoft "rowlist" sample? If so then use that > > No, I don't. Can you send me a copy, or point me to a place where I can > get it from? Search at www.microsoft.com fpor rowlist; it's about the third hit (msdn.microsoft.com/msdn-files) Download and compile under VC++ 6 > > > but edit a couple of the labels to be longer than one line. It's the "being > > longer than one line" that messes it up. > > Aha! That's a good tip -- I'll check it out soon, but right now I'm at > work, and I don't have any Wine-related things around :) > > > Thanks for the rapid response > > No problem -- sorry for the screw up :) > > > p.s. what is going on in DrawLargeItem with the ellipsification; it looks > > like it ellipsifies it and then throws the result away. > > No wonder -- that's the most obscure part of the code, and I had the most > problems with debugging the thing... > > > I am currently working on DrawText which should provide everything needed to > > draw the text properly. I am feeding it to Alexandre in small pieces so > > that we don't break anything. Microsoft, as far as I can see, don't > > actually use DrawText; they appear to reimplement all the ellipsification > > but I don't see why. > > Cool. Given your knowladge of DrawText, should I just drop the > ellipsification and simply let DrawText do it? I would say so. I expect to get the DrawText up to a usable state in a couple of weeks at most. (I've proven the concept but I need to step through the deltas carefully to make sure I don't break it). The fix will add the multiline capability with special symantics for DT_EDITCONTROL which, I believe, will make DrawText operate the same way as the text in listview. (including weird things like what does wordbreak do when a single word is too long!). Then the fun will start on ListView. When I played with it about 6 months ago the painting became a problem, taking into account when it is two lines deep, when it is "as long as needed" etc. Bill > > -- > Dimi. > > > >

Jan. 25, 2002