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

Repeated: Breakage in -relay and -snoop
by Uwe Bonnes June 13, 2002

June 13, 2002

Hallo, since last week, e.g a commandline like "wine <xxx> --debugmsg -relay=RtlEnterCriticalSection" inhibits _any_ relay message to be logged. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

3 4

Re: FW: [ros-kernel] wine dll
by juergen.schmied＠debitel.net June 13, 2002

June 13, 2002

For now and a any thinkable time this won't work without native shell32, shlwapi, shdocvw and some more shell stuff since big parts of the user interface are in there. It would be more useful to replace just one dll at one time with a wine dll. If you like to test the shell stuff, there is a registry key somewhere to set a different shell - like winfile. juergen "Steven Edwards" <Steven_Ed4153(a)yahoo.com> schrieb: > tested system: windows 2000 server build 2195 > pc tested: AMD Athon XP 1600, 256 ram > > first copied all dll to the windows dir. and booted. > win2k dies durning the winlogon. somewhere... > restored: > * urlmon.dll > * oleaut32.dll > * odbc32.dll > * oledlg.dll > * olepro32.dll > * winnls.dll > windows died again. > > restored: wintrust.dll, comcat.dll, crtdll.dll > result : windows died > > restored: tapi32.dll > result: windows died > > restored: dciman32.dll, dinput.dll > result: windows died > > restored: imm32.dll > result: windows died > > restored: mapi32.dll > result: windows died > > restored: dplayx.dll, mpr.dll > result: windows died > > restored: netapi.dll > result: windows showed a dialog saying that libwine*.dll was not found. > > copied: libwine.dll, libwine_tsx11.dll, libwine_unicode.dll. > result: winlogon.exe reports: msgina.dll could not be loaded, a restart button > is found, so I press it... > > restored: comctl32.dll > result: * the same dialog openes > * mstask.exe, says it cannt find the procedure: PathFintExtensionW(), at shlwapi.dll > * dns.exe, says ir cannt find the procedure: DwEnumEntryDetails(), at rasapi32.dll > > restored: shlwapi.dll, rasapi32.dll > result: after gzilion years (two minutes?) windows loaded, no error reported > I logged in as administrator, explorer did not load. > I press alt-ctrl-del to bring the sequrity dialog. I choosed to run the > task manager. I choose File/New task, and a dialog saying that ordinal 135 was not found in > shdocvm.dll, pressed OK. I runned again explorer. It did not load. I run windows commander, > (the browse command worked fine). Windows commander load ok. Run from the task manager notepad, > loads OK, and wrote this :) > > put wine dll: comctl32.dll > result: winlogon.exe reports: msgina.dll could not be loaded, a restart button. > > restored comctl32.dll and run a few programs. > windows commander runs. > notepad runs > winamp runs > several programs from the systemroot run, and thease gave me errors. > > systomroot\setup.exe : procedure entry not found: CheckSumMappedFile()(a)imagehelp.dll > systomroot\sigverif.exe: procedure entry not found: ImageAddCertificate()(a)imagehelp.dll > systomroot\ntbooks.exe : the instruction at "0x64d2b8c6" referenced at "0x0000" could not be "read".. ok, cancel to debug... (the window title says hh.exe) > procedure entry not found: ImageAddCertificate()(a)imagehelp.dll > systomroot\rundll32.exe: procedure entry not found: ImageDirectoryEntryToData()(a)imagehelp.dll > >

1 0

FW: [ros-kernel] wine dll's on a real system. (Mingw Win2k)
by Steven Edwards June 13, 2002

June 13, 2002

If anyone is interested in the win2k test results then here they are. Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson -----Original Message----- From: reactos-kernel-admin(a)lists.sourceforge.net [mailto:reactos-kernel-admin(a)lists.sourceforge.net] On Behalf Of Diego Iastrubni Sent: Wednesday, June 12, 2002 10:55 AM To: reactos-kernel(a)lists.sourceforge.net Subject: [ros-kernel] wine dll's on a real system. Hello gang, I got the wine dll's from Steven and installed them on a win2k server I have, on a ADM Athlon XP1600, 256 ram, and servral gb of disk. I documented what I saw, and the results are not good. :-(, This is the first round, so I will be patient. a few notes: * windows dies means I see the screen getting black and I see the bios again * please ingnore the spelling/ grammar orros in the text attached. * if you can, you can tell me if there is a way to see which programs use which dll, that would make my life easier. - diego -- bureaucracy, n: A method for transforming energy into solid waste.

1 0

Fix for locale regression test failures ...
by Paul Millar June 12, 2002

June 12, 2002

Hi, The problem _seems_ to be the same problem with ole/old2nls.c in two places. In GetNumberFormatA, it was (line 3091 onward): if (lpFormat != NULL) [...] else { if (dwflags & LOCALE_NOUSEROVERRIDE) used_operation = USE_LOCALEINFO; else used_operation = USE_SYSTEMDEFAULT; } with an equivalent test in GetCurrencyFormatA (see line 3331 onward). Both these tests look wrong as the logic is screwed up (not setting LOCALE_NOUSEROVERRIDE => use system defaults). After sullying my hands with MSDN, I found the following references: http://msdn.microsoft.com/library/en-us/intl/nls_0rec.asp and http://msdn.microsoft.com/library/en-us/intl/nls_8a0k.asp for GetCurrencyFormat and GetNumberFormat respectively. Both have a passage like: > If lpFormat is NULL, you can specify LOCALE_NOUSEROVERRIDE to format the > string using the system default number format for the specified locale; > or you can specify zero to format the string using any user overrides to > the locale's default number format. Which suggests the reverse behaviour. AFAIK, MSDN docs have been found to be incorrect in the past, so does anyone know who's right? BTW, swapping both lines to: if (dwflags & LOCALE_NOUSEROVERRIDE) used_operation = USE_SYSTEMDEFAULT; else used_operation = USE_LOCALEINFO; does fixes both the fr_FR and en_GB locale failings and en_US continues to work. I'll submit a proper patch in a moment, but I thought it best put all the information in this email first. Cheers, ---- Paul Millar

1 0

Extremely preliminary BiDi patch
by Shachar Shemesh June 12, 2002

June 12, 2002

Attached is an extremely preliminary BiDi patch. Here are the things this patch contains, and the points I would love to hear the list's comments about. This patch is under the LGPL only, at this stage. Changes: * Fixed the heb.nls file so that LANG=he_IL will be accepted * Implemented a skeleton for GetFontLanguageInfo. o I have filled in the skeleton where I knew what to fill it with. I would guess that a lot of stuff is still missing. o I would apretiate input on the aprorpiatness of using GetTextCharsetInfo as the source of information. o I have removed the FIXME, but a lot of stuff is still unimplemented. I didn't quite know what to put there instead. * GetCharacterPlacementW - This is certanly one of the more overloaded functions in the Win32 set (Select object comes to mind as a competitor, and this one has way more execution flows throught it). So far, as far as I could tell, only the flow that matched Latin fonts was implemented. I have added some (very basic) reordering. I would like to hear your comments about the following points: o I followed the autodocumentation instructions. Is this at all still supported or required? o The algorythm I used is far from a good one. It still doesn't support right to left paragraphs, neutral boundry characters, and a bunch of other necessary stuff. All it does, at the moment, is make sure consecutive runs of one direction are, more or less, readable. o I have added a fastpath option when no work is necassary. When all that is supported is reordering, this may make sense. However, I am somewhat worried that when kerning, ligation, glyphing etc. are added, the fastpath will be meaningless. Opinions? * ExtTextOutW o I am calling GetFontLanguageInfo for each and every ExtTextOutW (which is a focus point for all Text rendering functions). What performance implications will that have? Don't forget that what I pay for in asking whether reordering is necessary, I get back in not calling GetCharacterPlacementW, and in not allocating a buffer. Then again, some Unicode fonts will suffer both allocation and no reordering. o I am calling the backend text printing function in two flows. One is using the allocated buffer used for GetCharacterPlacementW, and the other is the original (no point in allocating a buffer if no processing was done). Should I work hard to merge the two calls? o I am assuming that the backend driver will not perform any reordering. I am not sure how correct that assumption is under, say, KDE3 (Hetz?). These are all the questions for the time being. I also need some explanation regarding procedures. Which of the following three are enough, on their own, to cause the patch to be integrated: 1. Attaching it to a bug (assuming that I am the bug's owner) 2. Sending the patch to wine-devel 3. Sending the patch to wine-patches Obviously, 3 is enough on it's own. Assuming I have questions, however, is 2 enough on its own? Is 1 at all necessary if I'm doing 2 or 3? Is this message off topic on wine-devel? on wine-patches? Shachar Index: dlls/kernel/nls/heb.nls =================================================================== RCS file: /home/wine/wine/dlls/kernel/nls/heb.nls,v retrieving revision 1.3 diff -u -r1.3 heb.nls --- dlls/kernel/nls/heb.nls 19 May 2002 22:23:23 -0000 1.3 +++ dlls/kernel/nls/heb.nls 12 Jun 2002 19:34:02 -0000 @@ -128,6 +128,6 @@ /* LOCVAL(LOCALE_FONTSIGNATURE, "") */ LOCVAL(LOCALE_SISO639LANGNAME,"he") -LOCVAL(LOCALE_SISO3166CTRYNAME,"HE") +LOCVAL(LOCALE_SISO3166CTRYNAME,"IL") /* gregoriansk kalender */ Index: objects/font.c =================================================================== RCS file: /home/wine/wine/objects/font.c,v retrieving revision 1.74 diff -u -r1.74 font.c --- objects/font.c 4 Jun 2002 01:02:52 -0000 1.74 +++ objects/font.c 12 Jun 2002 19:34:04 -0000 @@ -2098,10 +2098,48 @@ /************************************************************************* * GetFontLanguageInfo (GDI32.@) */ -DWORD WINAPI GetFontLanguageInfo(HDC hdc) { - /* return value 0 is correct for most cases anyway */ - FIXME("(%x):stub!\n", hdc); - return 0; +DWORD WINAPI GetFontLanguageInfo(HDC hdc) +{ + FONTSIGNATURE fontsig; + static const DWORD GCP_DBCS_MASK=0x003F0000, + GCP_DIACRITIC_MASK=0x00000000, + FLI_GLYPHS_MASK=0x00000000, + GCP_GLYPHSHAPE_MASK=0x00000040, + GCP_KASHIDA_MASK=0x00000000, + GCP_LIGATE_MASK=0x00000000, + GCP_USEKERNING_MASK=0x00000000, + GCP_REORDER_MASK=0x00000060; + + DWORD result=0; + + GetTextCharsetInfo( hdc, &fontsig, 0 ); + /* We detect each flag we return using a bitmask on the Codepage Bitfields */ + + if( (fontsig.fsCsb[0]&GCP_DBCS_MASK)!=0 ) + result|=GCP_DBCS; + + if( (fontsig.fsCsb[0]&GCP_DIACRITIC_MASK)!=0 ) + result|=GCP_DIACRITIC; + + if( (fontsig.fsCsb[0]&FLI_GLYPHS_MASK)!=0 ) + result|=FLI_GLYPHS; + + if( (fontsig.fsCsb[0]&GCP_GLYPHSHAPE_MASK)!=0 ) + result|=GCP_GLYPHSHAPE; + + if( (fontsig.fsCsb[0]&GCP_KASHIDA_MASK)!=0 ) + result|=GCP_KASHIDA; + + if( (fontsig.fsCsb[0]&GCP_LIGATE_MASK)!=0 ) + result|=GCP_LIGATE; + + if( (fontsig.fsCsb[0]&GCP_USEKERNING_MASK)!=0 ) + result|=GCP_USEKERNING; + + if( (fontsig.fsCsb[0]&GCP_REORDER_MASK)!=0 ) + result|=GCP_REORDER; + + return result; } /************************************************************************* @@ -2235,11 +2273,31 @@ /************************************************************************* * GetCharacterPlacementW [GDI32.@] + * + * Retrieve information about a string. This includes the width, reordering, + * Glyphing and so on. + * + * RETURNS + * + * The width and height of the string if succesful, 0 if failed. + * + * BUGS + * + * All flags except GCP_REORDER are not yet implemented. + * Reordering is not 100% complient to the Windows BiDi method. + * Caret positioning is not yet implemented. + * Classes are not yet implemented. + * */ DWORD WINAPI -GetCharacterPlacementW(HDC hdc, LPCWSTR lpString, INT uCount, - INT nMaxExtent, GCP_RESULTSW *lpResults, - DWORD dwFlags) +GetCharacterPlacementW( + HDC hdc, /* Device context for which the rendering is to be done */ + LPCWSTR lpString, /* The string for which information is to be returned */ + INT uCount, /* Number of WORDS in string. */ + INT nMaxExtent, /* Maximum extent the string is to take (in HDC logical units) */ + GCP_RESULTSW *lpResults, /* A pointer to a GCP_RESULTSW struct */ + DWORD dwFlags /* Flags specifying how to process the string */ + ) { DWORD ret=0; SIZE size; @@ -2254,37 +2312,115 @@ lpResults->lpDx, lpResults->lpCaretPos, lpResults->lpClass, lpResults->lpGlyphs, lpResults->nGlyphs, lpResults->nMaxFit); - if(dwFlags) FIXME("flags 0x%08lx ignored\n", dwFlags); + if(dwFlags&(~GCP_REORDER)) FIXME("flags 0x%08lx ignored\n", dwFlags); if(lpResults->lpCaretPos) FIXME("caret positions not implemented\n"); if(lpResults->lpClass) FIXME("classes not implemented\n"); - /* FIXME: reordering not implemented */ - /* copy will do if the GCP_REORDER flag is not set */ - if(lpResults->lpOutString) - lstrcpynW(lpResults->lpOutString, lpString, uCount); - - nSet = (UINT)uCount; - if(nSet > lpResults->nGlyphs) - nSet = lpResults->nGlyphs; - - /* return number of initialized fields */ - lpResults->nGlyphs = nSet; - - if(lpResults->lpOrder) - { - for(i = 0; i < nSet; i++) - lpResults->lpOrder[i] = i; - } - - if (lpResults->lpDx) - { - int c; - for (i = 0; i < nSet; i++) - { - if (GetCharWidth32W(hdc, lpString[i], lpString[i], &c)) - lpResults->lpDx[i]= c; - } - } + nSet = (UINT)uCount; + if(nSet > lpResults->nGlyphs) + nSet = lpResults->nGlyphs; + + /* return number of initialized fields */ + lpResults->nGlyphs = nSet; + + if(dwFlags==0) + { + /* Treat the case where no special handling was requested in a fastpath way */ + /* copy will do if the GCP_REORDER flag is not set */ + if(lpResults->lpOutString) + lstrcpynW(lpResults->lpOutString, lpString, uCount); + + if(lpResults->lpOrder) + { + for(i = 0; i < nSet; i++) + lpResults->lpOrder[i] = i; + } + + } else + { + WORD *pwCharType; + int run_end; + /* Keep a static table that translates the C2 types to something meaningful */ + /* 1 - left to right + * -1 - right to left + * 0 - neutral + */ + static const int chardir[]={ 0, 1, -1, 1, 1, 1, -1, 1, 0, 0, 0, 0 }; + + WARN("The BiDi algorythm doesn't conform to Windows' yet\n"); + if( (pwCharType=HeapAlloc(GetProcessHeap(), 0, uCount * sizeof(WORD)))==NULL ) + { + SetLastError(ERROR_NOT_ENOUGH_MEMORY); + + return 0; + } + + /* Fill in the order array with directionality values */ + GetStringTypeW(CT_CTYPE2, lpString, uCount, pwCharType); + + /* The complete and correct (at list according to MS) BiDi algorythm is not + * yet implemented here. Instead, we just make sure that consecutive runs of + * the same direction (or neutral) are ordered correctly + */ + for( i=0; i<uCount; i+=run_end ) + { + for( run_end=1; i+run_end<uCount && + (chardir[pwCharType[i+run_end]]==chardir[pwCharType[i]] || + chardir[pwCharType[i+run_end]]==0); ++run_end ) + ; + + if( chardir[pwCharType[i]]==1 || chardir[pwCharType[i]]==0 ) + { + /* A LTR run */ + if(lpResults->lpOutString) + { + int j; + for( j=0; j<run_end; j++ ) + { + lpResults->lpOutString[i+j]=lpString[i+j]; + } + } + + if(lpResults->lpOrder) + { + int j; + for( j=0; j<run_end; j++ ) + lpResults->lpOrder[i+j] = i+j; + } + } else + { + /* A RTL run */ + if(lpResults->lpOutString) + { + int j; + for( j=0; j<run_end; j++ ) + { + lpResults->lpOutString[i+j]=lpString[i+run_end-j-1]; + } + } + + if(lpResults->lpOrder) + { + int j; + for( j=0; j<run_end; j++ ) + lpResults->lpOrder[i+j] = i+run_end-j-1; + } + } + } + + HeapFree(GetProcessHeap(), 0, pwCharType); + } + + /* FIXME: Will use the placement chars */ + if (lpResults->lpDx) + { + int c; + for (i = 0; i < nSet; i++) + { + if (GetCharWidth32W(hdc, lpString[i], lpString[i], &c)) + lpResults->lpDx[i]= c; + } + } if(lpResults->lpGlyphs) GetGlyphIndicesW(hdc, lpString, nSet, lpResults->lpGlyphs, 0); Index: objects/text.c =================================================================== RCS file: /home/wine/wine/objects/text.c,v retrieving revision 1.45 diff -u -r1.45 text.c --- objects/text.c 31 May 2002 23:06:53 -0000 1.45 +++ objects/text.c 12 Jun 2002 19:34:04 -0000 @@ -170,9 +170,35 @@ { if(PATH_IsPathOpen(dc->path)) FIXME("called on an open path\n"); - else if(dc->funcs->pExtTextOut) - ret = dc->funcs->pExtTextOut(dc->physDev,x,y,flags,lprect,str,count,lpDx); - GDI_ReleaseObj( hdc ); + else if(dc->funcs->pExtTextOut) + { + DWORD fontLangInfo=0; + if( !(flags&(ETO_GLYPH_INDEX|ETO_IGNORELANGUAGE)) && + ((fontLangInfo=GetFontLanguageInfo( hdc ))&(GCP_REORDER|GCP_GLYPHSHAPE)) ) + { + /* The caller did not specify that language processing was already done, + * and the font idetifies iteself as requiring language processing. + */ + GCP_RESULTSW gcp; + + gcp.lStructSize=sizeof(gcp); + gcp.lpOutString=HeapAlloc(GetProcessHeap(), 0, count*sizeof(WCHAR)); + gcp.lpOrder=NULL; + gcp.lpDx=NULL; + gcp.lpCaretPos=NULL; + gcp.lpClass=NULL; + gcp.lpGlyphs=NULL; + gcp.nGlyphs=0; + gcp.nMaxFit=0; + + GetCharacterPlacementW(hdc, str, count, 0, &gcp, GCP_REORDER ); + + ret = dc->funcs->pExtTextOut(dc->physDev,x,y,flags|ETO_IGNORELANGUAGE, + lprect,gcp.lpOutString,count,lpDx); + } else + ret = dc->funcs->pExtTextOut(dc->physDev,x,y,flags,lprect,str,count,lpDx); + } + GDI_ReleaseObj( hdc ); } return ret; }

1 0

O2 compilation option
by Shachar Shemesh June 12, 2002

June 12, 2002

Hi all, I found that using the default ./configure options, the Makefiles are generated with "-g -O2" compilation options. This combination doesn't make sense to me, as what use are debug options if I cannot trace execution in a debugger. My autoconfig knowledge is not deep enough to understand whether there is a command line option to remove the "O2" from the makefiles. For the time being, I have simply modified configure by hand. Can anyone tell whether there is any better option? Shachar

2 1

Re: NtQuerySystemTime alignment problem
by Andreas Mohr June 12, 2002

June 12, 2002

Hi, On Wed, Jun 12, 2002 at 09:58:19AM -0400, Gregg Mattinson wrote: > This patch fixes an alignment problem in NtQuerySystemTime which occurs when > called from RunningObjectTableImpl_Register. Did anyone ever mention that you're doing GREAT work ? It's really nice to see many portability fixes going in. Thanks ! -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

1 0

Re: Not finding basic libraries
by Medland, Bill June 12, 2002

June 12, 2002

"Aitor" <nonvalid(a)nonvalid.com> wrote in message news:<gMEN8.341472$4Q.2433837(a)telenews.teleline.es>... > Hi all, > > I am new to installing wine by hand, as I always trusted the installation > made by Mandrake, Redhat & co. > > I managed to run Lotus WordPro (as an example of complex app.) some time > ago, and got impressed. Since then (can't remember version!), I have had > problems with newer versions even to execute notepad. > > Today I have downloaded latest wine (unstripped-061202), installed like > rpm -i --nodeps --force wine-etc.etc. > (I use mandrake 8.2, by the way) > > then copied /etc/wine/config to /root/.wine/config, and edited it like this > (only appropriate sections): > > [Drive C] > "Path" = "/mnt/windows" > "Type" = "hd" > "Label" = "MS-DOS" > "Filesystem" = "win95" > > [wine] > "Windows" = "c:\\windows" > "System" = "c:\\windows\\system" > "Temp" = "e:\\" > "Path" = "c:\\windows;c:\\windows\\system;e:\\;e:\\test;f:\\" > "Profile" = "c:\\windows\\Profiles\\Administrator" > "GraphicsDriver" = "x11drv" > ; Wine doesn't pass directory symlinks to Windows programs by default. > ; Enabling this may crash some programs that do recursive lookups of a whole > ; subdir tree in case of a symlink pointing back to itself. > ;"ShowDirSymlinks" = "1" > "ShellLinker" = "wineshelllink" The DllOverrides section is quite important too. Does it say that gdi32 should be loaded builtin,native? (It is normally recommended that gdi32, kernel32, user32 are loaded builtin; I've never heard of anyone trying to run the native gdi32 and kernel32 under Wine) > > NOW /mnt/windows is where windows trylly resides (my windows partition). > For example: > > [root(a)mypc root]# ls -l /mnt/windows/windows/system/gdi32.dll > -rwxr-xr-x 1 root root 155648 may 5 1999 > /mnt/windows/windows/system/gdi32.dll* > [root(a)mypc root]# > > Finally, when I try to execute notepad.exe, I get: > > [root(a)mypc root]# cd /mnt/windows/windows > [root(a)mypc windows]# wine notepad.exe > err:module:PE_fixup_imports Module (file) GDI32.dll (which is needed by > C:\windows\system\shell32.dll) not found > err:win32:PE_LoadLibraryExA can't load C:\windows\system\shell32.dll > err:module:MODULE_LoadLibraryExA Loading of native DLL > C:\windows\system\shell32.dll failed (error 14), check this file. > err:module:PE_fixup_imports Module (file) SHELL32.dll (which is needed by > C:\windows\notepad.exe) not found > [root(a)mypc windows]# > > Why? What can I be doing wrong? Could it be a question of > capitals/noncapitals? if this is the case, in my opinion, Wine should STOP > being case sensitive, just as the whole 'DOS/VMM/Windows' thingy is... > > Aitor Try wine --debugmsg +module notepad.exe You may also find wine --debugmsg +module,+file notepad.exe 2>notepad.log useful Bill

1 0

RE: O2 compilation option
by Medland, Bill June 12, 2002

June 12, 2002

> -----Original Message----- > From: Shachar Shemesh [mailto:sun(a)consumer.org.il] > Sent: Tuesday, June 11, 2002 10:51 PM > To: wine-devel(a)winehq.com > Subject: O2 compilation option > > > Hi all, > > I found that using the default ./configure options, the Makefiles are > generated with "-g -O2" compilation options. This combination doesn't > make sense to me, as what use are debug options if I cannot trace > execution in a debugger. info gcc Basically it may do some weird stuff but it is usable Bill

1 0

locale tests failed
by Sylvain Petreolle June 12, 2002

June 12, 2002

../../programs/winetest/runtest -q -P wine -M kernel32.dll -T ../.. -p tests/kernel32_test.exe.so tests/locale.c && touch tests/locale.ok fixme:string:OLE_GetFormatA datelen = 0, returning 255 fixme:string:OLE_GetFormatA datelen = 0, returning 255 tests/locale.c:260: Test failed: GetNumberFormat with len=2 got 2 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx instead of 2,xx tests/locale.c:269: Test failed: GetNumberFormat got 2 353,00 instead of 2,353.00 tests/locale.c:214: Test failed: GetCurrencyFormat with len=0: got 8 instead of 7 tests/locale.c:219: Test failed: GetCurrencyFormat got 23xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx instead of $23.53 tests/locale.c:226: Test failed: GetCurrencyFormat got 23,53 ¤ instead of $23.53 tests/locale.c:227: Test failed: GetCurrencyFormat: got 8 instead of 7 make[2]: *** [tests/locale.ok] Erreur 6 make[2]: Quitte le répertoire `/home/wine/dlls/kernel' make[1]: *** [kernel/__test__] Erreur 2 make[1]: Quitte le répertoire `/home/wine/dlls' make: *** [dlls/__test__] Erreur 2 LANG is set to fr_FR, and the '¤' is, I think, the euro symbol.test is ok when LANG is set to en_US for example. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

4 5

Re: Problems converting DLL to unix SO with winelib
by List vmn June 12, 2002

June 12, 2002

Hi Martin, I finaly got the patch to work. The problem was with my mail client. I am now at the office and using eudora and things worked... A question, When I use the patched winemaker , I get a spec file with out any imports at all, even the ones specified on the command line. When I compile/link I get unresolved symbols. I then dont know what to do so I add the import lines back to the spec file and it links/compiles.... What am I missing here? What is your patch doing ? Thanks, Miguel At 17:17 7/6/2002 +0200, you wrote: >Am Fre, 2002-06-07 um 16.59 schrieb mfeitosa(a)vmn.com.br: > > > Here is the output... > >And here is mine: > >[martin(a)biker tools]$ cvs diff -u -r 1.39 winemaker >[martin(a)biker tools]$ cd .. >[martin(a)biker wine]$ patch -p0 --dry-run </tmp/winemaker.diff >patching file tools/winemaker >patching file documentation/winemaker.man >[martin(a)biker wine]$ > >Perhaps you have the wrong patch. I attach it. >Martin > >-- >Martin Wilck Phone: +49 5251 8 15113 >Fujitsu Siemens Computers Fax: +49 5251 8 20409 >Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com >D-33106 Paderborn http://www.fujitsu-siemens.com/primergy > > > >

3 2

winespy - a wine gui front-end for --debugmsg output
by max June 12, 2002

June 12, 2002

I got the first (... very first) winespy wine front-end running. You can download at www.veneto.com/winespy/winespy.tar.gz In INSTALL and README files you'll find shorts description of usage and, of course, bugs :) Any suggestion/help appreciated ! Regards Max

1 0

gdi functions as undefined symbol in libwine.so
by Sylvain Petreolle June 11, 2002

June 11, 2002

Hi, Marcus showed I probably have install problems. All symbols that are in gdi.exe dll are reported as undefined symbols in libwine.so fixme:win32:ELF_FindExportedFunction function AbortDoc not found: /usr/local/lib/libwine.so: undefined symbol: AbortDoc fixme:win32:ELF_FindExportedFunction function AbortPath not found: /usr/local/lib/libwine.so: undefined symbol: AbortPath Download CVS version from scratch and reinstall didn't fix the problem. Did someone else got the problem ? I actually don't see a way to fix it. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

RE: driver question
by Patrik Stridvall June 11, 2002

June 11, 2002

> On Tue, Jun 11, 2002 at 11:23:06PM +0300, Hetz Ben Hamo wrote: > > > I'm not an expert on licensing, and I thought to ask this > question here - I'm > > not trying to make any emails flame war - just need a > simple answer... > > > A friend of mine is toying with an idea to write a frame > buffer driver instead > > of the x11drv on wine, but he doesn't think his boss will > allow to release > > the code.. > > > Can he (legally) write the driver, bundle it with the > lgpl'd wine and sell > > it? or is this illegal? > > If the driver interfaces with the rest of Wine through a > clearly defined > library API, and his proprietary code is distributed as > separate object > code that can be relinked with Wine at runtime or at build time (i.e., > made available as either .o files or as a .so shared lib), > then this is > unquestionably permitted by the LGPL. True in general but unfortunately the Wine display driver API wouldn't IMHO be classified as a clearly defined API... So whether this is allowed is a little unclear to say the least.

2 1

self-registerable standard DLLs
by John K. Hohm June 11, 2002

June 11, 2002

I noticed that the attempt to test comcat.dll on Win98 failed because DllRegisterServer is a stub returning E_NOTIMPL. I have added the registry entries for the component categories manager to winedefault.reg, which should suffice for normal Wine installations. Despite this, is it generally acceptable to have actual code to register/unregister a standard COM server DLL in its Dll[Un]RegisterServer? It would be redundant for normal Wine, but hey, it's not big or complex.

4 5

driver question
by Hetz Ben Hamo June 11, 2002

June 11, 2002

Hi, I'm not an expert on licensing, and I thought to ask this question here - I'm not trying to make any emails flame war - just need a simple answer... A friend of mine is toying with an idea to write a frame buffer driver instead of the x11drv on wine, but he doesn't think his boss will allow to release the code.. Can he (legally) write the driver, bundle it with the lgpl'd wine and sell it? or is this illegal? Thanks, Hetz

2 1

Re: null midi device
by Eric Pouech June 11, 2002

June 11, 2002

> I was thinking: Couldn't one use timidity to make a fake midi device > that actually produces sound? That would be something. I thought about it. you need to use timidity 0.20i (the last one from the original author released under LGPL, the next ones are released under GPL). Then, to make it a real midi driver (in terms of Win32 API) which isn't a trivial task (for example, timidity pre-processes the full content of the MIDI file to be played, whilst a standard MIDI driver has to play midi notes on the fly...). I did start looking at that a long time ago, but without real results in so far. A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle ____________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Avec Voila Mail, consultez vos e-mails sur votre mobile Wap.

6 9

builtin oleaut32
by Ann and Jason Edmeades June 11, 2002

June 11, 2002

Hello, I have been doing some playing with builtin oleaut32 and a Visual Basic program I am trying to get working under wine with no-windows (well, as little as possible anyway). I noticed after copying some ocx files from windows, I was starting to trap due to unimplemented stubs inside oleaut32, and have started coding up just enough to get my application working. Every time I fix one issue, I find 2 others, so before I dive in too far has anyone else done any work in improving this area which hasnt been submitted, or is anyone actively working on this - or should I just continue? Currently I have: VarCmp support for BSTR and Integer variants VarAnd support for boolean variants only VarNot support for boolean variants only VarParseNumFromStr support for negative numbers VarNumFromParseNum support shorts VarDateFromUDate return value is incorrect VarNot support for boolean variants only Two other questions as I am still fairly new at Unix in general, let alone wine.... 1. What is the policy on patches - Is one big one with all changes for the same module ok? 2. What about tracing - While writing them I have added trace to show the parms and return values (relay just shows the rc whereas the actual return value is normally a third varient). Should I leave these in? Thanks Jason

2 1

RE: builtin oleaut32
by Medland, Bill June 11, 2002

June 11, 2002

> -----Original Message----- > From: Ann and Jason Edmeades [mailto:us(a)the-edmeades.demon.co.uk] > Sent: Tuesday, June 11, 2002 10:20 AM > To: wine devel > Subject: builtin oleaut32 > > > Hello, > > I have been doing some playing with builtin oleaut32 and a > Visual Basic > program I am trying to get working under wine with no-windows > (well, as > little as possible anyway). > > I noticed after copying some ocx files from windows, I was > starting to trap > due to unimplemented stubs inside oleaut32, and have started > coding up just > enough to get my application working. Every time I fix one > issue, I find 2 > others, so before I dive in too far has anyone else done any work in > improving this area which hasnt been submitted, or is anyone actively > working on this - or should I just continue? Basically that's what I noted too. I am sort of working in the area but I haven't even got everything working natively yet (since I started from a non-windows installation and it's hard to figure out what needs to be put in). I would suggest that the best solution is to submit small packages at regular intervals. > > Currently I have: > VarCmp support for BSTR and Integer variants > VarAnd support for boolean variants only > VarNot support for boolean variants only > VarParseNumFromStr support for negative numbers > VarNumFromParseNum support shorts > VarDateFromUDate return value is incorrect > VarNot support for boolean variants only > > Two other questions as I am still fairly new at Unix in > general, let alone > wine.... > 1. What is the policy on patches - Is one big one with all > changes for the > same module ok? > 2. What about tracing - While writing them I have added trace > to show the > parms and return values (relay just shows the rc whereas the > actual return > value is normally a third varient). Should I leave these in? Sounds a good idea. Presumably they are under the ole debug channel. If it gets ridiculous it might be worth adding a new debug channel. > > Thanks > Jason > > > Bill

1 0

Re: Linux patch for supporting shortcuts and symlinks on VFAT
by Brian Vincent June 11, 2002

June 11, 2002

> It seem that at least some people are against it inclusion so I > wonder whether we should support inclusion of the patch or not. I'd agree that doing it at the kernel level isn't the answer. You don't want to abstract that information away from the user. Plus, like Francois mentioned there's a bunch of cases where it's just not going to work. However, what would be interesting (if you're going to parse the .lnk file anyway) is to display it as a symlink, but not actually have it operate as a link. For instance: -rw-r--r-- 1 vinn power 22 Jun 11 09:16 junk -> c:\Program Files\bar At that point it becomes useful to parse large directories of .lnk files by simply reading the directory. Leave it up to the application (Wine, etc) to figure out how to translate the path. With proper error handling you could probably add it as a "feature" to every filesystem. </$.02> -brian

1 0

Re: FPU patch for bug 586
by Ove Kaaven June 11, 2002

June 11, 2002

On Tue, 11 Jun 2002, admiral coeyman wrote: > Ove Kaaven, > > > > On Mon, 10 Jun 2002, admiral coeyman wrote: > > > > > This patch adds the self-modifying code part of the FPU interrupts 34->3b and > > > moves int 3d into the winedos section. > > > > Oh, I've been meaning to reply, but hadn't got around to it yet... it > > makes no sense to use MapDosToLinear(MapRealToLinear()). It should be > > obvious from its name that MapRealToLinear already converted to a linear > > address, so that's all you need. And MapLinearToDos will probably *not* do > > what you want, you should change the real-mode pointer directly instead, > > as in general you just can't convert a linear address back to real mode. > > Otherwise, the code is probably OK... > > > I was unsure of the memory handling functions. Both of these functions report > that they return linear addresses, but I read one as a dos linear address and > the other as a wine linear address. It was a mistake on my part. I read it as > though I had to convert the seg:offset code to a dos linear address, then > convert it to a wine linear address. It may have made more sense to me if I > hadn't been worried about the addresses being in the wrong order. Well, the meanings of these address types are, if I remember right: Real = 16-bit real mode seg:ofs address Dos = 32-bit offset from DOSMEM_dosmem (aka DOSMEM_MemoryBase()) (unless it's above 1MB, then it's considered a linear pointer) (after the DOS restructure, DOSMEM_dosmem is always 0, which is probably why it worked for you) Linear = 32-bit linear pointer that you can dereference in Wine code I consider the "Dos" memory type pretty useless, there's almost never a reason to use it instead of linear memory or something... > What I read says that the stack's lowest address contains IP and the word > above that is the code segment for the return. IP:CS I'm not sure that I > could just point a segment:offset converting function at an address in that > format and get the linear address. Well, you can, as long as we stick to x86 (might be trickier if we were to write a CPU emulator, but I guess there would be lots of places to change then anyway). > I've done the reverse conversion be backing IP up 2 bytes. You have two versions of the Int3dHandler in your patch. One of them isn't changed... Anyway, if it helps, here's how I might have written your routine (without the error checking), if I thought that perhaps these interrupts are also used by win16 apps (otherwise the second CTX_SEG_OFF_TO_LIN(...) can be replaced with PTR_REAL_TO_LIN(stack[1], stack[0])) void FPU_ModifyCode(CONTEXT86 *context, BYTE Opcode) { WORD *stack = CTX_SEG_OFF_TO_LIN(context, context->SegSs, context->Esp) BYTE *code = CTX_SEG_OFF_TO_LIN(context, stack[1], stack[0]); code[-2] = 0x9b; code[-1] = Opcode; stack[0] -= 2; }

1 0

Re: GLU32 patch
by Marcus Meissner June 11, 2002

June 11, 2002

On Mon, Jun 10, 2002 at 11:52:34PM -0400, Vincent B?ron wrote: > The glu32 dll is now compliant with MSDN. It can be compiled with a > libGLU 1.1, but preferably by a libGLU 1.2. > > Changelog: > - Modified the glu32 prototypes to match MSDN. > - Made it work for libGLU 1.1 and 1.2. ... > -@ stdcall gluCheckExtension(str ptr) wine_gluCheckExtension Why is this function gone? And you will need to add checks for glu.h in configure.ac too. Ciao, Marcus

2 1

Problems converting DLL to unix SO with winelib
by List vmn June 11, 2002

June 11, 2002

Hello Wine-devel, I finaly got the expected results from my simple tests to get a winelib DLL and test application to work. I am pretty sure that I am still doing something wrong in these tests !!!!! Can somebody say if the below setup is correct and if not what would be the correct way to create a winelib "dll" and then call it from a winelib executable. I am using wine-20020509. =>I start with a simple DLL file called mytest.c and use winemaker to create a libmytest.so bash#cd ~/mytest.dll bash#ls mytest.c bash#cat mytest.c //mytest.c #include <windows.h> #include <stdio.h> BOOL APIENTRY DllMain(HINSTANCE hinstDLL , DWORD fdwReason, LPVOID lpvReserved ) { printf("DllMain called\n"); return TRUE; } void usefullFunction() { printf("Usefull function got called\n"); } //end of mytest.c bash#winemaker --dll --nomfc . <output suppressed> bash#cat libmytest.spec name mytest type win32 mode dll init DllMain import kernel32.dll import ntdll.dll bash# ./configure <output suppressed> bash# make && make install gcc -c -g -O2 -fPIC -D_REENTRANT -DWINELIB -I. -I/usr/local/include/wine -o mytest.o mytest.c ld -r mytest.o -o libmytest.tmp.o strip --strip-unneeded libmytest.tmp.o LD_LIBRARY_PATH="/usr/local/lib:$LD_LIBRARY_PATH" /usr/local/bin/winebuild -fPIC -L/usr/local/lib/wine -sym libmytest.tmp.o -o libmytest.spec.c -spec ./libmytest.spec gcc -c -g -O2 -fPIC -D_REENTRANT -DWINELIB -I. -I/usr/local/include/wine -o libmytest.spec.o libmytest.spec.c gcc -shared -Wl,-rpath,/usr/local/lib -Wl,-Bsymbolic -o libmytest.so mytest.o libmytest.spec.o -lwine -lwine_unicode -lwine_uuid -lm _list=""; for i in $_list; do (cd $i; make install) || exit 1; done _list=" "; for i in $_list; do install $i /usr/local/bin; done _list="libmytest.so"; for i in $_list; do install $i /usr/local/lib; done bash# #Now I have a /usr/local/lib/libmytest.so file \ #I think the next commands are wrong... bash# cd /usr/local/lib bash# cp libmytest.so wine/mytest.dll.so bash# ln -s wine/mytest.dll.so libmytest.dll.so bash# #This was done so that I can write \ # import mytest.dll \ # in a spec file and "register with wine" this so =>I now create a simple winelib application to call mytest called "callmytest" =>Call my test is defined in callmytest.c bash# cd ~/callmytest bash#ls callmytest.c bash# cat callmytest.c //start of callmytest.c #include "windows.h" extern usefullFunction(); int WINAPI WinMain(HINSTANCE a,HINSTANCE b,LPSTR c ,int d) { usefullFunction(); } //end of callmytest.c bash# winemaker --guiexe -imytest.dll -lmytest.dll . <output suppressed> bash# cat callmytest.spec name callmytest type win32 mode guiexe init WinMain import kernel32.dll import ntdll.dll import mytest.dll bash# ./configure <output suppressed> bash# make gcc -c -g -O2 -fPIC -D_REENTRANT -DWINELIB -I. -I/usr/local/include/wine -o callmytest.o callmytest.c ld -r callmytest.o -o callmytest.tmp.o strip --strip-unneeded callmytest.tmp.o LD_LIBRARY_PATH="/usr/local/lib:$LD_LIBRARY_PATH" /usr/local/bin/winebuild -fPIC -L/usr/local/lib/wine -sym callmytest.tmp.o -o callmytest.spec.c -spec ./callmytest.spec gcc -c -g -O2 -fPIC -D_REENTRANT -DWINELIB -I. -I/usr/local/include/wine -o callmytest.spec.o callmytest.spec.c gcc -shared -Wl,-rpath,/usr/local/lib -Wl,-Bsymbolic -o callmytest.so callmytest.o callmytest.spec.o -lmytest.dll -lwine -lwine_unicode -lwine_uuid -lm test -f callmytest || ln -s /usr/local/bin/wine callmytest bash# ./callmytest DllMain called Usefull function got called DllMain called QUESTION 1: I think that adding -imytest.dll -lmytest.dll to winemaker --guiexe -imytest.dll -lmytest.dll . is wrong. QUESTION 2: Is DllMain called when the DLL is loaded and then unloaded ? Can anyone help me on this? Thanks, Miguel Feitosa

1 0

Problems converting DLL to unix SO with winelib
by mfeitosa June 11, 2002

June 11, 2002

Hello Wine-devel, I finaly got the expected results from my simple tests to get a winelib DLL and test application to work. I am pretty sure that I am still doing something wrong in these tests !!!!! Can somebody say if the below setup is correct and if not what would be the correct way to create a winelib "dll" and then call it from a winelib executable. I am using wine-20020509. =>I start with a simple DLL file called mytest.c and use winemaker to create a libmytest.so bash#cd ~/mytest.dll bash#ls mytest.c bash#cat mytest.c //mytest.c #include <windows.h> #include <stdio.h> BOOL APIENTRY DllMain(HINSTANCE hinstDLL , DWORD fdwReason, LPVOID lpvReserved ) { printf("DllMain called\n"); return TRUE; } void usefullFunction() { printf("Usefull function got called\n"); } //end of mytest.c bash#winemaker --dll --nomfc . <output suppressed> bash#cat libmytest.spec name mytest type win32 mode dll init DllMain import kernel32.dll import ntdll.dll bash# ./configure <output suppressed> bash# make && make install gcc -c -g -O2 -fPIC -D_REENTRANT -DWINELIB -I. -I/usr/local/include/wine -o mytest.o mytest.c ld -r mytest.o -o libmytest.tmp.o strip --strip-unneeded libmytest.tmp.o LD_LIBRARY_PATH="/usr/local/lib:$LD_LIBRARY_PATH" /usr/local/bin/winebuild -fPIC -L/usr/local/lib/wine -sym libmytest.tmp.o -o libmytest.spec.c -spec ./libmytest.spec gcc -c -g -O2 -fPIC -D_REENTRANT -DWINELIB -I. -I/usr/local/include/wine -o libmytest.spec.o libmytest.spec.c gcc -shared -Wl,-rpath,/usr/local/lib -Wl,-Bsymbolic -o libmytest.so mytest.o libmytest.spec.o -lwine -lwine_unicode -lwine_uuid -lm _list=""; for i in $_list; do (cd $i; make install) || exit 1; done _list=" "; for i in $_list; do install $i /usr/local/bin; done _list="libmytest.so"; for i in $_list; do install $i /usr/local/lib; done bash# #Now I have a /usr/local/lib/libmytest.so file \ #I think the next commands are wrong... bash# cd /usr/local/lib bash# cp libmytest.so wine/mytest.dll.so bash# ln -s wine/mytest.dll.so libmytest.dll.so bash# #This was done so that I can write \ # import mytest.dll \ # in a spec file and "register with wine" this so =>I now create a simple winelib application to call mytest called "callmytest" =>Call my test is defined in callmytest.c bash# cd ~/callmytest bash#ls callmytest.c bash# cat callmytest.c //start of callmytest.c #include "windows.h" extern usefullFunction(); int WINAPI WinMain(HINSTANCE a,HINSTANCE b,LPSTR c ,int d) { usefullFunction(); } //end of callmytest.c bash# winemaker --guiexe -imytest.dll -lmytest.dll . <output suppressed> bash# cat callmytest.spec name callmytest type win32 mode guiexe init WinMain import kernel32.dll import ntdll.dll import mytest.dll bash# ./configure <output suppressed> bash# make gcc -c -g -O2 -fPIC -D_REENTRANT -DWINELIB -I. -I/usr/local/include/wine -o callmytest.o callmytest.c ld -r callmytest.o -o callmytest.tmp.o strip --strip-unneeded callmytest.tmp.o LD_LIBRARY_PATH="/usr/local/lib:$LD_LIBRARY_PATH" /usr/local/bin/winebuild -fPIC -L/usr/local/lib/wine -sym callmytest.tmp.o -o callmytest.spec.c -spec ./callmytest.spec gcc -c -g -O2 -fPIC -D_REENTRANT -DWINELIB -I. -I/usr/local/include/wine -o callmytest.spec.o callmytest.spec.c gcc -shared -Wl,-rpath,/usr/local/lib -Wl,-Bsymbolic -o callmytest.so callmytest.o callmytest.spec.o -lmytest.dll -lwine -lwine_unicode -lwine_uuid -lm test -f callmytest || ln -s /usr/local/bin/wine callmytest bash# ./callmytest DllMain called Usefull function got called DllMain called QUESTION 1: I think that adding -imytest.dll -lmytest.dll to winemaker --guiexe -imytest.dll -lmytest.dll . is wrong. QUESTION 2: Is DllMain called when the DLL is loaded and then unloaded ? Can anyone help me on this? Thanks, Miguel Feitosa

1 0

RE: Linux patch for supporting shortcuts and symlinks on VFAT
by Patrik Stridvall June 11, 2002

June 11, 2002

> On Tue, 11 Jun 2002, Patrik Stridvall wrote: > [...] > > However it would be nice be nice to handle .lnk files as symlinks > > somehow. > > I'm not sure this is very useful, Well, just a feeling, but I have always been irritated about that the .lnk files are not real symlinks. Wine is not only supposed to be as good as Windows but also better if possible. > especially since few > symlinks will be > supported in any case. For instance in his proposal he ignores: > * all symlinks to absolute paths. That would be pretty much all > symlinks created under windows Yes. However you could have a drive table like echo /windows-c-drive > /proc/windows/drive/c echo /windows-d-drive > /proc/windows/drive/d So the kernel could do the look up. BTW this would also means that Wine could read /proc/windows/drive and map the drives. > * all UNC symlinks except those to \\localhost. But don't these paths > have a drive letter too? Even worse they have the first part after \\localhost should be the name of the share so that means that we need to have a series of /proc/windows/share directories or something as well... > * I guess he would also ignore the command line options > specified in shortcuts to executables > * and also the current directory Hmm. Well, that is a problem as well. Perhaps you could link to some sort of autogenerated shell script in /proc/windows/links say you access /mnt/c/test.lnk and you get a shell script in /proc/windows/links/mnt/c/test.lnk or something that /mnt/c/test.lnk symlinks to. > * and the icon of course. Which then means tools like konqueror or > nautilus cannot extract the icon either unless they make use of the > proposed ioctl hack. I don't consider this a problem. However solving the other problem is probably to ugly eventhough they are solvable in some meaning. > And if the goal is to be able to create symlinks on a filesystem that > does not support them, I believe the right way to do so would > be to have > a module sit on top of the file system that would do things > ala umsdos. > This would for instance allow one to also get things like ownership, > file permissions, device files, socket files, etc. And if you > are going > to use a VFAT filesystem as a regular Unix filesystem, having > permissions at least while in Linux seems like it would be a very good > thing. Indeed. It would be better if it was generalized somehow. Hmm... > > > * on Windows if you open("foo.lnk") you get the .lnk > files, not the > > > file it 'points' to. On Linux you would get the file it points to > > > instead which is a different behavior. > > > > True. However we could check if the extension is .lnk in OpenFile > > as friends and then call special funcitons like readlink to read the > > file. But it probably would be a too ugly hack to be worth it. > > Yes that's the soluti^H^H^H^H ugly hack that was suggested as a > workaround. It would probably involve an ioctl of some sort > though here > we are talking about reading the content of a file, not just > a couple of > metadata bits, not sure how ioctls handle such things (maybe > that's not > a problem, I'm not very familiar with ioctls). Doing it is not the problem. Accepting the overhead and the ugly hack is the real problem... > The other issue is that this workaround is not implemented > yet so we may > get stuck in a bad place for a while. True. > [...] > > Anyway, the big question seem to be whether we should > oppose the patch > > or not. It might could trouble for Wine is such a feature > exists some > > user might active it so we have to handle that case. > > It is proposed as the default behavior. This means it would likely end > up as the default in most distributions, so many users will > be hit by it > even if they did not activate it. > > I definitely oppose it. I believe it is not only harmful to Wine, but > also the wrong thing for Linux. As the default behavior I also oppose it. Unfortunely I very much fear that I won't be possible to do it in an acceptable way at all...

1 0