- wine-devel - winehq.org

A new SDL back-end we've been toying with
by Gavriel State 29 Jan '02

29 Jan '02

Hi everyone, We just put this together for some testing, and thought that someone might find it handy. I'm not submitting it to wine-patches, since we haven't tested it on the most recent winehq tree, but it should be pretty easy to integrate in. It's not 100% complete by any means, but it has both GDI bitmap and DDraw support. We can vouch that it runs some of the DDraw samples, but beyond that, who knows. That said, the SDL driver should be a useful alternative to the ttydrv for testing purposes. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

6 8

Re: Driver critical section changes from CW
by Gerard Patel 29 Jan '02

29 Jan '02

At 10:11 AM 1/29/02 +0100, you wrote: >Running the program The 4th Coming after updating >today, >results into these messages : >fixme:win32:SetCriticalSectionSpinCount >critsection=0x7ff063b8: spincount=1000 not supported <snip> This patch is not yet applied, it can hardly be responsible. See documentation/cvs-regression for the complete procedure to make sure a particular patch has caused a regression. Gerard

1 0

Driver critical section changes from CW
by Duane Clark 29 Jan '02

29 Jan '02

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; }

2 2

Fwd: Total Annihilation
by Daniel Davis 29 Jan '02

29 Jan '02

Hi guys, I sent this to the wine-users list but didn't get any response so I thought maybe you could answer this. I am simply trying to figure out why Total Annihilation keeps terminating with a code 21. I would prefer to know where the list of errors is so that I can solve these on my own without needing to pester people all the time. :-) Daniel ---------- Forwarded Message ---------- Subject: Total Annihilation Date: Sun, 27 Jan 2002 13:40:38 -0500 From: Daniel Davis <planetes(a)cfl.rr.com> To: wine-users(a)winehq.com Hi everyone, I just started tinkering with wine on my system and everytime I try to run Total Annihilation it dies with a return (error) code 21. Is there a list of return codes anywhere in wine that can help me determine where this program and any others I try to run in the future are dying? Daniel -------------------------------------------------------

3 3

Sooo quiet...
by Dimitrie O. Paun 28 Jan '02

28 Jan '02

... I feel like starting a flamewar, just to get some traffic on this list :) Speaking of which, I figured I should rattle Alexandre's cage :) So here I go: Wine's been around for 8 (_eight_) years (how time flies)! It is my understanding that we're approaching the 1.0 status. I say, let's change the versioning scheme, just to give the outside world a feeling of progress. Really, I think the current scheme kindda hurts us on a PR level. We can start with something like 0.90.0. This should give us plenty numbers to the upcoming 1.0, don't you think? -- Dimi.

3 3

Compilation error
by Christian Schmitt 28 Jan '02

28 Jan '02

Hello, i have a strange problem compiling the newest wine version (20020122). The compilation process stops with an error message concerning freetype: make[2]: Entering directory `/usr/src/wine-20020122/dlls/gdi' gcc -c -I. -I. -I../../include -I../../include -I/usr/local/include/freetype2 -g -O2 -Wall -fno-strength-reduce -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o freetype.o freetype.c freetype.c:56: parse error before `library' freetype.c:56: warning: type defaults to `int' in declaration of `library' freetype.c:56: warning: data definition has no type or storage class freetype.c:74: parse error before `FT_Face' freetype.c:74: warning: no semicolon at end of struct or union freetype.c: In function `AddFontFileToList': freetype.c:81: `FT_Face' undeclared (first use in this function) freetype.c:81: (Each undeclared identifier is reported only once freetype.c:81: for each function it appears in.) freetype.c:81: parse error before `ft_face' freetype.c:89: warning: implicit declaration of function `FT_New_Face' freetype.c:89: `ft_face' undeclared (first use in this function) freetype.c:94: warning: implicit declaration of function `FT_IS_SFNT' freetype.c:95: warning: implicit declaration of function `FT_Done_Face' freetype.c:138: `FT_STYLE_FLAG_ITALIC' undeclared (first use in this function) freetype.c:139: `FT_STYLE_FLAG_BOLD' undeclared (first use in this function) freetype.c: In function `WineEngInit': freetype.c:193: warning: implicit declaration of function `FT_Init_FreeType' freetype.c: At top level: freetype.c:230: parse error before `OpenFontFile' freetype.c:231: warning: return-type defaults to `int' freetype.c: In function `OpenFontFile': freetype.c:232: `FT_Error' undeclared (first use in this function) freetype.c:232: parse error before `err' freetype.c:233: `TT_OS2' undeclared (first use in this function) freetype.c:233: `pOS2' undeclared (first use in this function) freetype.c:233: warning: statement with no effect freetype.c:234: `FT_Face' undeclared (first use in this function) freetype.c:234: parse error before `ft_face' freetype.c:237: `err' undeclared (first use in this function) freetype.c:237: `ft_face' undeclared (first use in this function) freetype.c:243: warning: implicit declaration of function `FT_Get_Sfnt_Table' freetype.c:243: `ft_sfnt_os2' undeclared (first use in this function) freetype.c:262: `ppem' undeclared (first use in this function) freetype.c:267: warning: implicit declaration of function `FT_Set_Pixel_Sizes' freetype.c: In function `WineEngCreateFontInstance': freetype.c:288: dereferencing pointer to incomplete type freetype.c:289: dereferencing pointer to incomplete type freetype.c:317: dereferencing pointer to incomplete type freetype.c: In function `WineEngAddRefFont': freetype.c:330: dereferencing pointer to incomplete type freetype.c:331: warning: control reaches end of non-void function freetype.c: In function `WineEngDecRefFont': freetype.c:339: dereferencing pointer to incomplete type freetype.c:342: dereferencing pointer to incomplete type freetype.c: In function `GetEnumStructs': freetype.c:353: dereferencing pointer to incomplete type freetype.c:355: dereferencing pointer to incomplete type freetype.c:356: dereferencing pointer to incomplete type freetype.c: In function `WineEngGetGlyphOutline': freetype.c:469: `FT_Face' undeclared (first use in this function) freetype.c:469: parse error before `ft_face' freetype.c:470: `FT_UInt' undeclared (first use in this function) freetype.c:472: `FT_Bitmap' undeclared (first use in this function) freetype.c:472: parse error before `ft_bitmap' freetype.c:478: `glyph_index' undeclared (first use in this function) freetype.c:480: warning: implicit declaration of function `FT_Get_Char_Index' freetype.c:480: `ft_face' undeclared (first use in this function) freetype.c:482: warning: implicit declaration of function `FT_Load_Glyph' freetype.c:482: `FT_LOAD_DEFAULT' undeclared (first use in this function) freetype.c:494: `ft_glyph_format_outline' undeclared (first use in this function) freetype.c:506: `ft_bitmap' undeclared (first use in this function) freetype.c:509: `ft_pixel_mode_mono' undeclared (first use in this function) freetype.c:512: warning: implicit declaration of function `FT_Outline_Translate'freetype.c:517: warning: implicit declaration of function `FT_Outline_Get_Bitmap' freetype.c: In function `WineEngGetTextMetrics': freetype.c:531: `FT_Face' undeclared (first use in this function) freetype.c:531: parse error before `ft_face' freetype.c:532: `TT_OS2' undeclared (first use in this function) freetype.c:532: `pOS2' undeclared (first use in this function) freetype.c:532: warning: statement with no effect freetype.c:533: `TT_HoriHeader' undeclared (first use in this function) freetype.c:533: `pHori' undeclared (first use in this function) freetype.c:533: warning: statement with no effect freetype.c:534: `FT_Fixed' undeclared (first use in this function) freetype.c:534: parse error before `x_scale' freetype.c:536: `x_scale' undeclared (first use in this function) freetype.c:536: `ft_face' undeclared (first use in this function) freetype.c:537: `y_scale' undeclared (first use in this function) freetype.c:539: `ft_sfnt_os2' undeclared (first use in this function) freetype.c:545: `ft_sfnt_hhea' undeclared (first use in this function) freetype.c:558: warning: implicit declaration of function `FT_MulFix' freetype.c:581: `FT_STYLE_FLAG_ITALIC' undeclared (first use in this function) freetype.c:586: warning: implicit declaration of function `FT_IS_FIXED_WIDTH' freetype.c:587: warning: implicit declaration of function `FT_IS_SCALABLE' freetype.c: In function `WineEngGetOutlineTextMetrics': freetype.c:602: `FT_Face' undeclared (first use in this function) freetype.c:602: parse error before `ft_face' freetype.c:604: `TT_OS2' undeclared (first use in this function) freetype.c:604: `pOS2' undeclared (first use in this function) freetype.c:604: warning: statement with no effect freetype.c:605: `TT_HoriHeader' undeclared (first use in this function) freetype.c:605: `pHori' undeclared (first use in this function) freetype.c:605: warning: statement with no effect freetype.c:606: `FT_Fixed' undeclared (first use in this function) freetype.c:606: parse error before `x_scale' freetype.c:613: `ft_face' undeclared (first use in this function) freetype.c:615: `family_nameW' undeclared (first use in this function) freetype.c:621: `style_nameW' undeclared (first use in this function) freetype.c:648: `x_scale' undeclared (first use in this function) freetype.c:649: `y_scale' undeclared (first use in this function) freetype.c:651: `ft_sfnt_os2' undeclared (first use in this function) freetype.c:658: `ft_sfnt_hhea' undeclared (first use in this function) freetype.c:704: `cp' undeclared (first use in this function) freetype.c:714: `spaceW' undeclared (first use in this function) freetype.c: In function `WineEngGetFontData': freetype.c:785: `FT_Face' undeclared (first use in this function) freetype.c:785: parse error before `ft_face' freetype.c:786: `TT_Face' undeclared (first use in this function) freetype.c:787: `SFNT_Interface' undeclared (first use in this function) freetype.c:787: `sfnt' undeclared (first use in this function) freetype.c:787: warning: statement with no effect freetype.c:788: parse error before `len' freetype.c:789: `FT_Error' undeclared (first use in this function) freetype.c:791: `ft_face' undeclared (first use in this function) freetype.c:794: `tt_face' undeclared (first use in this function) freetype.c:794: parse error before `ft_face' freetype.c:795: parse error before `)' freetype.c:798: `len' undeclared (first use in this function) freetype.c:807: `err' undeclared (first use in this function) make[2]: *** [freetype.o] Error 1 make[2]: Leaving directory `/usr/src/wine-20020122/dlls/gdi' make[1]: *** [gdi/libgdi32.so] Error 2 make[1]: Leaving directory `/usr/src/wine-20020122/dlls' make: *** [dlls] Error 2 Compilation failed, aborting install. I don't know what to do to solve this problem. I tried "./configure --disable-freetype" to no avail. I use Xfree86 4.1.0 (self compiled) on a Debian 2.2r2 system. Can anybody help me with this issue? I need a way to disable freetype or another solution. I hope somebody can help me. Bye Chris -- Linux - Cause life is too short for reboots

2 1

Re: CodeWeaver's patches
by Gerard Patel 28 Jan '02

28 Jan '02

At 01:57 AM 1/28/02 -0500, you wrote: >I have finished doing that with one exception: the ListView. This one will >require a lot more work due to the fact that it was extensively modified. >I will work on the listview.c file this week, as I have some of my own >changes that I need to cleanup and submit, as well as CW's changes. Speaking of listview, I have issues with your last changes : notification is broken. I can see it with Eudora 4, but I have a test app in Python that I can send you if you want. I attach the changes I did to get Eudora working again Note that the change in notify() is unrelated, I just noticed the problem when searching the notification problem. Also the following change - if (*ppszText == NULL) - *lpLVItem->pszText = '\0'; is not related to your changes, this was broken a very long time ago. It's just that it makes listview work again for columns > 0. If you think to send your changes soon, maybe you could use my changes or implement them to your liking. Else I can send them myself (if you don't object to my changes), as you prefer. Gerard

2 1

DOSfs - removable media drives.
by Keith Matthews 28 Jan '02

28 Jan '02

I noticed earlier today that DOSfs is not correctly handling removable media drives. In particular floppies will get a permissions error message regardless of the actual permissions if there is no media in the drive. Presumeably Jazz type drives would do the same. I have made the assumption that the fact that there is no media in the drive needs to be stored and have added a new value to the drive flags for this. If someone knows better that it cannot be used or clashes with something I have not spotted then please say so. ================================================================ Index: files/drive.c =================================================================== RCS file: /home/wine/wine/files/drive.c,v retrieving revision 1.64 diff -u -u -r1.64 drive.c --- files/drive.c 2002/01/13 01:44:00 1.64 +++ files/drive.c 2002/01/28 16:41:26 @@ -7,6 +7,7 @@ * Label & serial number read support. * (c) 1999 Petr Tomasek <tomasek(a)etf.cuni.cz> * (c) 2000 Andreas Mohr (changes) + * (c) 2002 Keith Matthews (changes) * */ @@ -508,21 +509,95 @@ #define DRIVE_SUPER 96 int fd; off_t offs; + struct stat dev_data; + uid_t user; + gid_t group; if (memset(buff,0,DRIVE_SUPER)!=buff) return -1; - if ((fd=open(DOSDrives[drive].device,O_RDONLY)) == -1) + + if (!DOSDrives[drive].device) { - struct stat st; - if (!DOSDrives[drive].device) - ERR("No device configured for drive %c: !\n", 'A'+drive); - else - ERR("Couldn't open device '%s' for drive %c: ! (%s)\n", DOSDrives[drive].device, 'A'+drive, - (stat(DOSDrives[drive].device, &st)) ? - "not available or symlink not valid ?" : "no permission"); - ERR("Can't read drive volume info ! Either pre-set it or make sure the device to read it from is accessible !\n"); + ERR("No Device Configured for drive %c: !\n",'A'+drive); PROFILE_UsageWineIni(); return -1; } + + if (( stat(DOSDrives[drive].device,&dev_data)) == -1) + { + if (errno == ENOENT || errno == ENOTDIR || errno == ELOOP || errno == ENAMETOOLONG ) + { + ERR("Device ('%s) Configured for drive %c: is not a valid device path!\n",DOSDrives[drive].device,'A'+drive); + } else if ( errno == EACCES ) + ERR("Permissions problem on device for drive %c: !\n", 'A'+drive); + PROFILE_UsageWineIni(); + return -1; + } else + { + user = getuid(); + group = getgid(); + if ( user == dev_data.st_uid) + { + /* We are running as the device owner - check those perms */ + if ( (dev_data.st_mode & S_IRUSR) == 0 ) + { + /* owner does not have read perms - stupid but */ + ERR("Permissions problem on device for drive %c: - user does not have read access !\n", 'A'+drive); + PROFILE_UsageWineIni(); + return -1; + } + } else if ( group == dev_data.st_gid ) + { + if ( (dev_data.st_mode & S_IRGRP) == 0 ) + { + /* group does not have read perms */ + ERR("Permissions problem on device for drive %c: - group does not have read access !\n", 'A'+drive); + PROFILE_UsageWineIni(); + return -1; + } + + } else if ( (dev_data.st_mode & S_IROTH) == 0 ) + { + /* not owning user or group and no perms */ + ERR("Permissions problem on device for drive %c: - effective user does not have read access !\n", 'A'+drive); + PROFILE_UsageWineIni(); + return -1; + + } + } + + if ((fd=open(DOSDrives[drive].device,O_RDONLY)) == -1) + { + if (DOSDrives[drive].type == DRIVE_REMOVABLE ) + { + /***************************************************************************** + * OK, we've checked just about everything we can, it's a removeable media + * device, so assume no media since that gives same response + * + * Wrong if not running as root and user does not have read to device but + * we've already checked for that above + * + **************************************************************************/ + + DOSDrives[drive].flags = DOSDrives[drive].flags | DRIVE_NO_MEDIA; + return 0; + +/* ++++++++++++++++ should we be down here for CD's also ? also what about Jazz drives etc ?+++++++++++++++++++++++ */ + + } else { + /**************************************************************************** + * + * Not removeable media device - must be permissions problem + * + ***************************************************************************/ + ERR("Couldn't open device '%s' for drive %c: ! (%s)\n", DOSDrives[drive].device, 'A'+drive, + "no permission"); + ERR("Can't read drive volume info ! Either pre-set it or make sure the device to read it from is accessible !\n"); + PROFILE_UsageWineIni(); + return -1; + + } + } + Index: include/drive.h =================================================================== RCS file: /home/wine/wine/include/drive.h,v retrieving revision 1.8 diff -u -u -r1.8 drive.h --- include/drive.h 2000/12/12 00:44:43 1.8 +++ include/drive.h 2002/01/28 16:41:57 @@ -19,6 +19,7 @@ #define DRIVE_CASE_PRESERVING 0x0008 /* Drive fs is case preserving */ #define DRIVE_FAIL_READ_ONLY 0x0010 /* Fail opening read-only files for writing */ #define DRIVE_READ_VOL_INFO 0x0020 /* Try to read volume info from the device? */ +#define DRIVE_NO_MEDIA 0x0040 /* no media in drive */ extern int DRIVE_Init(void); extern int DRIVE_IsValid( int drive ); -- Keith Matthews Frequentous Consultants - Linux Services, Oracle development & database administration

1 0

CodeWeaver's patches
by Dimitrie O. Paun 28 Jan '02

28 Jan '02

Hi people, As you already know, I've signed up for the task of breaking down CW's patches (office[12].diff), for the common controls (dlls/comctl32/*) I have finished doing that with one exception: the ListView. This one will require a lot more work due to the fact that it was extensively modified. I will work on the listview.c file this week, as I have some of my own changes that I need to cleanup and submit, as well as CW's changes. -- Dimi.

1 0

ReactOS/Mingw32 port
by Steven Edwards 28 Jan '02

28 Jan '02

Hello, I am in the process of merging our wine tree back in to the main WINE branch and have a few issues that need to be addressed: 1. Makefiles and Resources Alexandre: I know you said you might not accept our makefiles but I went ahead and sent them for your review, if you dont want to apply them no problem. Will you accept the .def's for the dlls as we cannot use the .specs? No big deal if not because we can keep them on our CVS. Also due to a bug in windress we cannot use the wine resources so we have to use binary resources for our port. Will you accept those? If not, once again no big deal we can keep the makefiles, resources and defs in our CVS tree. 2. Winsock.h problems I've been looking at what our guys changed in the wine headers vs the current wine headers and the current winsock.h seems to have compatiblity problems for non-posix-like platforms. Any suggestions on how to fix it for our port? 3. Everything else I'm still new to the whole programming thing so I'm open for suggestions from everyone. If anyone has a better way of doing the port rather then #ifdef/#endif let me know. I'm going to start submitting patches to the headers today. Thanks Steven Edwards _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

3 4

Managed windows with Wine frames
by Mike McCormack 28 Jan '02

28 Jan '02

Hi, This patch build's upon Ove's decorationless managed window patch. It removes the windowmanager frames from all managed windows, and uses Wine drawn frames as default. IMO it gives a better feel to the desktop... I haven't tested it extensively, but it seems to work with some apps such as Netscape, Acrobat, etc. Add "WMFrames"="Y" to .wine/config to restore the default managed behaviour. All comments welcome. Mike ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: Patch to make wcmd compile on mingw/reactos
by Francois Gouget 27 Jan '02

27 Jan '02

On Sun, 27 Jan 2002, Isolation wrote: > Changelog: > Changed wineman to main for mingw/reactos #ifdefs are not too popular in the Wine project :-) A better approach would be to just systematically change 'wine_main' to 'main' (in wcmdmain.c and wcmd.spec). We used wine_main as a workaround for a Wine problem in the past but the problem is gone so there is no reason to keep it that way. It would even be better to be able to use whatever entry-point the user wants in ReactOS but that's another issue and you can deal with it later. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In a world without fences who needs Gates?

2 1

Pajama Sam's unmanaged window
by Ori Pessach 27 Jan '02

27 Jan '02

Hi, I spent some time trying to hunt down the window management problems I reported a while ago (dialogs displayed by the game Pajama Sam appearing behind the main window, and sometimes not getting keyboard focus). I found that the game's main window simply wasn't managed. The game opens a window that covers the entire screen, and doesn't have a caption. is_window_managed(), in dlls/x11drv/window.c therefore returns FALSE for that window, and (I'm guessing here) since Wine is running in managed mode, it manages that window poorly. Switching desktops in KDE doesn't remove the window from the screen, it's impossible to get any window to display on top of the game window, and in general, several functions in x11drv/winpos.c behave badly when Wine has a mix of managed and unmanaged windows. Changing is_window_managed()'s default return value to TRUE makes the game behave much better, but not perfectly. The KDE panel stays on top of the game window - it can be hidden away, but Windows handles this differently, letting the game window obscure the task bar. I'm inclined to call this a KDE problem, rather than a Wine problem. Also, I don't know whether the tests in is_window_managed() cover all the cases in which a window should stay unmanaged. Right now, is_window_managed() tests for child windows and tool windows, and returns FALSE for those windows. Are there any other types of windows that shouldn't be managed? -Ori Pessach _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

2 2

Re: Fix for overlapped I/O using ReadFile/WriteFile
by lawson_whitney＠juno.com 27 Jan '02

27 Jan '02

On Sun, 27 Jan 2002, Tony Bryant wrote: > This patch fixes 2 problems ... > diff -r1.131 file.c > 1359c1359,1360 > < LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine) > --- > > LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine, Welcome to the "I didn't read the README" club. | If you add something, or fix a bug, please send a patch ('diff -u' | format preferred) to julliard(a)winehq.com or to the | wine-patches(a)winehq.com mailing list for inclusion in the next | release. | | -- | Alexandre Julliard | julliard(a)winehq.com Lawson

1 0

Re: SetEndOfFile fix
by Guy L. Albertelli 27 Jan '02

27 Jan '02

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

4 5

wine debug question
by Shane Shields 27 Jan '02

27 Jan '02

hi all im trying to debug a program in wine but im not having any luck as to where the problem is. most probably due to my inexperience with wine:-P. maybe you can help. i know this program works on another wine developers computer with no problems but not on mine. attached is the output from the wine debugger and the last few lines from -debugmsg +all (the original log is 20+mb). i cant decide whether its a memory read problem or file write problem or ole problem or my problem ;-). if you want to test the program its at locutus.all.at and is called superlotto. the program is in turkish but the instructions on the web site are in english (im an aussie living in turkey). i wrote this program in vb5. ive been having this problem from cvs 26122001 and have been trying that long to debug it. if you can help me with some pointers or solutions it would be greatly appreciated. i would like to fix it myself but im stuck. thanks in advance Shane Shields To drink the WINE of success you must first seek the sayings of source ps im seeking the source but im nowhere near getting drunk ;-P

1 0

Re: Once again - this time with feeling - and no wrapping...
by Francois Gouget 27 Jan '02

27 Jan '02

On Sun, 27 Jan 2002, Tony Bryant wrote: > ? patch.diff > Index: files/file.c > =================================================================== > RCS file: /home/wine/wine/files/file.c,v > retrieving revision 1.131 > diff -r1.131 file.c > 1359c1359,1360 > < LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine) > --- > > LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine, > > HANDLE hCompletionEvent) Please use unified diff. It's much more readable, more robust and the recommended format for Wine patches. See: http://wine.codeweavers.com/docs/wine-devel/patches.shtml#PATCH-FORMAT -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0

1 0

ReactOS/Mingw Patches
by Isolation 27 Jan '02

27 Jan '02

I have submitted diffs to wine-patches to build mingw/reactos. These diffs are only the makefiles and dll def's. I will working on extracting the patches need to compile in the next week. Thanks Steven

1 0

license issue: winebuild->libbfd
by clemens 26 Jan '02

26 Jan '02

hi! winebuild parses an nm symbol dump in order to get the lists of exported dll symbols from shared libraries. 1) nm isn't called with the -D option. without -D it will just dump regular symbols. this will work when winebuild is used when compiling wine, because the generated .so files will include both, regular symbols, and dynamic symbols. prepackaged wine installations will have their shared libraries stripped from any regular symbols leaving just dynamic symbols making winebuild useless on those systems. I modified tools/winebuild/import.c:read_export_symbols to call nm with the -D option. works fine for stripped shared libraries, but crashes for some reasons in the regular wine building process. 2) instead of touching ugly C parsing code and fixing the bug, i would have liked to do it the right way: utilize libbfd. the problem: libbfd is GPL. not LGPL. as far as i can see I'm unable to use libbfd from winebuild now unless winebuild would become GPL too. any hints to resolve this? clemens

1 0

Re: Tab Ctrl fix
by Dimitrie O. Paun 26 Jan '02

26 Jan '02

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.

1 0

Re: int 33
by Andreas Mohr 26 Jan '02

26 Jan '02

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/

1 0

Re: int 33
by Nog 26 Jan '02

26 Jan '02

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;

1 0

Filename parsing
by Duane Clark 26 Jan '02

26 Jan '02

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 */ {

1 0

Patch for OLEClipbrd_IDataObject_GetData
by Sander van Leeuwen 26 Jan '02

26 Jan '02

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

1 0

The cat is out of the bag (Lindows)
by Hetz Ben Hamo 26 Jan '02

26 Jan '02

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

1 1

cvs run
by lee johnson 26 Jan '02

26 Jan '02

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@imyourhandiman codewind]$ wine wine: error while loading shared libraries: libwine.so: cannot open shared object file: No such file or directory [codewind@imyourhandiman codewind]$ thx lee -====

2 1

Does Windows have one of these?
by Bill Medland 25 Jan '02

25 Jan '02

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

1 0

RE: Excessive clipping of text in listview
by Medland, Bill 25 Jan '02

25 Jan '02

> -----Original Message----- > From: Dimitrie O. Paun [mailto:dimi@cs.toronto.edu] > Sent: Friday, January 25, 2002 9:11 AM > To: Bill Medland > Cc: wine-devel(a)winehq.com > Subject: Re: Excessive clipping of text in listview > > > On Fri, 25 Jan 2002, Bill Medland wrote: > > > Does anyone know how we (again) broke the text in the large > icon display of > > listview? It seems to come and go as we develop. > > <blush>I probably broke it</blush> I know the feeling. (not surprising given the size of the delta; you ought to see what my last big one would have screwed up). > > > The symptom. Our application has a ListView window. As of > yesterday's cvs > > most of the text only displays about 2 or 3 pixels wide, > while a few are > > readable. > > Are you using Unicode or ANSI? Can I get access to the code > to test with? ANSI Do you have access to the Microsoft "rowlist" sample? If so then use that 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. > > > I am just backtracking but I'm in a rush (I have to put together > > a demo machine by yesterday) and I'd like to know how far > back to go. > > Tell me, is 1.106 OK? Most likely the patch 1.106 -> 1.107 broke it. It did work on 1/jan so it was probably your delta. > > > -- > Dimi. > Thanks for the rapid response Bill p.s. what is going on in DrawLargeItem with the ellipsification; it looks like it ellipsifies it and then throws the result away. 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.

3 6

RE: Excessive clipping of text in listview
by Medland, Bill 25 Jan '02

25 Jan '02

Panic over; the 20020101 version will do for now. > -----Original Message----- > From: Dimitrie O. Paun [mailto:dimi@cs.toronto.edu] > Sent: Friday, January 25, 2002 9:11 AM > To: Bill Medland > Cc: wine-devel(a)winehq.com > Subject: Re: Excessive clipping of text in listview > > > On Fri, 25 Jan 2002, Bill Medland wrote: > > > Does anyone know how we (again) broke the text in the large > icon display of > > listview? It seems to come and go as we develop. > > <blush>I probably broke it</blush> > > > The symptom. Our application has a ListView window. As of > yesterday's cvs > > most of the text only displays about 2 or 3 pixels wide, > while a few are > > readable. > > Are you using Unicode or ANSI? Can I get access to the code > to test with? > > > I am just backtracking but I'm in a rush (I have to put together > > a demo machine by yesterday) and I'd like to know how far > back to go. > > Tell me, is 1.106 OK? Most likely the patch 1.106 -> 1.107 broke it. > > > -- > Dimi. >

1 0

Excessive clipping of text in listview
by Bill Medland 25 Jan '02

25 Jan '02

Does anyone know how we (again) broke the text in the large icon display of listview? It seems to come and go as we develop. The symptom. Our application has a ListView window. As of yesterday's cvs most of the text only displays about 2 or 3 pixels wide, while a few are readable. I am just backtracking but I'm in a rush (I have to put together a demo machine by yesterday) and I'd like to know how far back to go. Bill

2 1

Re: Patch to improve Microsoft Office 2000 functionality
by Duane Clark 25 Jan '02

25 Jan '02

Jeremy White wrote: > ... > by getting it out now, maybe some other folks will help out <grin>. > I'll be happy to sync this to the current CVS, test it out with the apps I have, and chop it up into a series of patches, if no one else wants to take that on.

2 4

C++ Winelib problems
by Peter Hunnisett 25 Jan '02

25 Jan '02

Hello all, I've been tooling around with building a C++ application using Winelib and I've come across a couple of problems resulting from the use of global constructors. The problems can be reproduced with a simple C++ application which from a constructor calls a method which is resolved through a dll import. 1) If this program is the main program, wine_dll_set_callback has not yet been invoked so the __wine_dll_register call doesn't resolve the import list. The problem is that the constructors of the program are run immediately after the dll is registered which results in calling a non resolved import. This can be worked around by simply creating a non C++ stub which does a LoadLibrary/GetProcAddress on the real main exe. However I'm wondering if there is a good reason for needing to wait until after the main exe is loaded before being able to resolve imports? I must be missing something from my quick view of the code. 2) The order of running constructor execution and DLL entry point is incorrect. To show the problem assume you have foo.dll which imports bar.dll Present order for builtins: Load foo.dll Start to resolve foo.dll dependencies Start to resolve bar.dll dependencies Finsh resolving bar.dll dependencies Run bar.dll C++ constructors Finish resolving foo.dll dependencies Run foo.dll C++ constructors Run bar.dll DLL entry point Run foo.dll DLL entry point I actually haven't checked if PE images presently have the same problem since I don't know what triggers the ctor execution for a PE image. I assume that it's the running of the DLL entry point, but I don't know for sure. Hopefully I'll find the time at some point this week to whip up a test. The correct order: Load foo.dll Start to resolve foo.dll dependencies Start to resolve bar.dll dependencies Finsh resolving bar.dll dependencies Run bar.dll C++ constructors Run bar.dll DLL entry point Finish resolving foo.dll dependencies Run foo.dll C++ constructors Run foo.dll DLL entry point The problem seems reasonably simple enough to resolve but I'm sure that I'm missing something since my patch doesn't work for the present version of wine :(. I think that the problem is that there's an issue with inter DLL dependencies somewhere as it dies in SYSMETRICS_Init with a bad hdc. I've attached a patch which removes the recursive dep search from MODULE_DllProcessAttach and moves MODULE_DllProcessAttach from LoadLibraryExA into MODULE_LoadLibraryExA. Does this seem like a reasonable approach to take? Any problems with the patch? Ciao, Peter

2 2

Word97 (winver win95) - no luck with wine
by Heiko Nardmann 25 Jan '02

25 Jan '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! I have problems starting Word97 using wine-20020122. I use the following command line: env LANG=de_DE LD_LIBRARY_PATH=/opt/wine-20020122/lib:$LD_LIBRARY_PATH /opt/wine-20020122/bin/wine --winver=win95 winword.exe The working directory is: /usr/Windows_NT_Files/Programs/Office/Word Inside this directory there are the following files: - -rwxr----- 1 nardmann users 1108752 Jun 23 2001 MSO7DEU.DLL - -rwxr--r-- 1 nardmann users 3792896 Aug 18 2000 mso97.dll - -rw-r--r-- 1 nardmann users 31232 Jun 29 2001 Normal.dot - -rwxr--r-- 1 nardmann users 5337088 Mai 8 2001 winword.exe - -rwxr--r-- 1 nardmann users 1724416 Aug 18 2000 wwintl32.dll I do not use an installed Windows, only these files! I use Wine on SuSE Linux 7.1 remote using Exceed on Windows NT 4.0. Some time ago I got Word97 running using a CVS version but now I get the following: For language 'german' several language ids were found: de_DE - 0407; de_CH - 0807; de_LU - 1007; de_LI - 1407; Instead of using first in the list, suggest to define your LANG environment variable like this: LANG=de_DE fixme:keyboard:X11DRV_KEYBOARD_DetectLayout Your keyboard layout was not found! Using closest match instead (German keyboard layout without dead keys) for scancode mapping. Please define your layout in windows/x11drv/keyboard.c and submit them to us for inclusion into future Wine releases. See the Wine User Guide, chapter "Keyboard" for more information. wine: Unhandled exception, starting debugger... And nothing happens then ... I could add '--debugmsg +all' and provide gzipped file if necessary. How can I locate the problem? I tried to run Wine at the console of the Linux machine logged in as root instead of user nardmann. Then I see the splash screen and get a message box saying that my registry is corrupted and that I should restart the Word setup program. I cannot click the button in this message box. I am going to check the '--debugmsg +reg' output during the next week and compare it with the contents of the registry in the .wine directory and the registry on my local WinNT machine. Running Wine remote using Exceed but being root gives me the following in the shell: snsrv053:root[Word]#env LANG=de_DE LD_LIBRARY_PATH=/opt/wine-20020122/lib:$LD_LIBRARY_PATH /opt/wine-20020122/bin/wine --winver=nt40 winword.exe fixme:keyboard:X11DRV_KEYBOARD_DetectLayout Your keyboard layout was not found! Using closest match instead (German keyboard layout without dead keys) for scancode mapping. Please define your layout in windows/x11drv/keyboard.c and submit them to us for inclusion into future Wine releases. See the Wine User Guide, chapter "Keyboard" for more information. X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 1 (X_CreateWindow) Serial number of failed request: 27 Current serial number in output stream: 37 The display variable is set correctly. How can I debug this bug? - -- Heiko Nardmann (Dipl.-Ing.), h.nardmann(a)secunet.de, Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de), Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8URippm53PRScYygRAnAZAJ4tAWZzU+QnKaChlXFZtyvJJkLwhQCgsoUG WwRlq+Fb46jaQuZ7s0kHbAI= =ObqT -----END PGP SIGNATURE-----

1 0

C testing framework. ASCII/Unicode portable version
by Andriy Palamarchuk 24 Jan '02

24 Jan '02

Attached version of the C testing framework, which is implemented with using TCHAR.H macros, so it is portable between ASCII and Unicode platforms. Also implemented test which can be used to test ASCII and Unicode API. As I found out creating ASCII/Unicode portable code requires much more attention than creating plain ASCII-only code, probably the same level of difficulty as creation Unicode-only code. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

5 33

Re: Microsoft's version of "WINE"
by Srdjan Matovina -- Customer Engineering 23 Jan '02

23 Jan '02

They use MainWin from MainSoft Inc. See http://www.mainsoft.com >To: wine-devel(a)winehq.com >From: "Sander Wichers" <wichers(a)usa.net> >Subject: Microsoft's version of "WINE" >X-Priority: 3 >X-MSMail-Priority: Normal >X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 >X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 >X-BeenThere: wine-devel(a)winehq.com >X-Mailman-Version: 2.0 >List-Help: <mailto:wine-devel-request@winehq.com?subject=help> >List-Post: <mailto:wine-devel@winehq.com> >List-Subscribe: <http://www.winehq.com/mailman/listinfo/wine-devel>, <mailto:wine-devel-request@winehq.com?subject=subscribe> >List-Id: Wine Developer's List <wine-devel.winehq.com> >List-Unsubscribe: <http://www.winehq.com/mailman/listinfo/wine-devel>, <mailto:wine-devel-request@winehq.com?subject=unsubscribe> >List-Archive: <http://www.winehq.com/hypermail/wine-devel/> >Date: Wed, 23 Jan 2002 16:20:35 +0100 > >Hi, > >Maybe you guys already seen this, and it's old news for you... but i'll post >this anyway in case you didn't know. It can be a good thing to learn from. > >I do not own a SUN or a HP-UX system. But I was just interested how >microsoft implemented IE 4 / IE 5 on HP-UX and SUN. So I extracted their >installation files to disk. It seems that microsoft made their own version >of wine. It's amazing that they didn't modified IE to run on unix. Instead >they made the choice to emulate all the windows functionality. And compile >IE on that. Microsoft is ready to run their applications on linux. They have >a complete "system" libary full of ported functionality to SUN and HP-UX... >all the libaries are there, libkernel32.so etc.... It's also nice to see how >they seperated the resources from the binaries. and let the kernel deal with >these resource files. > >Has any one of you looked into these system libaries? Is this information >relevant to anyone? > >bye, > >Sander Wichers > > > > > > ==== Srdjan Matovina Sun Microsystems Inc. SunPS Integration Services/ Americas Customer Engineering srdjan.matovina(a)sun.com Ph.(905) 415-2883 Fax.(905) 477-0217

2 1

Privaleged instruction
by Nog 23 Jan '02

23 Jan '02

Hi, Just for the fun of it I tried to run the dos installer of Mechwarrior 2: Mercenaries. It didn't get too far as the installer crashed on an unhandeled Privileged instruction. According to winedbg the instruction is 0x0002:0x10000 push %cs. To see what the opcode of this instruction might be, I added a trace to the INSTR_EmulateInstruction. Looking at the trace I found that the instruction it was having to emulate was 0x00 which looks very wrong to me. But just to check I simply made that function return true if the instruction was 0x00 but this only seemed to make things worse, the exception still occured but the debugger didn't launch. What I would like to know is, is push %cs realy a Privileged instruction (which I think it might be)? Looking into why INSTR_EmulateInstruction doesn't get the right pointer, the offset looked too big to me. Shouldn't it roll over to the next segment after 0xffff? The problem with the way that it is now is that the following macro, which converts the segment offset pair to linear addresses cuts off the upper bits, which looks correct. #define PTR_REAL_TO_LIN(seg,off) \ ((void*)(((unsigned int)(seg) << 4) + LOWORD(off))) What I want to know is why the offset is so high? nog.

2 1

RE: runtest: new option -M for testing current module as builtin
by Patrik Stridvall 23 Jan '02

23 Jan '02

> On Wed, 23 Jan 2002, Patrik Stridvall wrote: > [...] > > BEGIN { > > require wine; > > &wine::module_native("wininet"); > > &wine::module_builtin("imm32", "msacm32"); > > } > > I am not sure any test should require the native version > of any dll. > > We cannot ship native dlls with Wine for obvious reasons, so requiring > the native dll would force Wine developpers to have a Windows > partition > installation around, and one configured for use in the tests. > Otherwise > they would not be able to run the tests, would they? > > I don't think that's good. Of course it shouldn't require it. It should simply skip parts of the test if the native version is not available. if(&wine::is_native("wininet")) { # Do native wininet tests } > Choosing to use a native dll is more up to the developper > to debug a > test. And then modifying the configuration file, as we usually do to > debug applications, should be simple and familiar enough. > > But maybe I misunderstood something. Well it allows us to automatically test a non-developer Windows installation directly under Linux without requiring him to reboot. Even developers make find it useful to quickly be able to modify the loadorder without having to modify his configuration. Sometimes what you want to test is quite subtle, like you have a function A in module B that calls function C in module D. Perhaps you want to test the robustness of Wines implementation of function A by testing it both with the native and the builtin version of D. If you have many such tests it would be a lot of unnessary manual work to switch D between native and builtin while testing B as builtin. Then perhaps somebody else have some use I haven't even though of. The main use will be I think to force tests to as the default test the builtin version since if you type "make test" in a directory you really expect to test the files in THAT directory, not the native version even if your ~/.wine/config specifies that.

1 0

Re: runtest: new option -M for testing current module as builtin
by Francois Gouget 23 Jan '02

23 Jan '02

On Wed, 23 Jan 2002, Patrik Stridvall wrote: [...] > BEGIN { > require wine; > &wine::module_native("wininet"); > &wine::module_builtin("imm32", "msacm32"); > } I am not sure any test should require the native version of any dll. We cannot ship native dlls with Wine for obvious reasons, so requiring the native dll would force Wine developpers to have a Windows partition installation around, and one configured for use in the tests. Otherwise they would not be able to run the tests, would they? I don't think that's good. Choosing to use a native dll is more up to the developper to debug a test. And then modifying the configuration file, as we usually do to debug applications, should be simple and familiar enough. But maybe I misunderstood something. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.

1 0

Re: wine/windows dialog.c
by Uwe Bonnes 23 Jan '02

23 Jan '02

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: Alexandre> ChangeSet ID: 1011730184150795614346862 CVSROOT: Alexandre> /opt/cvs-commit Module name: wine Changes by: Alexandre> julliard@wine2. 02/01/22 15:09:44 Alexandre> Modified files: windows : dialog.c Alexandre> Log message: Removed no longer used average width Alexandre> calculation. Well, for the encarta 99 setup this gives the same bad result as before. I have attached a gif of the dialog in question. The manual calculation with the corrections in my resent patch gave better results. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Microsoft's version of "WINE"
by Sander Wichers 23 Jan '02

23 Jan '02

Hi, Maybe you guys already seen this, and it's old news for you... but i'll post this anyway in case you didn't know. It can be a good thing to learn from. I do not own a SUN or a HP-UX system. But I was just interested how microsoft implemented IE 4 / IE 5 on HP-UX and SUN. So I extracted their installation files to disk. It seems that microsoft made their own version of wine. It's amazing that they didn't modified IE to run on unix. Instead they made the choice to emulate all the windows functionality. And compile IE on that. Microsoft is ready to run their applications on linux. They have a complete "system" libary full of ported functionality to SUN and HP-UX... all the libaries are there, libkernel32.so etc.... It's also nice to see how they seperated the resources from the binaries. and let the kernel deal with these resource files. Has any one of you looked into these system libaries? Is this information relevant to anyone? bye, Sander Wichers

1 0

Verbose tests ?
by Sylvain Petreolle 23 Jan '02

23 Jan '02

Hi, running programs/winetest/runtest -v -v -v -v -v tests/wine.pl or programs/winetest/runtest -vvvvv only reports : tests/wine.pl: 22 tests executed, 2 marked as todo, 0 failures. Is this the normal behavior or have I made something wrong ? ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Courrier : http://courrier.yahoo.fr

2 1

Open Letter to DOJ re Microsoft Settlement
by Dan Kegel 22 Jan '02

22 Jan '02

The proposed settlement in the Microsoft antitrust trial will probably be accepted by the judge unless a lot of people complain soon, even though it lacks any useful enforcement provisions and fails to prohibit many of Microsoft's anticompetitive practices. I've drafted an open letter to the Department of Justice to explain why the proposed settlement should not be accepted; it's at http://www.kegel.com/remedy/letter.html I'd be honored if you would read it, and consider signing it with me, or submitting your own comment to the DOJ. Either way, the federal deadline for public comment is Monday the 28th. For more information, see http://www.kegel.com/remedy/ See also Jeremy White's page http://www.codeweavers.com/~jwhite/tunney.html Sincerely, Dan Kegel

2 2

sparc solaris build
by Srdjan Matovina -- Customer Engineering 22 Jan '02

22 Jan '02

Hi, I've built wine-20011226 on sparc with the only one issue left open: The resource compiler wrc core dumps when hit the bitmap (BINRES) part of .rc file. There is an alignment problem inside convert_bitmap() in newstruc.c file. The alignment problem came out from BITMAPINFOHEADER struct. But this was just the beginning! I've commented out body of convert_bitmap() just to see what will happen when run libtest/hello test case. After running wineserver, the libtest/hello core with the same problem: Program terminated by signal BUS (invalid address alignment). This time at different place: RtlSecondsSince1970ToTime from ntdll.so (time.c) struct FILETIME. Obviously I'll have an alignment problem with every structure in general. Is there any guideline for this kind of problem? Thanks Srdjan

2 1

Re: [PATCH] Overlapped recv(), WSARecv()
by Martin Wilck 22 Jan '02

22 Jan '02

As you may see from the different email address, I am currently off work - I'll look deeper into your traces next week. Many thanks for generating them, anyway. >From a first glance, it seems that the app doesn't do overlapped recv(). (lpOverlapped & completion_func are always NULL), so there should actually be no difference (well I'm now using recvmsg() instead of recv(), and the overhead for 16 bit Winsock apps is definitely larger, but I cannot see why that should slow everything down that much). Perhaps I screwed up the blocking semantics of non-overlapped IO. Have you generated the traces under exactly the same conditions? Can you explain what exactly you did? Martin

3 7

Article about WINE on DesktopLinux.com
by Roland 22 Jan '02

22 Jan '02

Hello, I found a very interesting article about WINE there: http://www.desktoplinux.com/articles/AT5502857506.html I have to fully agree with that author, I think he is a real genius! :))) Roland

1 0

Re: Decorationless managed windows again
by Alexandre Julliard 21 Jan '02

21 Jan '02

Ove Kaaven <ovehk(a)ping.uio.no> writes: > The logic in this patch is now somewhat revised according to Alexandre's > comments. I did not make this configurable, though, thinking that if the > user's WM really is too old to support them, then he probably wouldn't > mind getting more top-level windows managed anyway... Top-level windows maybe not, but menus and tooltips with wm decorations are pretty annoying... so I applied it, but without the is_window_managed changes, we will need a better algorithm there. -- Alexandre Julliard julliard(a)winehq.com

2 4

Re: Some fixes for dumb X errors :-)
by Alexandre Julliard 21 Jan '02

21 Jan '02

Lionel Ulmer <lionel.ulmer(a)free.fr> writes: > PS for Alexandre: we once discussed how we could 'streamline' this X error > handling (ie to prevent doing the same kind of code at three different > locations in the Wine code). Did you progress on this issue or not ? Yes, here's what I came up with. Basically you have to wrap the call that might fail with X11DRV_expect_error/X11DRV_check_error. Would this work for what you need to do? Index: dlls/x11drv/x11drv_main.c =================================================================== RCS file: /opt/cvs-commit/wine/dlls/x11drv/x11drv_main.c,v retrieving revision 1.47 diff -u -r1.47 x11drv_main.c --- dlls/x11drv/x11drv_main.c 2001/11/30 23:15:32 1.47 +++ dlls/x11drv/x11drv_main.c 2002/01/21 18:58:48 @@ -63,6 +63,12 @@ static char *desktop_geometry; static XVisualInfo *desktop_vi; +static x11drv_error_callback err_callback; /* current callback for error */ +static Display *err_callback_display; /* display callback is set for */ +static void *err_callback_arg; /* error callback argument */ +static int err_callback_result; /* error callback result */ +static int (*old_error_handler)( Display *, XErrorEvent * ); + #define IS_OPTION_TRUE(ch) \ ((ch) == 'y' || (ch) == 'Y' || (ch) == 't' || (ch) == 'T' || (ch) == '1') #define IS_OPTION_FALSE(ch) \ @@ -97,12 +103,57 @@ } #endif /* NO_REENTRANT_X11 */ + +/*********************************************************************** + * X11DRV_expect_error + * + * Setup a callback function that will be called on an X error. The + * callback must return non-zero if the error is the one it expected. + * This function acquires the x11 lock; X11DRV_check_error must be + * called in all cases to release it. + */ +void X11DRV_expect_error( Display *display, x11drv_error_callback callback, void *arg ) +{ + wine_tsx11_lock(); + XSync( display, False ); + err_callback = callback; + err_callback_display = display; + err_callback_arg = arg; + err_callback_result = 0; +} + + +/*********************************************************************** + * X11DRV_check_error + * + * Check if an expected X11 error occurred; return non-zero if yes. + * Also release the x11 lock obtained in X11DRV_expect_error. + */ +int X11DRV_check_error(void) +{ + int ret = err_callback_result; + XSync( err_callback_display, False ); + err_callback = NULL; + wine_tsx11_unlock(); + return ret; +} + + /*********************************************************************** * error_handler */ -static int error_handler(Display *display, XErrorEvent *error_evt) +static int error_handler( Display *display, XErrorEvent *error_evt ) { - DebugBreak(); /* force an entry in the debugger */ + if (err_callback && display == err_callback_display) + { + if ((err_callback_result = err_callback( display, error_evt, err_callback_arg ))) + { + TRACE( "got expected error\n" ); + return 0; + } + } + if (synchronous) DebugBreak(); /* force an entry in the debugger */ + old_error_handler( display, error_evt ); return 0; } @@ -297,6 +348,7 @@ screen = DefaultScreenOfDisplay( display ); visual = DefaultVisual( display, DefaultScreen(display) ); root_window = DefaultRootWindow( display ); + old_error_handler = XSetErrorHandler( error_handler ); /* Initialize screen depth */ @@ -328,11 +380,7 @@ */ TSXOpenIM( display, NULL, NULL, NULL); - if (synchronous) - { - XSetErrorHandler( error_handler ); - XSynchronize( display, True ); - } + if (synchronous) XSynchronize( display, True ); screen_width = WidthOfScreen( screen ); screen_height = HeightOfScreen( screen ); Index: include/x11drv.h =================================================================== RCS file: /opt/cvs-commit/wine/include/x11drv.h,v retrieving revision 1.95 diff -u -r1.95 x11drv.h --- include/x11drv.h 2002/01/04 18:27:45 1.95 +++ include/x11drv.h 2002/01/21 18:59:08 @@ -391,7 +391,9 @@ extern void X11DRV_SetFocus( HWND hwnd ); extern Cursor X11DRV_GetCursor( Display *display, struct tagCURSORICONINFO *ptr ); -extern void X11DRV_expect_error( unsigned char request, unsigned char error, XID id ); +typedef int (*x11drv_error_callback)( Display *display, XErrorEvent *event, void *arg ); + +extern void X11DRV_expect_error( Display *display, x11drv_error_callback callback, void *arg ); extern int X11DRV_check_error(void); extern void X11DRV_register_window( Display *display, HWND hwnd, struct x11drv_win_data *data ); extern void X11DRV_set_iconic_state( WND *win ); -- Alexandre Julliard julliard(a)winehq.com

1 0

Some musings about DGA2 support in Wine...
by Lionel Ulmer 21 Jan '02

21 Jan '02

Hi all, After being prodded by people on #WineHQ to look at the current DGA2 problem in Wine (it it works fine for graphics, but does not accept any user input at all and needs to either kill Wine remotely or do the three finger salute to the X server), I found the following things : - the DGA2 code (in dlls/x11drv/dga2.c) used the gdi_display connection to open the framebuffer and setting-up all the input handling. But it was the thread->display connection that was used to process the events. This is a no-go as when DGA2 is entered, there is only one connection that receives the event, the one which has grabbed the frame buffer (thanks to Ove to remind me of the 'one connection per thread' thingy). - so I removed all the mentions to 'gdi_display' in dga2.c and replaced them by the current thread display and still no go (although I checked that the event processing in WaitForMultipleEvents and subsequent process_events was done on the correct display). Still no go. So I investigated a bit with a little test program : = I did first try setting up DGA2 in a separate display and then doing all the 'standard' processing on another display (that is Wine does with DGA2 set-up in the init function to test if DGA2 is available and then really use it in another thread). As my test application still was working fine, this was not the problem... = then, I saw in the logs some calls to X11DRV functions after we have entered DGA2 (some due to the DDraw stuff creating DIB sections and so on, some due to the application I think). After adding the same stuff in my test program (ie I created a window just after entering DGA2), I found that it perturbed the event processing (I still had motion events, but neither key presses nor button presses). - so, finally, just to try, I backed off my changes in dga2.c (ie I used again the gdi_display for all the set-up) and had the process_events function in windows/x11drv/event.c use gdi_display instead of data->display when DGA was used (by testing the DGAUsed variable). And now it seems to work just fine.... All this leads now to the 10 � (an Euro sign for all the people not having an iso8859-15 font :-) ) question : how to fix this 'properly' and not with the hack I just did ? The only somewhat 'clean' solution I found would be to create a display connection specifically used for DGA2 (thus we would be sure that no X calls would 'pollute' the link). And in process_events, if DGA2 is used, use this connection instead of the thread connection (we already have some DGA specific variables there, what would be one more :-)) ). After, the question would be how we are sure that it's the 'good' WaitForMultipleEvents that receives the events (if the application is multi-threaded and has multiple threads calling this function). Anyway, if people want just to play some games using DGA2, they can always use my hacky solutions I just described up there :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

2 2

Re: _UNICODE vs UNICODE
by Andriy Palamarchuk 21 Jan '02

21 Jan '02

Francois Gouget wrote: > On Fri, 18 Jan 2002, Andriy Palamarchuk wrote: > > Using macro name "UNICODE" instead of "_UNICODE" is a > > typo, right? > > No, not necessarily. Windows has both and dinput.h, > for instance, > uses UNICODE, not _UNICODE. > > But I have no idea why they have two. I did a little research and found in a few places information that UNICODE is used by Windows headers, _UNICODE is used by C-runtime/MFC headers. However I did not find official explanation of this. Some examples, including a few MSDN ones, define both. E.g. see: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wss/wss/_e… Can you tell now where we need to use which one? Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

2 1

Re: GetPrivateProfileInt*() fix
by Alexandre Julliard 21 Jan '02

21 Jan '02

Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > these functions were pretty much broken (overflow and signed/unsigned > behaviour), so I fixed almost every problem. Why did you add an exception handler? Do you have an app that passes garbage pointers to GetPrivateProfileInt? -- Alexandre Julliard julliard(a)winehq.com

1 0

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