[Bug 10467] New: Making Microsoft .NET 2.0 to work in wine, based on example app FastMD5 1.4 for NET 2.0
http://bugs.winehq.org/show_bug.cgi?id=10467
Summary: Making Microsoft .NET 2.0 to work in wine, based on example app FastMD5 1.4 for NET 2.0 Product: Wine Version: CVS/GIT Platform: PC URL: http://www.paehl.de/english.php OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-dotnet AssignedTo: wine-bugs@winehq.org ReportedBy: focht@gmx.net
Hello,
this bug id exists for the sole purpose of showing my little journey of getting .NET 2.0 to work in wine.
This topic does *NOT* cover the MONO project in any way. The windows version of MONO is covered by other bug reports.
DISCLAIMER: This is just a first step which aims at major show stoppers. There are *many* issues left when it comes to managed (JIT) vs. unmanaged (native) API code bridging. To iron out all the bugs, many different applications are needed which cover the whole range of .NET Framework.
I randomly chose a simple .NET 2.0 app which uses plain system.windows.forms stuff (no fancy controls/interop).
--- snip --- http://www.paehl.de/fastmd5_net20.zip
FASTMD5 create very fast with low CPU use a MD5 hash. Required .NET 1.1 or 2.0 --- snip ---
Just as foreword: yes, it plain sucks to debug mixed code in wine (managed + unmanaged) because the tools required don't work reliable (or at all) due to several wine bugs/design problems.
Prerequisite: successful installation of .NET 2.0 Framework and wine-0.9.49 (or GIT)
---------- If you start .NET apps they will fail with stack overflows and some exceptions thrown. The exception type tells us what we are dealing with: 0xe0434f4d For the uninitiated: this an exception type exclusively thrown by .NET common language runtime (CLR).
Using my specially hacked wine to run tools like windbg one can get a raw estimate by looking at native method callstack:
--- snip --- 0:000> sxe clr .. 0:000> .load clr20\sos.dll .. 0:000> g .. 0:000> kb ChildEBP RetAddr Args to Child WARNING: Stack unwind information not available. Following frames may be wrong. 0034efb8 79f97065 e0434f4d 00000001 00000001 KERNEL32!RaiseException+0x78 0034f018 7a0945a4 00a11cb4 00000000 00000000 mscorwks!RaiseTheExceptionInternalOnly+0x226 0034f0dc 02fa364b 00000000 0000007f 0034f138 mscorwks!JIT_Throw+0xd0 0034f1d8 79e88f63 00000000 0012e0f8 0034f22c 0x2fa364b 0034f1f8 79e88f63 00000000 00000000 0016b200 mscorwks!CallDescrWorker+0x33 0034f210 79e88ee4 0034f2e8 00000002 0034f2b0 mscorwks!CallDescrWorker+0x33 .. --- snip ---
JIT code is at 0x2fa364b which transfers managed exceptions using mscorwks!JIT_Throw() to native code/OS.
Lets look at CLR exception info...
--- snip --- 0:000> !PrintException Exception object: 00a11cb4 Exception type: System.TypeInitializationException Message: The type initializer for 'System.Globalization.TextInfo' threw an exception. InnerException: <none> StackTrace (generated): <none> StackTraceString: <none> HResult: 80131534 --- snip ---
And the managed code callstack...
--- snip --- 0:000> !ClrStack OS Thread Id: 0xf (0) ESP EIP 0034f040 7b8414d8 [HelperMethodFrame: 0034f040] 0034f0e4 02fa364b System.Globalization.TextInfo.GetNativeTextInfo(Int32) 0034f114 02fa3511 System.Globalization.TextInfo.get_InvariantNativeTextInfo() 0034f140 02fa193d System.String.Compare(System.String, Int32, System.String, Int32, Int32, System.StringComparison) 0034f16c 02fa15a1 System.Security.Util.URLString.PreProcessForExtendedPathRemoval(System.String, Boolean) 0034f184 02fa10b0 System.AppDomainSetup.NormalizePath(System.String, Boolean) 0034f1a4 02fa06d6 System.AppDomainSetup.SetupDefaultApplicationBase(System.String) 0034f1bc 02fa02cc System.AppDomain.SetupFusionStore(System.AppDomainSetup) 0034f1d4 02fa01fa System.AppDomain.SetupDomain(Boolean, System.String, System.String) 0034f42c 79e88f63 [GCFrame: 0034f42c] 0034f9e0 79e88f63 [DebuggerClassInitMarkFrame: 0034f9e0] --- snip ---
Some native method call in GetNativeTextInfo() seems to be the culprit. For many (string) resource based stuff to work, a unicode OS casing table is required. The table for the invariant version is built from external .NLS file. To make story short: wine does not ship the default case mapping table for unicode characters: "l_intl.nls". This is a "must" requirement and failure results in early TypeInitializationException while setting up default application domain.
Short fix: copy the file from your windows system32 directory to wine system32. Long run fix: let wine generate/install this file. Not a big deal.
Now simple .NET _console_ based apps (like "Hello World") will work. ---------------------------------------
Stay tuned, more goodies to come ...
Regards
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #1 from Anastasius Focht focht@gmx.net 2007-11-16 07:05:45 --- Created an attachment (id=9195) --> (http://bugs.winehq.org/attachment.cgi?id=9195) expose PEB loader lock to make .NET framework (ui) to work
Hello,
lets make further steps in this mine field :-)
Prerequisite:
1) wine-0.9.49 (or GIT) 2) successful installation of .NET 2.0 Framework 3) "l_intl.nls" copied from windows installation to wine system32
----
With that stuff in place, starting .NET gui apps will immediately lead to a crash.
--- snip --- 0:000> .exr -1 ExceptionAddress: 7a2bd897 (mscorwks!AuxUlibIsDLLSynchronizationHeld+0x00000074) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 00000000 Parameter[1]: 0000000c Attempt to read from address 0000000c --- snip ---
Not a CLR exception this time. Looks like ordinary NULL ptr dereference. But just in case let's look at CLR stack:
--- snip --- 0:000> !ClrStack OS Thread Id: 0xf (0) ESP EIP 0034f128 7a2bd897 [NDirectMethodFrameGeneric: 0034f128] System.Windows.Forms.UnsafeNativeMethods.IntCreateWindowEx(Int32, System.String, System.String, Int32, Int32, Int32, Int32, Int32, System.Runtime.InteropServices.HandleRef, System.Runtime.InteropServices.HandleRef, System.Runtime.InteropServices.HandleRef, System.Object) 0034f16c 039b44a5 System.Windows.Forms.UnsafeNativeMethods.CreateWindowEx(Int32, System.String, System.String, Int32, Int32, Int32, Int32, Int32, System.Runtime.InteropServices.HandleRef, System.Runtime.InteropServices.HandleRef, System.Runtime.InteropServices.HandleRef, System.Object) 0034f1a8 039b089b System.Windows.Forms.NativeWindow.CreateHandle(System.Windows.Forms.CreateParams) 0034f228 02fafe53 System.Windows.Forms.Control.CreateHandle() 0034f288 02fae08b System.Windows.Forms.Application+MarshalingControl..ctor() 0034f290 02fadfea System.Windows.Forms.Application+ThreadContext.get_MarshalingControl() 0034f2c0 02fad783 System.Windows.Forms.WindowsFormsSynchronizationContext..ctor() 0034f2d0 02facec9 System.Windows.Forms.WindowsFormsSynchronizationContext.InstallIfNeeded() 0034f2fc 02fa9374 System.Windows.Forms.Control..ctor(Boolean) 0034f370 02fa8176 System.Windows.Forms.ScrollableControl..ctor() 0034f380 02fa8046 System.Windows.Forms.ContainerControl..ctor() 0034f390 02fa7e69 System.Windows.Forms.Form..ctor() 0034f3c8 02fa7132 Projekt2.WinForm..ctor() 0034f3d0 02fa710c Projekt2.WinForm.Main() 0034f5e4 79e88f63 [GCFrame: 0034f5e4] --- snip ---
Ok, somewhere after UnsafeNativeMethods.IntCreateWindowEx() (= native code transition) it crashes. Lets see native code callstack...
--- snip --- 0:000> kb ChildEBP RetAddr Args to Child 0034e98c 005704ea 0034e998 00570472 0012e100 mscorwks!AuxUlibIsDLLSynchronizationHeld+0x74 WARNING: Frame IP not in any known module. Following frames may be wrong. 0034e9a8 6043855a 00050056 00000024 00000000 0x5704ea 0034e9d8 60438bfe 00570472 00050056 00000024 user32!DeferWindowPos+0x2ea 0034ea18 6043de41 00050056 00000024 00000000 user32!DeferWindowPos+0x98e 0034ea58 60405e8a 00050056 00000024 00000000 user32!CallWindowProcA+0x1d1 0034eac8 60408dc2 0034ebe4 00000001 00000001 user32!GetMessagePos+0xda 0034eb28 6040923a 00000003 6045755e 00000001 user32!PeekMessageA+0xca2 0034eb68 60435228 00050056 00000024 00000000 user32!SendMessageW+0x4a 0034ec28 605e75f7 00050056 0034ed88 0034ed80 user32!WINPOS_GetMinMaxInfo+0x238 0034eda8 604321a7 00050056 0034f018 00000001 winex11!CreateWindow+0x327 0034f008 60433a9b 0000013e 0012e100 00000000 user32!SetWindowLongW+0x537 0034f048 79ef064c 00000000 00a14ee8 00000000 user32!CreateWindowExW+0x5b 0034f0e4 009ca83b 0012e100 0034f128 ff3b682a mscorwks!NDirectGenericStubReturnFromCall 0034f110 039b44a5 0034f1c8 00a14acc 00a14a8c 0x9ca83b 0034f16c 039b089b 00000000 00000000 11000000 0x39b44a5 0034f220 02fafe53 00a13e00 0000000e 0034f278 0x39b089b 0034f280 02fae08b 00a13e00 02fadfea 00a13a20 0x2fafe53 0034f2b8 02fad783 00000001 00a13928 00000000 0x2fae08b 0034f3d0 79e88f63 79e7c2ca 0034f414 0034f460 0x2fad783 0034f3d4 79e7c2ca 0034f414 0034f460 79e88ee4 mscorwks!CallDescrWorker+0x33 .. --- snip ---
Debugging the native code further, one comes to following code snippet.. I commented some parts for better readability:
--- snip --- mov eax, large fs:18h ; return the TEB address mov eax, [eax+30h] ; return the PEB address mov eax, [eax+0A0h] ; PEB+0xA0 -> void *LoaderLock -> PRTL_CRITICAL_SECTION LoaderLock push 1 add eax, 0Ch ; PEB->LoaderLock.OwningThread .. cmp dword ptr [eax], 0 ; PEB->LoaderLock.OwningThread *boom* .. --- snip ---
Well the code checks the PEB loader lock directly probably to prevent any ui deadlocks caused by multiple threads defer/nested loading ui controls. Wine does not expose its internal loader lock in PEB (NULL ptr), which leads to crash.
At this point wine has to make a design decision: expose the loader lock (critical section) in PEB or dismiss .NET :-) Unfortunately I don't see another way because if we fake the lock at this point by using a dummy one in order to protect the real loader lock it might cause various issues (both locks would have to be synchronized).
Attached is a patch which fixes this. It assigns the PEB loader lock field to wine internal loader lock at process startup (dlls/ntdll/loader.c:process_attach)
It works for me (tm) though AJ might find a better place for this. ---------------------------------------
Stay tuned, more goodies to come ...
Regards.
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #2 from Anastasius Focht focht@gmx.net 2007-11-16 07:49:40 --- Hello,
again :-)
Prerequisite:
1) wine-0.9.49 (or GIT) 2) successful installation of .NET 2.0 Framework 3) "l_intl.nls" copied from windows installation to wine system32 4) PEB loader lock patch from http://bugs.winehq.org/attachment.cgi?id=9195
----
With that stuff in place, starting .NET gui apps will immediately lead to a crash.
-- snip --- 0:000> .exr -1 ExceptionAddress: 7b841460 (KERNEL32!RaiseException) ExceptionCode: e0434f4d (CLR exception) ExceptionFlags: 00000001 NumberParameters: 1 Parameter[0]: 80070057 -- snip ---
Wow .. CLR exception for now :-) Lets see what kind ...
--- snip --- 0:000> !PrintException Exception object: 00a17cfc Exception type: System.ArgumentException Message: Only TrueType fonts are supported. This is not a TrueType font. InnerException: <none> StackTrace (generated): <none> StackTraceString: <none> HResult: 80070057 --- snip ---
Now thats some kind of useful information (although the message is slightly misleading as found later). Obligatory CLR stack:
--- snip --- 0:000> !ClrStack OS Thread Id: 0xf (0) ESP EIP 0034f038 7b8414d8 [HelperMethodFrame: 0034f038] 0034f0dc 039bd191 System.Drawing.Font.FromLogFont(System.Object, IntPtr) 0034f104 039bca13 System.Drawing.Font.FromHfont(IntPtr) 0034f150 039bc7cb System.Drawing.SystemFonts.get_DefaultFont() 0034f188 039bc2c2 System.Windows.Forms.Control.get_Font() 0034f194 039bc201 System.Windows.Forms.Control.get_FontHeight() 0034f1a4 039bc0ff System.Windows.Forms.TextBoxBase.get_PreferredHeight() 0034f1b8 039bc0b7 System.Windows.Forms.TextBoxBase.get_DefaultSize() 0034f1cc 02fa92ea System.Windows.Forms.Control..ctor(Boolean) 0034f240 039bc041 System.Windows.Forms.TextBoxBase..ctor() 0034f24c 039bbe87 System.Windows.Forms.TextBox..ctor() 0034f250 039ba002 Projekt2.WinForm.InitializeComponent() 0034f3c8 02fa7139 Projekt2.WinForm..ctor() 0034f3d0 02fa710c Projekt2.WinForm.Main() 0034f5e4 79e88f63 [GCFrame: 0034f5e4] --- snip ---
Ok, native gdiplus that doesn't like the way truetype fonts are currently installed on my system. Unfortunately you can't use wine gdiplus (builtin) at this point because there is too much API missing. .NET "fixes" this issue by using LoadLibraryEx() + direct load path, preventing builtin load first.
Bascially it enumerates the registry (SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts) keys and searches "c:\windows\fonts" (SearchPathW) according what it found in registry. Following keys are queried too: "SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink" and "SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes"
Fix1: copy the registered truetype fonts from your share\wine\fonts whatever to windows\fonts. Be aware .NET apps might use more font variants so it might look very crappy if only few (fallbacks) are used.
Fix2: copy/install the default windows truetype fonts (all ttf) to your wine windows\fonts folder and register them in registry (if not done by installer). You might export "HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Font*" keys for easier game.
This should fix the font issue and give apps the look'n'feel as in windows. ---------------------------------------
Stay tuned, more goodies to come ...
Regards.
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #3 from Anastasius Focht focht@gmx.net 2007-11-16 08:03:11 --- Created an attachment (id=9198) --> (http://bugs.winehq.org/attachment.cgi?id=9198) patch which keeps .NET gui apps happy by adjusting winstation->flags WSF_VISIBLE
Hello,
again :-)
Prerequisite:
1) wine-0.9.49 (or GIT) 2) successful installation of .NET 2.0 Framework 3) "l_intl.nls" copied from windows installation to wine system32 4) PEB loader lock patch from http://bugs.winehq.org/attachment.cgi?id=9195 5) true type fonts correctly installed for native gdiplus (comment #2)
----
With that stuff in place, till no luck starting .NET gui apps .. crash
--- snip --- 0:000> .exr -1 ExceptionAddress: 7b841460 (KERNEL32!RaiseException) ExceptionCode: e0434f4d (CLR exception) ExceptionFlags: 00000001 NumberParameters: 1 Parameter[0]: 80131509 --- snip ---
Ok, CLR one. More info ...
--- snip --- 0:000> !PrintException Exception object: 00a4e824 Exception type: System.InvalidOperationException Message: Showing a modal dialog box or form when the application is not running in UserInteractive mode is not a valid operation. Specify the ServiceNotification or DefaultDesktopOnly style to display a notification from a service application. InnerException: <none> StackTrace (generated): <none> StackTraceString: <none> HResult: 80131509 --- snip ---
Whoops ... that's some interesting description. Native callstack:
--- snip --- 0:000> kb ChildEBP RetAddr Args to Child WARNING: Stack unwind information not available. Following frames may be wrong. 0034edb8 79f97065 e0434f4d 00000001 00000001 KERNEL32!RaiseException+0x78 0034ee18 7a0945a4 00a4e824 00000000 00000000 mscorwks!RaiseTheExceptionInternalOnly+0x226 0034eedc 0413ecd8 f7c050be 79e71998 0034f044 mscorwks!JIT_Throw+0xd0 0034f000 6066ac60 00000155 000001cd 001a8f94 0x413ecd8 0034f0b0 60660930 7c5c2920 0034f100 00000000 winex11!SetCursorPos+0x9a0 0034f158 6043855a 00040078 00000202 00000000 winex11!WindowMessage+0xe80 0034f188 60438bfe 00570852 00040078 00000202 user32!DeferWindowPos+0x2ea 0034f1c8 6043de41 00040078 00000202 00000000 user32!DeferWindowPos+0x98e 0034f208 60405c26 00040078 00000202 00000000 user32!CallWindowProcA+0x1d1 0034f248 03c5105e 0034f2dc f7c050be 00000000 user32!DispatchMessageW+0x96 0034f264 03d8e5fa 00a20be0 00000001 00000000 0x3c5105e 0034f3d0 79e88f63 79e7c2ca 0034f414 0034f460 0x3d8e5fa 0034f3d4 79e7c2ca 0034f414 0034f460 79e88ee4 mscorwks!CallDescrWorker+0x33 .. --- snip ---
CLR callstack
--- snip --- 0:000> !clrstack OS Thread Id: 0xf (0) ESP EIP 0034ee40 7b8414d8 [HelperMethodFrame: 0034ee40] 0034eee4 0413ecd8 System.Windows.Forms.MessageBox.ShowCore(System.Windows.Forms.IWin32Window, System.String, System.String, System.Windows.Forms.MessageBoxButtons, System.Windows.Forms.MessageBoxIcon, System.Windows.Forms.MessageBoxDefaultButton, System.Windows.Forms.MessageBoxOptions, Boolean) 0034eee8 0413e967 [InlinedCallFrame: 0034eee8] 0034f044 00000000 [InlinedCallFrame: 0034f044] 0034f27c 00000000 [NDirectMethodFrameStandalone: 0034f27c] System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG ByRef) 0034f5e4 00000000 [GCFrame: 0034f5e4] --- snip ---
Ok, what happens? Well, in native code it checks if the user is "interactive" by using GetProcessWindowStation() and GetUserObjectInformation( USEROBJECTFLAGS) API.
Unfortunately wine has this special flag not set (if not set by WindowStation creation or SetUserObjectInformation API) Attached is a patch which fixes this. As soon as a desktop gets created, this flag is set (e.g. winstation->flags |= WSF_VISIBLE)
At this point, .NET gui apps _might_ start working. ---------------------------------------
Stay tuned, more goodies to come ...
Regards
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #4 from Anastasius Focht focht@gmx.net 2007-11-16 08:19:02 --- Created an attachment (id=9199) --> (http://bugs.winehq.org/attachment.cgi?id=9199) patch which fixes empty LPARAM for initial CDM_xxx messages in FILEDLG95_HandleCustomDialogMessages
Hello,
again :-)
Prerequisite:
1) wine-0.9.49 (or GIT) 2) successful installation of .NET 2.0 Framework 3) "l_intl.nls" copied from windows installation to wine system32 4) PEB loader lock patch from http://bugs.winehq.org/attachment.cgi?id=9195 5) true type fonts correctly installed for native gdiplus (comment #2) 6) WinStation patch from http://bugs.winehq.org/attachment.cgi?id=9198
----
With that stuff in place, the .NET app starts but as soon as the "browse" button is clicked it crashes. Turns out this probably not .NET related bug but I added it here because it's needed to get this app to work.
--- snip --- fixme:commdlg:GetFileName95 Flags 0x00800000 not yet implemented First chance exception: page fault on write access to 0x00000000 in 32-bit code (0x75789bca). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:75789bca ESP:0034c8f0 EBP:0034cd5c EFLAGS:00210247( - 00 RIZP1C) EAX:6165facc EBX:61665600 ECX:00000000 EDX:0034ed7c ESI:001ba260 EDI:00000000 Stack dump: 0x0034c8f0: 61647762 00000000 001ba260 00000002 0x0034c900: 00000000 03a28298 00000000 00000000 0x0034c910: 0000000f 00000000 00000000 0034c90e 0x0034c920: 00000000 00040068 0034ed7c 00000000 0x0034c930: 00000000 02f842c4 00000000 00000000 0x0034c940: 02f80010 00000000 00000000 00000001 Backtrace: =>1 0x75789bca (0x0034cd5c) 2 0x616484a1 FileOpenDlgProc95+0x661(hwnd=0x40068, uMsg=0x464, wParam=0x0, lParam=0x0) [/usr/local/src/wine/dlls/comdlg32/filedlg.c:1118] in comdlg32 (0x0034d41c) 3 0x602b653a WINPROC_wrapper+0x1a() in user32 (0x0034d44c) 4 0x602b8368 call_dialog_proc+0x68(hwnd=<register EDI not in topmost frame>, msg=0x464, wp=0x0, lp=0x0, result=0x34d4bc, arg=0x61647e40) [/usr/local/src/wine/dlls/user32/winproc.c:479] in user32 (0x0034d48c) 5 0x602baa8a WINPROC_CallDlgProcW+0x5a(func=0xffff003d, hwnd=0x40068, msg=0x464, wParam=<register EDI not in topmost frame>, lParam=0x0) [/usr/local/src/wine/dlls/user32/winproc.c:2394] in user32 (0x0034d4cc) 6 0x6024aeb5 DefDlgProcW+0x85(hwnd=<register ESI not in topmost frame>, msg=0x464, wParam=0x0, lParam=0x0) [/usr/local/src/wine/dlls/user32/defdlg.c:488] in user32 (0x0034d4fc) 7 0x602b653a WINPROC_wrapper+0x1a() in user32 (0x0034d52c) 8 0x602b6bde call_window_proc+0x6e(hwnd=<register EDI not in topmost frame>, msg=0x464, wp=0x0, lp=0x0, result=0x34d610, arg=0x6024ae30) [/usr/local/src/wine/dlls/user32/winproc.c:457] in user32 (0x0034d56c) .. --- snip ---
In short: while trying to create a file open dialog, FILEDLG95_* sends a series of "change" notifications in WM_INITDIALOG. e.g. CDN_INITDONE, CDN_FOLDERCHANGE, CDN_SELCHANGE. Unfortunately L/WPARAM parameter validation for CDM_GETFILEPATH and CDM_GETSPEC is somewhat missing in FILEDLG95_HandleCustomDialogMessages(). It crashes there while dereferencing NULL ptr.
Attached patch checks lParam before doing anything useful.
With that patch in place, this little .NET 2.0 app seems to work fine. It might be that other .NET 1.x/2.0 apps might start working too.
As said in the beginning .. there are probably many issues left. But this is a start ;-)
Regards
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #5 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2007-11-17 01:22:54 --- Created an attachment (id=9204) --> (http://bugs.winehq.org/attachment.cgi?id=9204) for testing
You might export "HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Font*" keys for easier game.
I'll attach that here, so users can give it some testing
http://bugs.winehq.org/show_bug.cgi?id=10467
Luke Bratch l_bratch@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |l_bratch@yahoo.co.uk
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #6 from Anastasius Focht focht@gmx.net 2007-11-18 12:07:37 --- Created an attachment (id=9238) --> (http://bugs.winehq.org/attachment.cgi?id=9238) patch to process stack guard page to allow CLR exceptions from .NET runtime to succeed
Hello,
this is probably the most important patch of all. Small but full of consequences ... took me some time to find out what's going on ;-)
At current state of wine (even with previous patches applied), any CLR exception thrown from managed/JIT code will cause .NET apps to segfault. Exceptions thrown from managed code are not bad by default. In fact they are important program flow execution mechanism. Almost every .NET app throws some in it's lifetime. Well I skip the glory details here how managed exceptions work at OS level...
At a certain point after the native callstack unwinding took place, the managed code (JIT) undergoes some complex unwinding process to restore the JIT virtual machine to correct state.
Basically the JIT code manager crawls the managed code stacks and rebuilds frames to resume execution at some point. During this stack crawl, some prerequisites checked to make sure the stack is in "good" state. One if them are stack guard pages. Unfortunately this is an area where the current wine implementation fails...
In windows stack guard pages are used for dynamic thread stack growth. When the app touches the guard page, windows commits that page and the next uncommitted page becomes the new guard page. Automatic stack growth works only for the guard page and stack memory usually grows in page size (=4K) increments.
The .NET runtime code checks the process stack regions for present guard pages. This fails for wine: although the a guard page is set up, its located at other location and the flags do not match (PAGE_NOACCESS vs. PAGE_GUARD). This leads to a somewhat catastrophic result ;-)
Imagine the following code snippet (I added fancy function names to better reading) .. assuming no page guards have been found.
--- snip --- call get_current_stack_pointer_in_eax mov esi, eax and esi, 0FFFFF000h mov edi, 1000h mov ecx, ebx sub esi, edi call get_managed_thread_top_stack_addr_in_eax mov ebx, eax cmp esi, ebx jb we_got_a_problem_no_place_for_page_guard push esi call setup_page_guard .. call verify_if_page_guard_is_really_there --- snip ---
Basically it sets up a page guard in next stack page (rounded) using VirtualProtect( .. PAGE_GUARD) (within setup_page_guard()).
At this point the rounding for page guard address leaves estimated 0x250 bytes before the VirtualProtect() call to designated guard address. No problem for windows - even if page guard is touched by nested API calls it's automagically fixed by OS.
The wine sequence: VirtualProtect -> VirtualProtectEx -> NtProtectVirtualMemory -> VIRTUAL_SetProt -> mprotect *kaboooooom*
It immediately segfaults when calling mprotect, aborting the program. Before mprotect(), the stack space has around 0x100 bytes left to designated guard address (some locals within NtProtectVirtualMemory eat space). Somewhere in glibc code the remaining stack space to designated guard address is eaten. When mprotect() is executed, the "guard" page is immediately touched by glibc code itself which leads to segmentation fault. Interesting not-so-obvious problem ;-)
Unfortunately this place can't be fixed in wine. I removed some locals to gain more stack space but not avail. 0x200 bytes are not enough for the call sequence to succeed. Bypassing the guard region with a large buffer on stack before calling mprotect() won't work: as soon as the stack pointer is re-adjusted on function exit, the address will cross the guard page address - even if it does not touch it - it will cause abort. Dead end ... even if it succeeds to setup the guard in this case, other code might cause PAGE_GUARD violations - depending on call stack depth - which are not automagically handled in wine,
Fortunately I found a solution. When it looks for guard pages, it starts at bottom of stack and walks it's way up (VirtualQuery). When it finds such a guard page, the problematic code which re-enables guard pages is not executed. So wine has to make sure there is an initial guard page the .NET runtime likes ;-)
Attached patch fixes this. Notice it uses NtCurrentTeb()->Tib.StackLimit rather than the current NtCurrentTeb()->DeallocationStack to setup guard page address. This is required because .NET runtime starts page guard walking by looking at Tib.StackLimit until it reaches current stack pointer area. Also the PAGE_GUARD flag needs to be explicitly set.
This should allow most .NET software to start or at least not to segfault anymore. ;-) Even if unrecoverable .NET errors are encountered you now get a detailed description on console what went wrong and can fix this accordingly (like specific truetype missing whatever).
Regards
http://bugs.winehq.org/show_bug.cgi?id=10467
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefandoesinger@gmx.at
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #7 from Vitaliy Margolen vitaliy@kievinfo.com 2007-11-18 13:16:34 --- That won't work. Wine does not grow stack. And does not use guard page.
When I did some testing on winnt+ the guard page was used only to grow stack. When the maximal stack size was reached (when it could not be grown anymore because of reserved space in the lover address space) windows allocated page with PAGE_NOACCESS. Exactly what Wine does now. Just allocating the maximum stack size instead.
So if what you saying is true the bug is in .net not Wine. However it would be nice for Wine to support growing stack.
What you did won't work for some programs that clear _whole stack space_ on exit. On windows they trigger stack growth. On Wine they just crash.
http://bugs.winehq.org/show_bug.cgi?id=10467
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #9238 is|0 |1 obsolete| |
--- Comment #8 from Anastasius Focht focht@gmx.net 2007-11-18 13:48:45 --- Created an attachment (id=9240) --> (http://bugs.winehq.org/attachment.cgi?id=9240) patch to fix bottom stack guard page to allow CLR exceptions from .NET runtime to succeed
Hello
--- quote --- That won't work. Wine does not grow stack. And does not use guard page. --- quote ---
--- quote --- When I did some testing on winnt+ the guard page was used only to grow stack. When the maximal stack size was reached (when it could not be grown anymore because of reserved space in the lover address space) windows allocated page with PAGE_NOACCESS. Exactly what Wine does now. Just allocating the maximum stack size instead. --- quote ---
Did you actually bother to read? I *never* intended to implement/mimick any dynamic stack growth using PAGE_GUARD like NT does. I just marked a single guard page location at bottom of stack and adjusted flags accordingly. O-N-E single stack guard page at thread stack B-O-T-T-O-M. If there is a guard page violation due to stack overflow then the usual overflow handling has to be extended to handle this case (just like wine currently does when PAGE_NOACCESS guard is encountered). There is no growth further. The app would be killed anyway.
--- quote --- So if what you saying is true the bug is in .net not Wine. However it would be nice for Wine to support growing stack. --- quote ---
This is the way windows NT based operating systems work. The Microsoft .NET runtime was never intended to run on other operating systems (except of shared source rotor, which differs in aspects). Why should the MS .NET runtime developers actually care that wine doesn't support this stuff?
--- quote --- What you did won't work for some programs that clear _whole stack space_ on exit. On windows they trigger stack growth. On Wine they just crash. --- quote ---
And? Whats the problem? In the rare cases such brain damaged programs won't work anymore just add internal last chance PAGE_GUARD violation handler, which clears the guard page flag and resume malware cleanup process. Done.
Anyway attached is version which takes user threads into account. This lets multithreaded .NET apps succeed too, which throw CLR exceptions from other than main thread.
Regards
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #9 from Vitaliy Margolen vitaliy@kievinfo.com 2007-11-18 14:40:57 --- I'm not sure why you quoting something that's available by scrolling up. But just in case you need it, you can find it blow.
You didn't read it right. And you did not search the commit log for _WHY_ Wine does not use guard page. You really should and also look at all the mentioned bugs.
I'm telling you that stuff like starforce and securerom _WILL_ crash if you don't grow stack on guard page access. It HAVE TO be gown, or it HAVE TO BE no access page as it is now. Your hack is just that - a hack. It can not be used as is without implementing stack growth.
(In reply to comment #8)
Created an attachment (id=9240)
--> (http://bugs.winehq.org/attachment.cgi?id=9240) [details]
patch to fix bottom stack guard page to allow CLR exceptions from .NET runtime to succeed
Hello
--- quote --- That won't work. Wine does not grow stack. And does not use guard page. --- quote ---
--- quote --- When I did some testing on winnt+ the guard page was used only to grow stack. When the maximal stack size was reached (when it could not be grown anymore because of reserved space in the lover address space) windows allocated page with PAGE_NOACCESS. Exactly what Wine does now. Just allocating the maximum stack size instead. --- quote ---
Did you actually bother to read? I *never* intended to implement/mimick any dynamic stack growth using PAGE_GUARD like NT does. I just marked a single guard page location at bottom of stack and adjusted flags accordingly. O-N-E single stack guard page at thread stack B-O-T-T-O-M. If there is a guard page violation due to stack overflow then the usual overflow handling has to be extended to handle this case (just like wine currently does when PAGE_NOACCESS guard is encountered). There is no growth further. The app would be killed anyway.
--- quote --- So if what you saying is true the bug is in .net not Wine. However it would be nice for Wine to support growing stack. --- quote ---
This is the way windows NT based operating systems work. The Microsoft .NET runtime was never intended to run on other operating systems (except of shared source rotor, which differs in aspects). Why should the MS .NET runtime developers actually care that wine doesn't support this stuff?
--- quote --- What you did won't work for some programs that clear _whole stack space_ on exit. On windows they trigger stack growth. On Wine they just crash. --- quote ---
And? Whats the problem? In the rare cases such brain damaged programs won't work anymore just add internal last chance PAGE_GUARD violation handler, which clears the guard page flag and resume malware cleanup process. Done.
Anyway attached is version which takes user threads into account. This lets multithreaded .NET apps succeed too, which throw CLR exceptions from other than main thread.
Regards
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #10 from Anastasius Focht focht@gmx.net 2007-11-18 16:23:55 --- Hello,
--- quote --- I'm not sure why you quoting something that's available by scrolling up. But just in case you need it, you can find it blow. --- quote ---
I quote the way I like it. Sometimes its better to respond/comment to _specific_ parts of posts than to quote everything or nothing.
--- quote --- You didn't read it right. And you did not search the commit log for _WHY_ Wine does not use guard page. You really should and also look at all the mentioned bugs. --- quote ---
Well I searched and found this last commit:
http://www.winehq.org/pipermail/wine-cvs/2005-December/019888.html
"ntdll: Don't use a real guard page at the bottom of the stack. A no-access page is enough, we can't properly raise an overflow exception anyway."
But I didn't found a discussion related to that message that explains "is enough" and "can't properly raise stack overflow exception".
--- quote MSDN --- If a thread in an application causes an EXCEPTION_STACK_OVERFLOW exception, the thread has left its stack in a damaged state.
When this maximum stack size is exceeded, the system does the following three things: * Removes the PAGE_GUARD protection on the guard page, as previously described. * Tries to allocate a new guard page below the last one. However, this fails because the maximum stack size has been exceeded. * Raises an exception so that the thread can handle it in the exception block. ... Note that, at that point, the stack no longer has a guard page. The next time that the program grows the stack all the way to the end, where there should be a guard page, the program writes beyond the end of the stack and causes an access violation. --- quote MSDN ---
So why not having both? Two-layered page guard for thread stacks:
NtProtectVirtualMemory( NtCurrentProcess(), &teb->DeallocationStack, &size, PAGE_NOACCESS, NULL ); NtProtectVirtualMemory( NtCurrentProcess(), &teb->Tib.StackLimit, &size, PAGE_GUARD, NULL );
-- stack bottom -- PAGE_NO_ACCESS -> raise access violation / die PAGE_GUARD -> "last chance", raise EXCEPTION_STACK_OVERFLOW (and reset the guard if necessary) .. PAGE_READ_WRITE/EXECUTE whatever -> normal stack pages .. current callstack -- stack top --
When the PAGE_GUARD page is touched, remove the PAGE_GUARD flag *and* raise EXCEPTION_STACK_OVERFLOW. This gives the executing thread the chance to actually do something within "last chance" 4K page limit, cleanup, error reporting whatever. If the app structured exception handler - which catches EXCEPTION_STACK_OVERFLOW - tries to touch/walk the stack further, then the PAGE_NO_ACCESS comes into play (causing nested exception). This could be the access violation exception described in MSDN (quote). With this mechanism wine doesn't need to implement dynamically grown PAGE_GUARD stack and pleases applications that expect a PAGE_GUARD flagged page (like .NET) and some sort of EXCEPTION_STACK_OVERFLOW. Better than dying in very last NO_ACCESS page without telling the real cause: stack overflow.
-- quote --- I'm telling you that stuff like starforce and securerom _WILL_ crash if you don't grow stack on guard page access. It HAVE TO be gown, or it HAVE TO BE no access page as it is now. Your hack is just that - a hack. It can not be used as is without implementing stack growth. -- quote ---
Show me the code/disassembly snippet of Securom illustrating NO_ACCESS vs. PAGE_GUARD problem at stack bottom. I reversed various copy prot stuff and the stack wipe is NOT an issue there (even retested the bottom PAGE_GUARD patch for v6 and v7 just in case).
Besides this a common technique to prevent debuggers getting a good callstack if the target protector code smells something fishy. All "on purpose" stack wipes I have encountered in various PE protections didn't started from/reached stack bottom at all. Usually a fixed amount of stack pages are cleared from current_esp-n*page_size to stack top. Current to-the-top callstack is what matters.
And StarForce ... aren't you the one who tells people "StarForce won't ever work"? So who cares then?
Regards
http://bugs.winehq.org/show_bug.cgi?id=10467
Bjorn Nostvold bjorn.nostvold@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bjorn.nostvold@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=10467
Jaime Rave jaimerave@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jaimerave@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=10467
Louis Lenders xerox_xerox2000@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dusted@dusted.dk
--- Comment #11 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2007-11-22 08:03:53 --- *** Bug 9897 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #12 from Anastasius Focht focht@gmx.net 2007-11-22 08:29:11 --- Hello,
just saw some .net 2.0 mini howto's in other bug reports based on my information/patches here...
If you use recent GIT (>= 19. Nov 2007), the PEB loader lock patch (http://bugs.winehq.org/attachment.cgi?id=9195) can be omitted. See http://article.gmane.org/gmane.comp.emulators.wine.cvs/35801
The other patches are needed though.
Regards
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #13 from Anastasius Focht focht@gmx.net 2007-11-22 08:39:19 --- Hello again,
if you use/spread the howto in other bug reports (http://www.winehq.org/pipermail/wine-bugs/2007-November/077096.html), you might want a little improvement to .NET 2.0 installation (less internal crashes/skips which might cause harm later, although the installation succeeds).
http://www.winehq.org/pipermail/wine-bugs/2007-November/077087.html
Though the patch isn't needed when J. Hawkins fixes service install part in msi (deformat service strings).
Anyway you should make step (2) to (1) in future.
--- snip --- 1. Install .net 2.0 (installer should finish fine in wine-0.9.49)
2. Copy the file l_intl.nls from a windows partition to ~/.wine/drive_c/windows/system32 --- snip ---
While the .NET 2.0 installer is executing, some components already use parts of .NET runtime (assembly installation/registration/GAC). Hence the "l_intl.nls" is needed before the .NET 2.0 installation is run.
Regards
http://bugs.winehq.org/show_bug.cgi?id=10467
Louis Lenders xerox_xerox2000@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xerox_xerox2000@yahoo.co.uk
--- Comment #14 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2007-11-22 09:03:05 --- Ok, thanks very much, i'll update the howto (i put it in the appdb)
http://bugs.winehq.org/show_bug.cgi?id=10467
David Canar davidcanar@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |davidcanar@gmail.com
--- Comment #15 from David Canar davidcanar@gmail.com 2007-12-13 14:04:41 --- All the patches work great! are they going to be included in the main Wine code? I downloaded Wine the snapshot from December 12th 2007 and it seems that it doesn't have any of the patches that are here in this bug. I applied them and I got 2 .NET 2.0 applications working already. One of them SharpDevelop 2.2 has a little bit of problems loading other .dll files I need to investigate further why; but the application started and I can see many dialog boxes and I can interact with the application. Thank you Anastasius Focht for your work!!!
http://bugs.winehq.org/show_bug.cgi?id=10467
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #16 from Dan Kegel dank@kegel.com 2007-12-13 18:06:08 --- No, Anastasius is anonymous, so we can't apply his patches. Somebody has to write them from scratch, I'm afraid. Still, it's very helpful that he did this work.
http://bugs.winehq.org/show_bug.cgi?id=10467
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |10787
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #17 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2007-12-18 13:59:26 --- Looks like Alexandre just committed a fix for one part of the problem: http://www.winehq.org/pipermail/wine-cvs/2007-December/038922.html So the patch from comment #3 is not needed anymore now. That leaves two patches to be applied to get this (and other) simple .net apps running (comment #4 and #6).
The bug/patch comment #4 looks more or less like a duplicate of bug #9104. As stated there someone posted a fix about two years ago: http://www.winehq.org/pipermail/wine-patches/2005-October/021306.html
Is there anyone who can judge if the patch is ok, or why it was rejected?
http://bugs.winehq.org/show_bug.cgi?id=10467
James McKenzie jjmckenzie51@sprintpcs.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jjmckenzie51@sprintpcs.com
--- Comment #18 from James McKenzie jjmckenzie51@sprintpcs.com 2008-01-09 19:29:47 --- Louis: The patch in issue 9104 needs a conformence test, that is a test to show that the patch does indeed work. Without one, the patch cannot be accepted. James
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #19 from James McKenzie jjmckenzie51@sprintpcs.com 2008-01-09 22:07:19 --- Herr Focht: .NET 1.1 and 2.0 will not install on Wine 0.9.52. The installation breaks when RegSvcs.exe is run. Can you look into this?
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #20 from Anastasius Focht focht@gmx.net 2008-01-15 08:14:15 --- Hello,
--- quote --- Herr Focht: .NET 1.1 and 2.0 will not install on Wine 0.9.52. The installation breaks when RegSvcs.exe is run. Can you look into this? --- quote ---
.NET 1.1 dies due to activation context api problem. When querying (default) sxs activation context info with basic information class it returns default context which is incorrect. Additionally .NET accesses "native" activation context api directly and relies on certain structure layouts which obviously fails because wine's does not match windows ones.
.NET 2.0 installs fine (with some minor nuisances) in default (clean) .wine configuration. If you encounter a *serious* cash preventing successful install post the exact steps to reproduce. Don't bother with COM+/CLR exceptions from regasm/regsvcs .. these are expected at current state of wine.
If you intend to run real .net apps it's better to have some fixes _prior_ to installation of .NET applied:
- l_intl.nls fix - page guard fix - MSI installer fix for .clr optimization service
Latter one needs to be applied _now_ to prevent long delays (hangs) due to recent changes in service manager while (unsuccessfully) trying to start CLR optimization service (http://bugs.winehq.org/attachment.cgi?id=9285 from bug 3972) Much worse due to new "auto run" features (services, run, run once) you will get extra delays every time you implicitly start wine server because of this msi service install deformat bug.
Regarding the unicode case mapping file: It seems one of wine's developers, Timoshkov Dmitry wrote such a tool years ago. Seems pretty straight forward, no magic at all. If you don't have windows l_intl.nls, you can generate the required file using the script from following url: http://d.hatena.ne.jp/nazodane/mobile?date=20071230%C2%A7ion=1199011371
Some japanese guy automated the process nicely. Domo arigato gosaimashita! (I love anime):-)
It might take some time to (recursively) download all the mappings but once in place it correctly builds the required files. You can then copy the generated l_intl.nls to your wine system32.
Regards
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #21 from James McKenzie jjmckenzie51@sprintpcs.com 2008-01-19 11:59:10 --- Herr Foucht: Babelfish did not do justice to the page and could not translate several of the instructions. I may leave a request to the page for an English translation but it appears as if this is part of the ReactOS project, whose code cannot be incorporated into Wine (I don't know the history of this and I really don't care, if ReactOS is released under the GPL and is clean (as it has to be in order to avoid the wrath of Microsoft) then its code should be importable into Wine.) If you have such a translation, could you post it on a public site and link to it? Thank you. James
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #22 from Dan Kegel dank@kegel.com 2008-01-19 12:18:48 --- They imported it from wine, I think. See http://www.mail-archive.com/wine-devel@winehq.com/msg00408.html
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #23 from Anastasius Focht focht@gmx.net 2008-01-19 12:33:02 --- Hello,
well the single "create_nls.c" source file in question which is pulled by the shell script snippet reads as follows:
--- snip header --- /* * Tool for creating NT-like NLS files for Unicode <-> Codepage conversions. * Tool for creating NT-like l_intl.nls file for case mapping of unicode * characters. * Copyright 2000 Timoshkov Dmitry * Copyright 2001 Matei Alexandru * * Sources of information: * Andrew Kozin's YAW project http://www.chat.ru/~stanson/yaw_en.html * Ove Kõven's investigations http://www.ping.uio.no/~ovehk/nls */ --- snip header ---
So ask one of the authors/originators, Dmitry Timoshkov of codeweavers.com about copyright issues and implications. If he wrote this tool using publicly available information there seems no harm to incorporate his work in current wine source tree.
Another question is the use of unicode.org data (tables and mappings), though that can be answered by looking at http://unicode.org/copyright.html
And for the "instructions" part ... there is no need to bother babelfish for japanese translation, the short shell script is self explaining enough.
Regards
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #24 from Dmitry Timoshkov dmitry@codeweavers.com 2008-01-19 23:35:34 --- I've written the converter at the time I've being working on adding unicode support to Wine, and at that time I thought that using .nls file as NT does is the way to go. Alexandre had a different opinion on that.
I have no idea why there is "Matei Alexandru" copyright in the source, I sent to him my source after a private request, and I don't nothing in the source which I haven't written. I still have the original sources if somebody needs them.
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #25 from Dmitry Timoshkov dmitry@codeweavers.com 2008-01-19 23:36:47 --- s/I don't nothing/I see nothing/
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #26 from Anastasius Focht focht@gmx.net 2008-01-20 07:18:56 --- Hello,
--- quote --- I've written the converter at the time I've being working on adding unicode support to Wine, and at that time I thought that using .nls file as NT does is the way to go. Alexandre had a different opinion on that. --- quote ---
Ok, a different approach was taken. It seems .NET only needs the default NT-style unicode case mapping table (invariant) to be present (the file gets memory mapped).
I see two options to solve this problem:
1.) Generate "l_intl.nls" with your tool once and import it as binary resource into wine tree. Upon wineprefix creation/update it should get copied into system32 directory.
2.) Strip the tool only to contain code which creates the required case mapping file. This seems to be fairly easy. Only "UnicodeData.txt" from unicode.org is required as external data dependency to build both (upper and lower) case tables and binary write the data. Import this stripped down source file an up-to-date "UnicodeData.txt" into wine "tools" subtree and let it create the required case mapping file. Upon wineprefix creation/update it should get copied into system32 directory.
Regards
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #27 from Dmitry Timoshkov dmitry@codeweavers.com 2008-01-20 07:28:18 --- Actually libs/wine/cpmap.pl already generates libs/wine/casemap.c which has very similar internal format to l_intl.nls, so it should be fairly easy to add l_intl.nls generation to cpmap.pl.
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #28 from Anastasius Focht focht@gmx.net 2008-01-20 07:48:04 --- Hello,
--- quote --- Actually libs/wine/cpmap.pl already generates libs/wine/casemap.c which has very similar internal format to l_intl.nls, so it should be fairly easy to add l_intl.nls generation to cpmap.pl. --- quote ---
Ah I missed this one. With the data for both tables already present all that needs to be done is to extend the perl script to binary write out an NT-style case mapping file (packed tables). Yay, that would be the best solution.
Regards
http://bugs.winehq.org/show_bug.cgi?id=10467
Louis Lenders xerox_xerox2000@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |quest2013@emailengine.org
--- Comment #29 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2008-01-30 01:18:56 --- *** Bug 11395 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=10467
Roderick Colenbrander thunderbird2k@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cngnome@gmail.com
--- Comment #30 from Roderick Colenbrander thunderbird2k@gmx.net 2008-02-07 16:30:54 --- *** Bug 11501 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #31 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2008-02-07 16:34:11 --- *** Bug 11502 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=10467
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #9195 is|1 |0 patch| | Attachment #9195 is|0 |1 obsolete| |
--- Comment #32 from Anastasius Focht focht@gmx.net 2008-02-17 08:11:40 --- (From update of attachment 9195) Obsoleting some patches which have been fixed in GIT for some time now.
http://article.gmane.org/gmane.comp.emulators.wine.cvs/35801
http://bugs.winehq.org/show_bug.cgi?id=10467
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #9198 is|1 |0 patch| | Attachment #9198 is|0 |1 obsolete| |
--- Comment #33 from Anastasius Focht focht@gmx.net 2008-02-17 08:13:10 --- (From update of attachment 9198) Obsoleting my patches, fixed in GIT for some time now.
http://www.winehq.org/pipermail/wine-cvs/2007-December/038922.html
http://bugs.winehq.org/show_bug.cgi?id=10467
Ger Teunis g.teunis@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |g.teunis@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=10467
Hin-Tak Leung htl10@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |htl10@users.sourceforge.net
http://bugs.winehq.org/show_bug.cgi?id=10467
Hin-Tak Leung htl10@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |11867
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #34 from Hin-Tak Leung htl10@users.sourceforge.net 2008-03-09 15:57:17 --- I should mention that the font copying and registry hack is *also* needed for win32 mono 1.2.6 - so those fonts or whatever probably needs to be a standard part of wine.
with unchanged 0.5.56, .NET 2 framework can be installed, and correctly as well. however, the changes http://appdb.winehq.org/objectManager.php?sClass=version&iId=3754 are required for *running* .NET apps.
I am not convinced that all of the changes are needed (nor correct, based on the discussions here) - especially the font hack seems too "wholesale" just-copy-everything-under-windows. FWIW, Vista ships over 300Mb of fonts, and it is stupid to copy them all. (I didn't - I just sym-linked them).
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #35 from James McKenzie jjmckenzie51@sprintpcs.com 2008-03-09 16:15:13 --- Fonts: Maybe all that is needed is to install the core fonts, Arial and Times New Roman which can be done using winetricks: winetricks corefonts
James
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #36 from Hin-Tak Leung htl10@users.sourceforge.net 2008-03-09 16:23:45 --- (In reply to comment #35)
Fonts: Maybe all that is needed is to install the core fonts, Arial and Times New Roman which can be done using winetricks: winetricks corefonts
That's not the point (I said I already symlinked all 300MB of it from Vista) - I had a look at the font registry hack and it also includes one from office ( from the program file/* directory), which clearly should not be there. What I think should be done, is to clearly identify a *minimal* set of fonts that NET applications assume the platform have, and provide that natively. So I actually wish one of the patches should emit an info message about .NET applications trying to access fonts.
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #37 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2008-03-09 16:31:05 ---
What I think should be done, is to clearly identify a *minimal* set of fonts that NET applications assume the platform have, and provide that natively.
I'll do that when i've got some time. The work around copying *all* fonts was a bit of laziness, to be continued
http://bugs.winehq.org/show_bug.cgi?id=10467
Daniel djpnewton@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #38 from Daniel djpnewton@gmail.com 2008-03-19 16:46:08 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #39 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2008-03-25 14:56:57 --- Ah marvelous: with current git i only had to install corefonts, and copy the l_int.nls to system32. After doing that, Fastmd5 starts fine! Also the comdlg bug is fixed (see other bug for pdfxviewer). Now we're getting somewhere! Note: for the dotnet2.0 installer i had to set version back to win2k, otherwise it crashed
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #40 from Dan Kegel dank@kegel.com 2008-03-25 15:39:45 --- Thanks for updating the howto!
So http://winehq.org/pipermail/wine-cvs/2008-March/041667.html seems to have fixed the problem mentioned in #4, I gather.
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #41 from Hin-Tak Leung htl10@users.sourceforge.net 2008-03-26 08:45:33 --- I found a commit between 0.9.57<->0.9.58 broke .NET2's font access... (or what's important to me). The .NET 2 application I want to run now dies with 'attempt to read or write protected memory. This is often an indication that other memory is corrupt".
commit 0436a5d14abf22af6ec10640496f9e0298a65f69 Author: Huw Davies huw@codeweavers.com Date: Mon Mar 10 12:31:43 2008 +0000
gdi32: Store the Windows path (if it's available) in the font registry entries.
http://bugs.winehq.org/show_bug.cgi?id=10467
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |huw@codeweavers.com
--- Comment #42 from Dan Kegel dank@kegel.com 2008-03-26 08:54:19 --- Hin-tak, thanks. Which app is it? (And if there's no free download for it, do you know of a free app that is also affected?) cc'ing Huw.
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #43 from Hin-Tak Leung htl10@users.sourceforge.net 2008-03-26 09:11:06 --- I just posted to wine-devel, actually. The application is unfortunately proprietary (http://www.illumina.com/pages.ilmn?ID=35) but quite well-known in genetics research.
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #44 from Huw Davies huw@codeweavers.com 2008-03-26 10:37:04 --- Created an attachment (id=11667) --> (http://bugs.winehq.org/attachment.cgi?id=11667) Hack to skip loading of ukai.ttf
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #45 from Huw Davies huw@codeweavers.com 2008-03-26 10:38:10 --- (In reply to comment #44)
Created an attachment (id=11667)
--> (http://bugs.winehq.org/attachment.cgi?id=11667) [details]
Hack to skip loading of ukai.ttf
Could you try the above patch? Native gdiplus has problems with ukai.ttf.
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #46 from Dan Kegel dank@kegel.com 2008-03-26 10:55:02 --- Or follow http://www.codeweavers.com/support/wiki/faq/fontissues
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #47 from Hin-Tak Leung htl10@users.sourceforge.net 2008-03-26 11:00:21 --- Hmm, I can give the ukai patch a try, but I also have uming which is probably very similiar in terms of font structures, being of the same origin, and a lot of others non-european fonts. I don't get them from 3rd party, but fedora 8 shipped quite a few.
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #48 from Hin-Tak Leung htl10@users.sourceforge.net 2008-03-26 11:04:26 --- But my fonts are *newer* feity's, by a lot: !
$ rpm -qf /usr/share/fonts/cjkunifonts-*/* cjkunifonts-ukai-0.1.20060928-4.fc8.noarch cjkunifonts-ukai-0.1.20060928-4.fc8.noarch cjkunifonts-ukai-0.1.20060928-4.fc8.noarch cjkunifonts-uming-0.1.20060928-4.fc8.noarch cjkunifonts-uming-0.1.20060928-4.fc8.noarch cjkunifonts-uming-0.1.20060928-4.fc8.noarch
Do they mean one should *upgrade* or *downgrade*? That Wiki issue is not very helpful for non-ubuntu linux users. And Feity 7.04 is very old by fedora 8's standard.
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #49 from Dmitry Timoshkov dmitry@codeweavers.com 2008-03-26 11:11:57 --- First thing to try apparently is move the (potentially) problematic fonts aside and see if that helps.
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #50 from Hin-Tak Leung htl10@users.sourceforge.net 2008-03-26 11:27:39 --- (In reply to comment #49)
First thing to try apparently is move the (potentially) problematic fonts aside and see if that helps.
I don't have any fonts under ${HOME}/.fonts (the personal fontconfig font directory), but this is not a very practical advice:
$ locate .ttf | grep '^/usr/share/fonts/' | wc -l 153
i.e. I have at least 153 truetype fonts which were shipped by redhat to fedora 8. I have excluded /usr/share/X11/fonts/TTF/, and other application-specific directories already.
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #51 from Hin-Tak Leung htl10@users.sourceforge.net 2008-03-26 11:29:59 --- (In reply to comment #46)
Or follow http://www.codeweavers.com/support/wiki/faq/fontissues
This is no use to non-ubuntu users.
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #52 from Huw Davies huw@codeweavers.com 2008-03-26 11:45:13 --- (In reply to comment #51)
(In reply to comment #46)
Or follow http://www.codeweavers.com/support/wiki/faq/fontissues
This is no use to non-ubuntu users.
(In reply to comment #50)
(In reply to comment #49)
First thing to try apparently is move the (potentially) problematic fonts aside and see if that helps.
I don't have any fonts under ${HOME}/.fonts (the personal fontconfig font directory), but this is not a very practical advice:
$ locate .ttf | grep '^/usr/share/fonts/' | wc -l 153
i.e. I have at least 153 truetype fonts which were shipped by redhat to fedora 8. I have excluded /usr/share/X11/fonts/TTF/, and other application-specific directories already.
We're not suggesting moving the fonts is a proper fix, just it'll help us determine what the problem is.
So, please proceed as follows: 1. Try the patch.
If that works great, otherwise:
2. Try removing ukai.ttf first (just mv it to /tmp) if that doesn't help move the other ukai and uming fonts to /tmp and try again.
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #53 from Alexandre Julliard julliard@winehq.org 2008-03-26 11:58:35 --- Re-visiting the guard page thing: (this bug really needs to be split...)
(In reply to comment #6)
Attached patch fixes this. Notice it uses NtCurrentTeb()->Tib.StackLimit rather than the current NtCurrentTeb()->DeallocationStack to setup guard page address. This is required because .NET runtime starts page guard walking by looking at Tib.StackLimit until it reaches current stack pointer area.
StackLimit is supposed to point above the guard page, it's the start of the valid area (and yes there are apps that depend on this). So if .NET starts looking from StackLimit, creating a Windows-style guard page is not going to help.
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #54 from Hin-Tak Leung htl10@users.sourceforge.net 2008-03-26 14:48:59 --- (In reply to comment #52) <snipped>
So, please proceed as follows:
- Try the patch.
Yes, the patch works.
So:
1) there are other Arphic kai derivatives out there (and filtering by name is probably not effective); and also the Arphic kai font was the first commercial quality chinese font released under an open license, so it is extremely popular and most linux boxes comes with it optional.
2) might worth telling the Xorg people? (I believe they are the one who created it?) apparently http://www.freedesktop.org/wiki/Software/CJKUnifonts is the official URL.
1) the font issue wiki page needs to be updated for non-unbuntu and a different ukai releases - it looks like I have the latest already, and the wiki page never explained which direction one should go (it seems to suggest that it is a ubuntu customization which broke the font, rather than whatever); whereas I have a redhat variant of the latest ukai release.
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #55 from Anastasius Focht focht@gmx.net 2008-03-26 17:49:05 --- Hello,
--- quote --- StackLimit is supposed to point above the guard page, it's the start of the valid area (and yes there are apps that depend on this). So if .NET starts looking from StackLimit, creating a Windows-style guard page is not going to help. --- quote ---
As I already explained, there is currently no other way - there has to be a PAGE_GUARD page between StackLimit and current thread stack addr (< StackBase).
I illustrate the problem for other interested people a bit more...
Consider the following common scenario...
--- memory map for typical PE ---
address size contains type mapped as 00240000 00001000 guard page private (no access) 00241000 0010F000 main thread stack private read-write .. 00400000 00001000 PE header image read-write-copy 00401000 00047000 .text (code,imports) image read-write-copy 00448000 00007000 .rsrc (data, res) image read-write-copy 0044F000 00001000 image read-write-copy 00450000 00001000 .reloc (relocations) image read-write-copy .. --- memory map for typical PE ---
stack_lower_bound == 0x240000 == NtCurrentTeb()->DeallocationStack
--- retrieve lower stack bound --- MEMORY_BASIC_INFORMATION info; DWORD addr; VirtualQuery( &addr, &info, sizeof(MEMORY_BASIC_INFORMATION)); --- retrieve lower stack bound ---
offset value comment $+00 0034F000 BaseAddress $+04 00240000 AllocationBase $+08 00000004 AllocationProtect $+0C 00001000 RegionSize $+10 00001000 State $+14 00000004 Protect $+18 00020000 Type
stack_lower_bound = info.AllocationBase;
stack_base = NtCurrentTeb()->Tib.StackBase; ( == 0x350000)
--- retrieve stack base --- mov eax, large fs:[18h] ; NtCurrentTeb() mov eax, [eax+4] ; NtCurrentTeb()->Tib.StackBase --- retrieve stack base ---
guard page search algorithm (TRUE = found):
--- algorithm to search for guard page ---
search_start_addr = NtCurrentTeb()->Tib.StackLimit (= stack_lower_bound + page_size) == 0x241000 (page_size = 0x1000 for x86)
{ addr = search_start_addr; while( addr < stack_base) { VirtualQuery( addr, &info, sizeof(MEMORY_BASIC_INFORMATION)); if( info.Protect & PAGE_GUARD) return TRUE; addr += info.RegionSize; } return FALSE; }
--- algorithm to search for guard page ---
From first iteration:
offset value comment $+00 00241000 BaseAddress $+04 00240000 AllocationBase $+08 00000004 AllocationProtect $+0C 0010F000 RegionSize $+10 00001000 State $+14 00000004 Protect $+18 00020000 Type
Trace snippet of .NET 2.0 app (C++ -> managed exception transition + unwinding):
--- snip trace --- .. 003d:Call KERNEL32.RaiseException(e06d7363,00000001,00000003,0033e28c) ret=78158dd3 003d:trace:seh:raise_exception code=e06d7363 flags=1 addr=0x7b8419a0 003d:trace:seh:raise_exception info[0]=19930520 003d:trace:seh:raise_exception info[1]=0033e300 003d:trace:seh:raise_exception info[2]=79f9acc4 003d:trace:seh:raise_exception eax=7b82c3e9 ebx=7b8af3a4 ecx=00000000 edx=0033e278 esi=0033e278 edi=0033e1f0 003d:trace:seh:raise_exception ebp=0033e1d8 esp=0033e174 cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00000216 .. 003d:Call KERNEL32.RaiseException(e0434f4d,00000001,00000001,0033e294) ret=79f97065 003d:trace:seh:raise_exception code=e0434f4d flags=1 addr=0x7b8419a0 003d:trace:seh:raise_exception info[0]=80004001 003d:trace:seh:raise_exception eax=7b82c3e9 ebx=7b8af3a4 ecx=00000000 edx=0033e274 esi=0033e274 edi=0033e1f0 003d:trace:seh:raise_exception ebp=0033e1d8 esp=0033e174 cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00000212 ... 003d:Ret ntdll.RtlUnwind() retval=00000000 ret=79f9608c 003d: eax=00000000 ebx=00000001 ecx=0013de68 edx=0033dc34 esi=00000000 edi=0013de68 ebp=0033db50 esp=0033db44 ds=007b es=007b fs=0033 gs=003b flags=00000246 ... 003d:Call KERNEL32.VirtualQuery(00241000,0033d3d4,0000001c) ret=79f992fc 003d:Ret KERNEL32.VirtualQuery() retval=0000001c ret=79f992fc 003d:Call KERNEL32.VirtualQuery(00241000,0033e478,0000001c) ret=79f992fc 003d:Ret KERNEL32.VirtualQuery() retval=0000001c ret=79f992fc 003d:Call KERNEL32.VirtualProtect(0033d000,00000001,00000104,0033e498) ret=79e74b61 003d:trace:virtual:NtProtectVirtualMemory 0xffffffff 0x33d000 00000001 00000104 003d:trace:virtual:VIRTUAL_SetProt 0x33d000-0x33dfff cgrw- <segfault here> --- snip trace ---
First VirtualQuery() -> page guard search algorithm Second VirtualQuery() + VirtualProtect() -> page guard enabling code.
I'm not going to waste more time with explanations.
Please show me the offending apps which ought to break when a guard page is located at StackLimit. I might find a way to satisfy both - but I have to see the app code.
Regards
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #56 from Alexandre Julliard julliard@winehq.org 2008-03-27 04:19:36 --- (In reply to comment #55)
First VirtualQuery() -> page guard search algorithm Second VirtualQuery() + VirtualProtect() -> page guard enabling code.
I'm not going to waste more time with explanations.
Please show me the offending apps which ought to break when a guard page is located at StackLimit. I might find a way to satisfy both - but I have to see the app code.
You can't solve this by making it incompatible with what Windows does. The proper solution is to make sure that we handle guard pages correctly in the segfault handler, and that we can do that VirtualProtect call without crashing. Do you have a small test app demonstrating the problem?
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #57 from Anastasius Focht focht@gmx.net 2008-03-27 09:16:16 --- Hello,
--- quote --- Do you have a small test app demonstrating the problem? --- quote ---
Sure. A .NET app: http://www.aisto.com/roeder/dotnet/Download.aspx?File=Writer (simple WYSIWYG editor for HTML files) To download fill in the usual fake info in download form, e.g. "my name", "org", "fun@inter.net".
You need the .NET 2.0 redist package as prerequisite: http://www.microsoft.com/downloads/details.aspx?FamilyID=0856EACB-4362-4B0D-...
1. clean ~/.wine 2. copy the file "l_intl.nls" from a windows partition to ~/.wine/drive_c/windows/system32 3. sh winetricks gecko 4. set your wine to "Windows 2000" before install to work around unsupported reparse/junction Api 5. install .NET 2.0 Framework 6. unzip the app into some directory, start the app "<unzip-dir>\Build\Writer.exe"
Regards
http://bugs.winehq.org/show_bug.cgi?id=10467
David Gerard dgerard@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dgerard@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #58 from Alexandre Julliard julliard@winehq.org 2008-04-01 10:33:18 --- I looked into this, actually it doesn't start looking from StackLimit but from the base of the stack, so it should work fine to add a guard page below StackLimit the way it is on Windows.
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #59 from Dan Kegel dank@kegel.com 2008-04-02 08:30:50 --- Alexandre added the guard page, http://www.winehq.org/pipermail/wine-cvs/2008-April/041944.html
http://bugs.winehq.org/show_bug.cgi?id=10467
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #9240 is|0 |1 obsolete| |
--- Comment #60 from Anastasius Focht focht@gmx.net 2008-04-02 15:48:43 --- (From update of attachment 9240) Hello,
--- quote --- I looked into this, actually it doesn't start looking from StackLimit but from the base of the stack, so it should work fine to add a guard page below StackLimit the way it is on Windows. --- quote ---
Search start is stack allocation base + page_size (VirtualQuery) which was coincidentally StackLimit in the wine thread stack implementation before the fix.
By moving StackLimit to not include the newly added guard page (base + 2*page_size) your implementation preserves NT compatibility and looks obviously more correct ;-)
Besides the required page guard at stack base + page_size, .NET uncovered another page guard problem here.
I think wine should still be able to handle cases where apps try to setup page guard in current thread stack frame (using address of local variable) - at least preventing the segfault triggered by glibc mprotect code.
For this problem do you want a bug report? Though that's low priority then.
---
When the case mapping table "l_intl.nls" is autogenerated (see comment #27) this bug will be finished.
Install issues like NTFS junctions (XP config) are covered by other bug reports.
Regards
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #61 from Alexandre Julliard julliard@winehq.org 2008-04-02 16:43:35 --- (In reply to comment #60)
I think wine should still be able to handle cases where apps try to setup page guard in current thread stack frame (using address of local variable) - at least preventing the segfault triggered by glibc mprotect code.
Setting up a guard page is supposed to work too, if you have a case where it doesn't then yes please report it (in a new bug please, this one is getting really crowded...)
http://bugs.winehq.org/show_bug.cgi?id=10467
Nathan quest2013@emailengine.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|quest2013@emailengine.org |
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #62 from Dan Kegel dank@kegel.com 2008-05-11 11:23:51 --- I updated "winetricks dotnet20" to install a fixed arphic font and corefonts (to avoid two different crashes). It now sets up .net 2.0 well enough for this app, but only if you don't have msttcorefonts installed via linux (which makes the windows corefont installers exit silently).
http://bugs.winehq.org/show_bug.cgi?id=10467
Hans Leidekker hans@it.vu.nl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hans@it.vu.nl
--- Comment #63 from Hans Leidekker hans@it.vu.nl 2008-05-11 12:52:31 ---
It now sets up .net 2.0 well enough for this app, but only if you don't have msttcorefonts installed via linux (which makes the windows corefont installers exit silently).
I recall that the installers call CreateFontIndirect on the font to be installed and exit if that succeeds. You might want to just cabextract the files.
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #64 from Dan Kegel dank@kegel.com 2008-05-11 16:16:03 --- I would, but I don't think that leads to the correct entries in the registry. I could blow away all fonts listed in there that are pointed to by a z: path, but that might anger some users.
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #65 from Hans Leidekker hans@it.vu.nl 2008-05-12 08:27:03 --- This is what happens basically, for each font face within a given font installer:
CopyFile("C:\windows\temp\IXP000.TMP\Arialbd.TTF", "C\windows\fonts\Arialbd.TTF")
RegOpenKeyEx("SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Fonts") RegSetValueEx("Arial Bold (TrueType)")
AddFontResource("C:\windows\fonts\Arial.TTF") PostMessage(WM_FONTCHANGE)
The file copy and registry setting would be simple additions to winetricks. The AddFontResource and PostMessage calls are there to make the font available to existing and new processes in the current session. I suspect that we don't really need these but if we do a wineboot might provide a usable workaround.
http://bugs.winehq.org/show_bug.cgi?id=10467
Ger Teunis g.teunis@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|g.teunis@gmail.com |
http://bugs.winehq.org/show_bug.cgi?id=10467
Eugene Klimov slach@74mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |slach@74mail.ru
--- Comment #66 from Eugene Klimov slach@74mail.ru 2008-10-22 09:11:45 --- i'm installing Debian lenny WINE 1.0.1 + .NET 2.0 fine, but any access to Culture from .NET application crashed
$wine --version wine-1.0 after installing $./winetricks corefonts msxml3 msxml6 $./winetricks dotnet20 all ok with many "fixme:" messages
but when i running MSBuild.exe for compiling my simple C# Project $wine cmd CMD 1.0 z:\home\user> %windir%\Microsoft.NET\Framework\v2.0.50727\msbuild.exe z:\home\user\source\BuildTarget.xml /p:Configuration=Release 2>msbuild.stderr.log 1>msbuild.stdout.log
i have some WINE fixme messages -------------------------- fixme:shell:URL_ParseUrl failed to parse L"System" fixme:shell:URL_ParseUrl failed to parse L"Microsoft.Build.Engine" fixme:shell:URL_ParseUrl failed to parse L"Microsoft.Build.Framework" fixme:shell:URL_ParseUrl failed to parse L"MSBuild.resources" fixme:shell:URL_ParseUrl failed to parse L"MSBuild.resources" fixme:shell:URL_ParseUrl failed to parse L"System.Xml" fixme:shell:URL_ParseUrl failed to parse L"Microsoft.Build.Engine.resources" fixme:shell:URL_ParseUrl failed to parse L"Microsoft.Build.Engine.resources" fixme:shell:URL_ParseUrl failed to parse L"Microsoft.Build.Tasks" fixme:shell:URL_ParseUrl failed to parse L"Microsoft.Build.Utilities" fixme:shell:URL_ParseUrl failed to parse L"Microsoft.Build.Tasks.resources" fixme:shell:URL_ParseUrl failed to parse L"Microsoft.Build.Tasks.resources" fixme:shell:URL_ParseUrl failed to parse L"" fixme:ole:CoGetContextToken stub fixme:ntdll:RtlNtStatusToDosErrorNoTeb no mapping for c0150018 fixme:shell:URL_ParseUrl failed to parse L"" fixme:time:GetCalendarInfoW flag CAL_NOUSEROVERRIDE used, not fully implemented fixme:time:GetCalendarInfoW Unimplemented caltype 1 fixme:time:GetCalendarInfoW flag CAL_NOUSEROVERRIDE used, not fully implemented fixme:time:GetCalendarInfoW Unimplemented caltype 2 fixme:shell:URL_ParseUrl failed to parse L"mscorlib.resources" fixme:ole:CoGetContextToken stub fixme:ole:Context_QueryInterface interface not implemented {000001da-0000-0000-c000-000000000046} --------------------------
and i have MSBuild error with Culture settings -------------------------- Z:\home\user\make\mkinstall>CLS Z:\home\user\make\mkinstall>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\msbuild.exe ....\source\BuildTarget.xml /p:Configuration=Release Microsoft (R) Build Engine Version 2.0.50727.42 [Microsoft .NET Framework, Version 2.0.50727.42] Copyright (C) Microsoft Corporation 2005. All rights reserved.
Build started 22.10.2008 18:34:20. __________________________________________________ Project "Z:\home\user\source\BuildTarget.xml" (default targets):
Target ResolveAssemblyReferences: C:\windows\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets(1306,9): error MSB3095: Invalid argument. Culture name 'eo' is not supported. C:\windows\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets(1306,9): error MSB3095: Parameter name: name Done building target "ResolveAssemblyReferences" in project "BuildTarget.xml" -- FAILED.
Done building project "BuildTarget.xml" -- FAILED.
Build FAILED. C:\windows\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets(1306,9): error MSB3095: Invalid argument. Culture name 'eo' is not supported. C:\windows\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets(1306,9): error MSB3095: Parameter name: name 0 Warning(s) 1 Error(s)
Time Elapsed 00:00:00.83 --------------------------
for testing i write simple .NET Culture Listing application
ListCulture.cs see attachment <code> -------------------------- using System; using System.Collections.Generic; using System.Text; using System.Globalization;
namespace ListCulture { class Program { static void Main(string[] args) { List<string> list = new List<string>(); foreach (CultureInfo ci in CultureInfo.GetCultures(CultureTypes.AllCultures)) { string specName = "(none)"; try { specName = CultureInfo.CreateSpecificCulture(ci.Name).Name; } catch { } list.Add(String.Format("{0,-12}{1,-12}{2}", ci.Name, specName, ci.EnglishName)); }
list.Sort(); // sort by name
// write to console Console.WriteLine("CULTURE SPEC.CULTURE ENGLISH NAME");
Console.WriteLine("--------------------------------------------------------------"); foreach (string str in list) Console.WriteLine(str); } } } -------------------------- </code>
compiling ListCulture.cs under WINE %windir%\Microsoft.NET\Framework\v2.0.50727\csc /r:sysglobl.dll ListCulture.cs
all OK
but running ListCulture.exe 2> ListCulture.err.log have same error for WINE ---------------------- fixme:virtual:NtAllocateVirtualMemory MEM_WRITE_WATCH type not supported fixme:ole:CoGetContextToken stub fixme:time:GetCalendarInfoW flag CAL_NOUSEROVERRIDE used, not fully implemented fixme:time:GetCalendarInfoW Unimplemented caltype 1 fixme:time:GetCalendarInfoW Unimplemented caltype 2 fixme:shell:URL_ParseUrl failed to parse L"mscorlib.resources" fixme:advapi:CheckTokenMembership (0x14c 0x171ec8 0x33de88) stub! fixme:imm:ImmDisableIME (-1): stub Application tried to create a window, but no driver could be loaded. Make sure that your X server is running and that $DISPLAY is set correctly. err:ole:CoWaitForMultipleHandles Unexpected wait termination: -1, 87 err:ole:CoWaitForMultipleHandles Unexpected wait termination: -1, 87 fixme:ole:ProxyCliSec_QueryBlanket (0x122024, 0x33fd7c, 0x33fd80, (nil), 0x33fd84, 0x33fd88, (nil), (nil)): stub err:ole:CoQueryProxyBlanket -- failed with 0x80004001 fixme:advapi:RegisterEventSourceW ((null),L"VsJITDebugger"): stub fixme:advapi:ReportEventW (0xcafe4242,0x0001,0x0000,0xc0001000,0x5410d8,0x0001,0x00000004,0x33fdac,0x33fdb0): stub err:eventlog:ReportEventW L"An unhandled win32 exception occurred in ListCulture.exe [66]. Just-In-Time debugging this exception failed with the following error: 0x80004001\n\nCheck the documentation index for 'Just-in-time debugging, errors' for more information." fixme:advapi:DeregisterEventSource (0xcafe4242) stub -------------
and exeption for ListCulture.exe --------------------------
Unhandled Exception: System.ArgumentException: Culture name 'eo' is not supported. Parameter name: name at System.Globalization.CultureTableRecord..ctor(String cultureName, Boolean useUserOverride) at System.Globalization.CultureTableRecord.GetCultureTableRecord(String name, Boolean useUserOverride) at System.Globalization.CultureTableRecord.GetCultureTableRecord(Int32 cultureId, Boolean useUserOverride) at System.Globalization.CultureInfo..ctor(Int32 culture, Boolean useUserOverride) at System.Globalization.CultureInfo..ctor(Int32 culture) at System.Globalization.CultureTable.GetCultures(CultureTypes types) at ListCulture.Program.Main(String[] args)
change locale
locale LANG=en_US.UTF-8 LC_CTYPE="en_US.utf8" LC_NUMERIC="en_US.utf8" LC_TIME="en_US.utf8" LC_COLLATE="en_US.utf8" LC_MONETARY="en_US.utf8" LC_MESSAGES="en_US.utf8" LC_PAPER="en_US.utf8" LC_NAME="en_US.utf8" LC_ADDRESS="en_US.utf8" LC_TELEPHONE="en_US.utf8" LC_MEASUREMENT="en_US.utf8" LC_IDENTIFICATION="en_US.utf8" LC_ALL=en_US.utf8
or
locale LANG=ru_RU.cp1251 LC_CTYPE="ru_RU.cp1251" LC_NUMERIC="ru_RU.cp1251" LC_TIME="ru_RU.cp1251" LC_COLLATE="ru_RU.cp1251" LC_MONETARY="ru_RU.cp1251" LC_MESSAGES="ru_RU.cp1251" LC_PAPER="ru_RU.cp1251" LC_NAME="ru_RU.cp1251" LC_ADDRESS="ru_RU.cp1251" LC_TELEPHONE="ru_RU.cp1251" LC_MEASUREMENT="ru_RU.cp1251" LC_IDENTIFICATION="ru_RU.cp1251" LC_ALL=ru_RU.cp1251
nothing effect
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #67 from Eugene Klimov slach@74mail.ru 2008-10-22 09:14:33 --- Created an attachment (id=16797) --> (http://bugs.winehq.org/attachment.cgi?id=16797) Listing of available Culture in .NET 2.0
Listing of available Culture in .NET 2.0 have Exception Unhandled Exception: System.ArgumentException: Culture name 'eo' is not supported.
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #68 from Eugene Klimov slach@74mail.ru 2008-10-22 10:10:10 --- Created an attachment (id=16798) --> (http://bugs.winehq.org/attachment.cgi?id=16798) just writ CurrentCulture
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #69 from Eugene Klimov slach@74mail.ru 2008-10-22 10:15:02 --- CurrentCulture.cs
using System; using System.Collections.Generic; using System.Text; using System.Globalization;
namespace CurrentCulture { class Program { static void Main(string[] args) { CultureInfo ci = System.Threading.Thread.CurrentThread.CurrentCulture;
Console.WriteLine("System.Threading.Thread.CurrentThread.CurrentCulture"); Console.WriteLine(ci.Name); } } }
working fine
fixme:virtual:NtAllocateVirtualMemory MEM_WRITE_WATCH type not supported fixme:ole:CoGetContextToken stub System.Threading.Thread.CurrentThread.CurrentCulture en-US fixme:ole:CoGetContextToken stub
http://bugs.winehq.org/show_bug.cgi?id=10467
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
--- Comment #70 from Austin English austinenglish@gmail.com 2008-11-23 22:35:39 --- Anastasius, what's the current status of this bug?
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #71 from James Hawkins truiken@gmail.com 2008-11-23 22:43:08 --- (In reply to comment #70)
Anastasius, what's the current status of this bug?
The current status is listed in the comments, specifically comment #60.
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #72 from Witold Baryluk baryluk@smp.if.uj.edu.pl 2008-12-15 06:09:15 --- FastMD5 is working pretty well in 1.1.10. Calculates correctly all hashes, there are some problems with clipboard handling.
Reproduce: clear wine ./winetricks corefonts msxml3 msxml6 ./winetricks dotnet20 wine ./Fastmd5.exe Click Open, Select info.txt, Click "Create Hash", copy anything (can be empty string) to the clipboard (from any application), click "<- Clipboard", Click one more time "Create Hash", click "Crate Hash" one more time.
Crash.
Problem is in fixme:ole:CoGetContextToken stub
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #73 from Anastasius Focht focht@gmx.net 2008-12-15 12:34:04 --- Hello,
--- quote --- Reproduce: clear wine ./winetricks corefonts msxml3 msxml6 ./winetricks dotnet20 wine ./Fastmd5.exe --- quote ---
I don't see the point of all those dependencies? The FastMD5 example app only needs .NET 2.0 Framework (winetricks dotnet20), nothing more.
--- quote --- FastMD5 is working pretty well in 1.1.10. Calculates correctly all hashes, there are some problems with clipboard handling.
.. Click Open, Select info.txt, Click "Create Hash", copy anything (can be empty string) to the clipboard (from any application), click "<- Clipboard", Click one more time "Create Hash", click "Crate Hash" one more time.
Crash --- quote ---
The problem you are experiencing has nothing to do with clipboard action. Ideally any other operation can trigger the same problem - you just need to wait long enough (until the garbage collector/finalizers ought to run). It's already covered by bug 13462 though not well understood from reading comments. The patch there prevents the crash by providing needed interface stub to the .NET runtime.
.NET simply treats the callback stub "unimpl" as disconnected RPC endpoint. There will be small resource leaks (for runtime callable wrapper) when the garbage collector/finalizer is run but that causes no harm - and most importantly: prevents a crash. This applies to all .NET apps, maybe the importance for bug 13462 is underestimated hence no further attempt was made to get a patch in.
--- quote --- Problem is in fixme:ole:CoGetContextToken stub --- quote ---
Don't try to guess... it won't work ;-) While this stub will be a source of problem in future (needed to support COM context switching properly) this FIXME can be currently ignored.
Regards
http://bugs.winehq.org/show_bug.cgi?id=10467
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Making Microsoft .NET 2.0 to|Microsoft .NET Framwork 2.0 |work in wine, based on |requires l_intl.nls (unicode |example app FastMD5 1.4 for |casing tables) |NET 2.0 | Version|CVS/GIT |0.9.49.
--- Comment #74 from Anastasius Focht focht@gmx.net 2009-01-17 05:59:43 --- Hello,
corrected version tag and changed summary accordingly to current state. All other issues this showcase/meta bug is about have been fixed for some time now. The remaining ones have separate bug reports.
Regards
http://bugs.winehq.org/show_bug.cgi?id=10467
James McKenzie jjmckenzie51@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|jjmckenzie51@sprintpcs.com |jjmckenzie51@earthlink.net
http://bugs.winehq.org/show_bug.cgi?id=10467
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jordan.w.bradley@gmail.com
--- Comment #75 from Austin English austinenglish@gmail.com 2009-03-31 15:08:52 --- *** Bug 17909 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=10467
Scott Ritchie scott@open-vote.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |scott@open-vote.org Target Milestone|--- |1.2.0
--- Comment #76 from Scott Ritchie scott@open-vote.org 2009-07-14 19:17:08 --- "Almost done", affects .net and thusly many apps in a big way, nominating for 1.2.
http://bugs.winehq.org/show_bug.cgi?id=10467
Scott Ritchie scott@open-vote.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |scott@open-vote.org Target Milestone|--- |1.2.0
--- Comment #76 from Scott Ritchie scott@open-vote.org 2009-07-14 19:17:08 --- "Almost done", affects .net and thusly many apps in a big way, nominating for 1.2.
--- Comment #77 from Vincent Povirk madewokherd@gmail.com 2009-10-22 11:13:40 --- Andrey Turkin has sent some patches for this: http://www.winehq.org/pipermail/wine-patches/2009-January/067527.html http://www.winehq.org/pipermail/wine-patches/2009-January/068072.html http://www.winehq.org/pipermail/wine-patches/2009-October/080191.html
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #78 from Vincent Povirk madewokherd@gmail.com 2009-10-30 10:13:11 --- Andrey Turkin sent another patch: http://www.winehq.org/pipermail/wine-patches/2009-October/080650.html
http://bugs.winehq.org/show_bug.cgi?id=10467
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |adys.wh@gmail.com
--- Comment #79 from Jerome Leclanche adys.wh@gmail.com 2009-12-03 15:33:33 --- (In reply to comment #78)
Andrey Turkin sent another patch: http://www.winehq.org/pipermail/wine-patches/2009-October/080650.html
Did they get in? Any update?
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #80 from Austin English austinenglish@gmail.com 2009-12-03 18:02:26 --- (In reply to comment #79)
(In reply to comment #78)
Andrey Turkin sent another patch: http://www.winehq.org/pipermail/wine-patches/2009-October/080650.html
Did they get in? Any update?
http://source.winehq.org/git/wine.git/?a=history;f=programs/wineboot;hb=HEAD
No.
http://bugs.winehq.org/show_bug.cgi?id=10467
Andrew Nguyen arethusa26@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kovariadam@gmail.com
--- Comment #81 from Andrew Nguyen arethusa26@gmail.com 2010-02-09 03:24:50 --- *** Bug 21136 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #82 from James McKenzie jjmckenzie51@earthlink.net 2010-02-15 14:51:56 --- Has anyone tried installing dotnet 20 through Winetricks with Wine 1.1.38? I keep on getting a Coinitialize version mismatch error when I try to run BibleStudyPro with dotnet 2.0 without any service packs.
http://bugs.winehq.org/show_bug.cgi?id=10467
Andrew Nguyen arethusa26@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |goonstk@yahoo.com
--- Comment #83 from Andrew Nguyen arethusa26@gmail.com 2010-02-21 12:58:58 --- *** Bug 21803 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=10467
Andrew Nguyen arethusa26@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |danfoxdavies@googlemail.com
--- Comment #84 from Andrew Nguyen arethusa26@gmail.com 2010-03-13 09:23:55 --- *** Bug 22025 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=10467
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|mscoree |-unknown
--- Comment #85 from Vincent Povirk madewokherd@gmail.com 2010-03-25 16:28:15 --- Not a bug in wine's builtin mscoree, changing component.
http://bugs.winehq.org/show_bug.cgi?id=10467
Andrew Nguyen arethusa26@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |prockop@gmail.com
--- Comment #86 from Andrew Nguyen arethusa26@gmail.com 2010-03-27 15:00:24 --- *** Bug 22186 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #87 from Danfox Davies danfoxdavies@googlemail.com 2010-03-27 16:10:00 --- Created an attachment (id=27072) --> (http://bugs.winehq.org/attachment.cgi?id=27072) SR3D Builder crash output with suggested workaround .net 2.0 via winetricks already implemented.
This is the output of SR 3D Builder (an LDraw application) on attempting to run it in 1.1.41 with .net 2.0 installed via winetricks. Any suggestions?
http://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #88 from Andrew Nguyen arethusa26@gmail.com 2010-03-27 16:15:35 --- (In reply to comment #87)
Created an attachment (id=27072)
--> (http://bugs.winehq.org/attachment.cgi?id=27072) [details]
SR3D Builder crash output with suggested workaround .net 2.0 via winetricks already implemented.
This is the output of SR 3D Builder (an LDraw application) on attempting to run it in 1.1.41 with .net 2.0 installed via winetricks. Any suggestions?
That problem and output has nothing to do with this bug, but it's probably bug 16418.
http://bugs.winehq.org/show_bug.cgi?id=10467
Andrew Nguyen arethusa26@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |igor.demyanov@gmail.com
--- Comment #89 from Andrew Nguyen arethusa26@gmail.com 2010-04-16 14:33:18 --- *** Bug 22376 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=10467
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #90 from Alexandre Julliard julliard@winehq.org 2010-05-07 09:45:17 --- Fixed now.
http://bugs.winehq.org/show_bug.cgi?id=10467
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #91 from Alexandre Julliard julliard@winehq.org 2010-05-07 13:28:55 --- Closing bugs fixed in 1.1.44.
http://bugs.winehq.org/show_bug.cgi?id=10467
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |dotnet, download, Installer Fixed by SHA1| |930a13dd86613e79fd6d011edcf | |d27b340dce6b6 Component|-unknown |tools
--- Comment #92 from Anastasius Focht focht@gmx.net 2011-10-12 04:13:33 CDT --- Hello,
filling/correcting fields ...
Regards
http://bugs.winehq.org/show_bug.cgi?id=10467
Sylvain Petreolle spetreolle@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |spetreolle@yahoo.fr Summary|Microsoft .NET Framwork 2.0 |Microsoft .NET Framework |requires l_intl.nls |2.0 requires l_intl.nls |(unicode casing tables) |(unicode casing tables)
https://bugs.winehq.org/show_bug.cgi?id=10467
Jacob Hrbek werifGX@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |werifGX@gmail.com
--- Comment #93 from Jacob Hrbek werifGX@gmail.com --- This bug has entry in winetricks so i'm requesting more info: Which wine versions are affected by this?
https://bugs.winehq.org/show_bug.cgi?id=10467
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #94 from Zebediah Figura z.figura12@gmail.com --- (In reply to Jacob Hrbek from comment #93)
This bug has entry in winetricks so i'm requesting more info: Which wine versions are affected by this?
Presumably all versions up to and including 1.1.43, or is that not what you mean?
https://bugs.winehq.org/show_bug.cgi?id=10467
--- Comment #95 from Jacob Hrbek werifGX@gmail.com --- (In reply to Zebediah Figura from comment #94)
(In reply to Jacob Hrbek from comment #93)
This bug has entry in winetricks so i'm requesting more info: Which wine versions are affected by this?
Presumably all versions up to and including 1.1.43, or is that not what you mean?
Assuming `1.1.43` being a wine version then it's exactly what i was looking for thanks
(currently winetricks has `w_workaround_bug` that returns true/false depending on specified wine version)
https://bugs.winehq.org/show_bug.cgi?id=10467
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- URL|http://www.paehl.de/english |https://web.archive.org/web |.php |/20081112195357/http://www. | |paehl.de/fastmd5_net20.zip
-
wine-bugs＠winehq.org -
WineHQ Bugzilla