Hello, im trying to run an .NET 1.1 Program. .NET V1.1 Installation works fine, but when i want to start the Program i get some errors and Program exits Code: fixme:virtual:NtAllocateVirtualMemory MEM_WRITE_WATCH type not supported fixme:virtual:NtAllocateVirtualMemory MEM_WRITE_WATCH type not supported fixme:shell:URL_ParseUrl failed to parse L"mscorlib" 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. 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:apartment_createwindowifneeded CreateWindow failed with error 1114 fixme:shell:URL_ParseUrl failed to parse L"System.Data" Maybe this is an known bug or someone has a workthru for me. Thanks a lot
MasterTH wrote:> Hello, > > im trying to run an .NET 1.1 Program. .NET V1.1 Installation works fine, but when i want to start the Program i get some errors and Program exits > > > Code: > > fixme:virtual:NtAllocateVirtualMemory MEM_WRITE_WATCH type not supported > fixme:virtual:NtAllocateVirtualMemory MEM_WRITE_WATCH type not supported > fixme:shell:URL_ParseUrl failed to parse L"mscorlib" > 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. > 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:apartment_createwindowifneeded CreateWindow failed with error 1114 > fixme:shell:URL_ParseUrl failed to parse L"System.Data" > > >What program are you trying to run? I am assuming that you are using version 0.9.57 of Wine as well. James McKenzie
i'm working in a government. It's SD.NET Nobody would know about it Code: linux-c5xy:~ # wine --version wine-0.9.57
ok, is it on the roadmap already??
Good Morning from germany, sorry code is not availible anywhere. But i tried a different program with uses the .NET Framework 1.1. Here is the Link http://www.winload.de/screenshots/41122/Internet/Internettools/DSLWatch.NET.1.6.html Installation works fine, after starting the Program the same crash appears. With an other .NET DLL but i think the problem is the same. Here's the console output: Code: fixme:virtual:NtAllocateVirtualMemory MEM_WRITE_WATCH type not supported fixme:virtual:NtAllocateVirtualMemory MEM_WRITE_WATCH type not supported fixme:shell:URL_ParseUrl failed to parse L"mscorlib" fixme:shell:URL_ParseUrl failed to parse L"System.Windows.Forms"
i dont know a lot what happens in the installation progress of the .NET Framework, but it seems that the problem is the registration of the .NET-Modules. When coding an .NET program you use this System-Variables Like: Import System.Data
James McKenzie wants to know if there is another .NET program with the same bug for testing> MasterTH wrote: > Quote: > i'm working in a government. It's SD.NET Nobody would know about it > > > I understand. Is this code available somewhere? > Quote: > Code: > > linux-c5xy:~ # wine --version > wine-0.9.57 > > > This looks good. > > If the program is not available to the public, then try another .NET 1.1 > program that is and see if the error can be reproduced. If we cannot > test the program to find the bug, we cannot hope to fix it. > > James McKenzie
fixme:virtual:NtAllocateVirtualMemory MEM_WRITE_WATCH type not supported is probably NOT the reason for the crash. I have it too on my .NET application and I can safely ignore it because the application is not affected. If you read some documentation about the net, you will see that the .NET is using JIT and not MEM_WRITE_WATCH but MEM_WRITE_WATCH is used by Visual Basic which leads me to the (uneducated) opinion that this error is just thrown by the C++ on which the .NET is based. However as per WINDOWS_2000 if MEM_WRITE_WATCH is not supported, it is just ignored by the concerned components. Please do not fire on me if there is a mistake in what I said [Laughing]
Maybe you are right. I just found this information on an interview about the
release of the .NET when I was looking for this error myself.
I would not even recognize a VB .NET application even if it were in front of my
nose.
quote:
It seems that there is. The Windows VirtualAlloc function allows us to specify
that the allocated region should be "write watched" (using the
MEM_WRITE_WATCH flag) so that further writes to it will be recorded and can then
be retrieved using the GetWriteWatch API. The granularity of the watch,
naturally, is in pages, so it requires more work on the garbage collector's
side after determining that the area has been written to, but it seems that the
performance gains (from not using the JIT-generated write barrier thunk) should
be more significant.
The question I was talking about, then, is why doesn't the .NET GC use this
built-in memory watch mechanism, supplied by the Win32 API? The following blog
entry notes this possibility (in section 3.2.4), but does not elaborate
regarding the reasons behind the particular choice made in .NET. I have several
speculations (which are just that - speculations) and am still pursuing a more
definitive answer:
* The aforementioned API is not supported on Windows 95 (which is, perhaps,
not so surprising), but it is not supported on Windows 2000 as well. This would
limit the .NET framework's compatibility with these platforms (although in
those particular cases the JIT-thunk approach could be adopted).
* The aforementioned API is Windows-specific and does not provide any
compatibility with other platforms. The JIT-generated write barrier is generic
and theoretically can work on any platform.
* The performance penalty of using the MEM_WRITE_WATCH flag for writing to a
region of memory is bigger than the thunk generated by the JIT. Note that a
very primitive measurement I've performed indicates an 8% performance
penalty when writing to memory protected by a write watch as opposed to writing
to memory that is not protected by a write watch (don't quote me on this
:-)).
End of quote
http://blogs.microsoft.co.il/blogs/sasha/archive/2007/02/09/Fun-with-the-.NET-GC_2C00_-Paging_2C00_-Generations-and-Write-Barriers.aspx
I have run but I changed the source because of problems with the tmp directory (mismatch between the ownership of files in the wine directory and the tmp directory). It does not work on me with the standard wine. I can test your software on my Wine where it is working but only .NET 2 is installed.
ok i think we've to wait untl .net is supported by wine. hopefully we're not fare away
i'll try and give report later
i tried it, but the same error appears.
In my opinion, the .NET will be only working in filesystem where not most of it belongs to root (like it seems to be on ubuntu). During the installation of the .NET, the installer seems to be picking the config file of the distribution to know what is your printer settings, temporary directory etc. While this is probably meant with "the .NET is set to work on any o/s with any configuration" if it does happen that it does only read the file but writes on it - then you will have a problem for the coming months. my 2 c (and knowledge that without the directory check the .NET installation goes much further)