Created attachment 9195 [details]
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.

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.

Created attachment 9198 [details]
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

Created attachment 9199 [details]
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

Created attachment 9204 [details]
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

Created attachment 9238 [details]
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

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.

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

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

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

*** Bug 9897 has been marked as a duplicate of this bug. ***

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

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

Ok, thanks very much, i'll update the howto (i put it in the appdb)

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

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.

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? 

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

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?

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&section=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

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

They imported it from wine, I think.  See
http://www.mail-archive.com/wine-devel@winehq.com/msg00408.html

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

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.

s/I don't nothing/I see nothing/

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

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.

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

*** Bug 11395 has been marked as a duplicate of this bug. ***

*** Bug 11501 has been marked as a duplicate of this bug. ***

*** Bug 11502 has been marked as a duplicate of this bug. ***

Comment on attachment 9195 [details]
expose PEB loader lock to make .NET framework (ui) to work

Obsoleting some patches which have been fixed in GIT for some time now.

http://article.gmane.org/gmane.comp.emulators.wine.cvs/35801

Comment on attachment 9198 [details]
patch which keeps .NET gui apps happy by adjusting winstation->flags WSF_VISIBLE

Obsoleting my patches, fixed in GIT for some time now.

http://www.winehq.org/pipermail/wine-cvs/2007-December/038922.html

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

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

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


 

>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

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

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.

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.

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.

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. 

Created attachment 11667 [details]
Hack to skip loading of ukai.ttf

(In reply to comment #44)
> Created an attachment (id=11667) [details]
> Hack to skip loading of ukai.ttf
> 

Could you try the above patch?  Native gdiplus has problems with ukai.ttf.

Or follow http://www.codeweavers.com/support/wiki/faq/fontissues

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.

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.

First thing to try apparently is move the (potentially) problematic fonts
aside and see if that helps.

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

(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 #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.

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.

(In reply to comment #52)
<snipped>
> So, please proceed as follows:
> 1. 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.

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

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

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-8EDD-AAB15C5E04F5&displaylang=en 

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

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.

Alexandre added the guard page,
http://www.winehq.org/pipermail/wine-cvs/2008-April/041944.html

Comment on attachment 9240 [details]
patch to fix bottom stack guard page to allow CLR exceptions from .NET runtime to succeed

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

(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...)

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

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

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.

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.

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

Created attachment 16797 [details]
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.

Created attachment 16798 [details]
just writ CurrentCulture

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

Anastasius, what's the current status of this bug?

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

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

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

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

*** Bug 17909 has been marked as a duplicate of this bug. ***

"Almost done", affects .net and thusly many apps in a big way, nominating for 1.2.

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

Andrey Turkin sent another patch: http://www.winehq.org/pipermail/wine-patches/2009-October/080650.html

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

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

*** Bug 21136 has been marked as a duplicate of this bug. ***

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.

*** Bug 21803 has been marked as a duplicate of this bug. ***

*** Bug 22025 has been marked as a duplicate of this bug. ***

Not a bug in wine's builtin mscoree, changing component.

*** Bug 22186 has been marked as a duplicate of this bug. ***

Created attachment 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?

(In reply to comment #87)
> Created an attachment (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.

*** Bug 22376 has been marked as a duplicate of this bug. ***

Fixed now.

Closing bugs fixed in 1.1.44.

Hello,

filling/correcting fields ...

Regards

This bug has entry in winetricks so i'm requesting more info: Which wine versions are affected by this?

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

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