Re: [Mono-dev] [CI] RFC - Mono now building on Cygwin/Windows with Appveyor

2014-10-26 Thread Vincent Povirk 
 - I'd also like to run the Mono tests as a part of the build
 verification. Are they expected to work under Windows/Cygwin?

I was not able to run the tests on Windows/Mono in current master. I
made this PR to address that: https://github.com/mono/mono/pull/1360

They should run on Windows/.NET without that patch.

I don't expect them to pass, even on .NET, and I think it'd be a large
effort to whip them into shape.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on Windows issues.

2014-10-16 Thread Vincent Povirk 
 What's the estimation of effort required to get mono buildable in
 windows and debuggable in VS? 6 man months? 18 man months?

I do builds from master for Windows regularly (but on Linux using
mingw-w64), so getting it to work shouldn't be anywhere near that
difficult. I've seen someone on irc who does builds on Windows using
VS. The Windows build on master is chronically broken but also
chronically fixed by people who rely on it. Often the build happens to
be broken during a release, and that is never fixed. (It's entirely
possible, however, that no one uses cygwin to build on master and it
never gets fixed.)

CI on Windows would certainly be helpful, especially if it included
running the Mono tests in .NET (so we know the tests are really
correct).

As for the original issue in this thread:

In file included from socket-io.c:30:0:
/usr/i686-pc-mingw32/sys-root/
mingw/include/ws2tcpip.h:38:2: error:
#error ws2tcpip.h is not compatible with winsock.h. Include
winsock2.h instead.

I don't know anything about building with cygwin, but I would guess
something in your version of the standard cygwin headers is pulling in
winsock.h. Easiest way to find it is probably to add a define to
socket-io.c before the includes that will conflict with something
defined by winsock.h, i.e. add int accept; to the top of the file.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] mono_thread_manage causes subsequent mono_jit_cleanup call to hang?

2014-09-23 Thread Vincent Povirk 
 How about internally renaming mono_thread_manage and add a no-op version of
 it.

 It would retain compatibility with wine and would not further complicate the
 shutdown sequence.

 Sounds good to me.

I did some further research, and it seems this would break the
shutdown process used by coree.c:

mono_thread_manage ();
mono_runtime_quit ();

I guess Wine could use that same process, as mono_runtime_quit just
calls mini_cleanup. I expect it to work with all existing Mono
versions, but I want to make sure first that it won't be broken in the
future.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] mono_thread_manage causes subsequent mono_jit_cleanup call to hang?

2014-09-12 Thread Vincent Povirk 
On Fri, Sep 12, 2014 at 12:47 AM, Rodrigo Kumpera kump...@gmail.com wrote:
 How about internally renaming mono_thread_manage and add a no-op version of
 it.

 It would retain compatibility with wine and would not further complicate the
 shutdown sequence.

Sounds good to me.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] mono_thread_manage causes subsequent mono_jit_cleanup call to hang?

2014-09-10 Thread Vincent Povirk 
With a recent master build of Mono, I'm getting hangs in Wine when a
.NET exe exits. I think it's related to this commit:

commit 1996d664b4be7b97921485871f756db1d58011fe
Author: Rodrigo Kumpera kump...@gmail.com
Date:   Mon Aug 25 14:37:22 2014 -0400

[jit] Ensure no threads are running when the JIT is asked to cleanup.

Currently, our main function for running a .exe (_CorExeMain) exits by
doing this:

mono_thread_manage();
mono_jit_cleanup(domain);
return exit_code;

The hang is in the mono_jit_cleanup() call. I found that if I don't
call mono_thread_manage() first, it no longer hangs.

So that leads me to ask the following questions:

1. Is my use of mono_thread_manage correct? I thought it was my
responsibility to call this before mono_jit_cleanup, but that commit
seems to imply it's not my responsibility (but was still necessary in
all previous versions because Mono was broken).

2. Should Mono be fixed to account for what I was doing? I'd prefer to
have code that is as version-independent as possible. Maybe mono could
somehow detect that mono_thread_manage was already completed by the
current thread, and do nothing in this case?

3. Is there something else I can do on my end to fix this that won't
break with old Mono versions?
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] mono_thread_manage causes subsequent mono_jit_cleanup call to hang?

2014-09-10 Thread Vincent Povirk 
 2. Should Mono be fixed to account for what I was doing? I'd prefer to
 have code that is as version-independent as possible. Maybe mono could
 somehow detect that mono_thread_manage was already completed by the
 current thread, and do nothing in this case?

I wrote a patch using this approach:
https://github.com/madewokherd/mono/commit/7baf38fd134f92f7d80f43bb3cf6d77122b3eb1e

But I'm really not sure about this.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Killing .NET 2.0 support?

2014-05-21 Thread Vincent Povirk 
On Wed, May 21, 2014 at 8:19 AM, Stefanos A. stapos...@gmail.com wrote:
 You might wish to make a heads up announcement to give distros some time to
 adapt (in the unlikely case some might wish to implement some sort of
 side-by-side installation for compatibility.) The Wine project may also be
 affected, since they are now shipping Mono/Windows.

As long as we can still support Windows programs, I don't mind. We've
been using the 2.0 runtime for 1.x for a while, and I haven't seen any
problems relating to that.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] mono and unmanaged code

2014-03-28 Thread Vincent Povirk 
 If that isn’t possible, you should look into using Wine. Mono should run atop 
 Wine (last I heard…), so this may be a viable solution for you.

The default for Wine nowadays (since 1.5 or so) is to install Mono
automatically (for various reasons, it uses a special Windows build)
and use it to run any managed code. So trying it should be simple, at
least.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] mingw-w64 build broken

2014-02-05 Thread Vincent Povirk 
With current master, my mingw-w64 build is failing with the following error:

../../../mono/mono/metadata/sgen-gc.c:4855:19: error:
'mono_gc_pthread_exit' undeclared (first use in this function)

It seems to be related to commit
6427caaea886e089c7b2941137af8d918e199df0. This function is not present
in the Windows build, but I don't know if it's good enough to just
ExitThread on Windows.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Linux: can I access a .NET 4.0 DLL from regular DLL running an EXE under Wine?

2013-11-01 Thread Vincent Povirk 
  The executable file calls a standard Windows DLL, which in turn accesses a
 .NET 4.0 DLL.  At the point that this .NET 4.0 DLL is first accessed, the
 app will crash (obviously, since Wine doesn't know of .NET).

This case is within Wine's scope, and Wine ships with a build of Mono
for this purpose. See http://wiki.winehq.org/Mono. The MS
implementation of the .NET Framework can also be installed and tends
to work better.

 I did try Wine's regsvr32 to register the .NET DLLs, but as I expected it
 failed.  What I really need is the Mono / Wine / Linux equivalent of
 regasm.exe (that's how these .NET 4.0 DLLs are registered on Windows).

We don't have a replacement for regasm yet, but depending on the
extent of your program's needs, you might be able to use a .reg and
.tlb file from regasm on Windows.

Is this software publicly available? It could be a useful test case
for COM integration.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] GSoC 2012 Proposal - WPF

2012-03-28 Thread Vincent Povirk 
Hi,

Since you're interested in Mono in Wine, I should probably explain the
current situation.

Currently, it's possible to install Mono for Windows in Wine, and
Wine's mscoree.dll will find the Mono install and use it to run .NET
code. This is not very useful because of incompatibilities and missing
libraries (notably WPF, msvcm, and XNA), and it tends to be confusing
for users, who have a choice of Mono and native .NET, though Wine will
always recommend Mono. Native .NET can only really be installed
properly via winetricks.

I'm working on a Mono package that will work similar to wine-gecko. It
will install automatically if native .NET is not present and include a
replacement for any MS .NET components that we can't use as-is (due to
licensing or compatibility problems). My hope is to create stubs for
msvcm, WPF, and XNA, so that those projects are slightly more
inviting. (Actually, for XNA I'm hoping to take advantage of MonoGame,
but I haven't yet done the research on making them binary compatible.)

The Mono community is generally not very interested in this, as they
are more focused on being a development platform than a compatibility
layer. This is working out very well for them, and Mono is very useful
as such, so I think that makes sense.

The Wine community is more interested in replacing .NET components
like WPF, but AFAIK none of us know any details of WPF's API, or what
you would have to do to implement it. So while the Wine project would
likely be interested in such a project, I don't think we could provide
much guidance with the technical issues around WPF specifically, or
how to properly scope the effort. So it is probably not a good project
right now, but it might be next year when the Mono packaging for Wine
will be further along.

We really need people who can work on .NET code for Wine, and I'm only
expecting that need to increase. So I'd like to help get you started,
but I fear there isn't much I can do. I'm sorry we're not yet prepared
for a gsoc project in this area.

I do remember asking about the possibility of porting parts of WPF in
Moonlight to work in plain Mono, and I was told it would be difficult
to separate them from Moonlight.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] [PATCH] System.Windows.Forms.Mime: Use freedesktop.org only on Unix platforms.

2011-03-29 Thread Vincent Povirk 
This shouldn't be used in an environment like Wine, where the FDO mime
files of a real Windows system can be accessed.
From f08711c13f10237d56b29e5fd5f95b8be70ce90f Mon Sep 17 00:00:00 2001
From: Vincent Povirk madewokh...@gmail.com
Date: Tue, 29 Mar 2011 13:59:09 -0500
Subject: [PATCH] System.Windows.Forms.Mime: Use freedesktop.org only on Unix 
platforms.

---
 .../System.Windows.Forms/Mime.cs   |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Mime.cs 
b/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Mime.cs
index f317c0a..3accd85 100644
--- a/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Mime.cs
+++ b/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Mime.cs
@@ -645,6 +645,11 @@ namespace System.Windows.Forms

public int Init ()
{
+   int p = (int) Environment.OSVersion.Platform;
+   if ((p != 4)  (p != 6)  (p != 128))
+   // Not running on Unix.
+   return -1;
+
CheckFDOMimePaths ();

if (!fdo_mime_available)
-- 
1.7.2.5

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] [PATCH] Replace ENABLE_COREE with a runtime switch.

2011-03-18 Thread Vincent Povirk 
On Fri, Mar 18, 2011 at 12:38 PM, Rodrigo Kumpera kump...@gmail.com wrote:
 Does it break the verifier without mixed mode enabled? If it doesn't
 looks good to me.

That worked in my testing (and failed with mixed mode enabled).
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] [PATCH] Replace ENABLE_COREE with a runtime switch.

2011-03-07 Thread Vincent Povirk 
This patch mostly reverts 666d37829304e85f72969c44e92bc11ca167a272,
which put Mono's mixed-mode support in #ifdef ENABLE_COREE, disabling
it by default on Windows.

It was disabled because it broke the verifier, and it still does.

Since most of the new behavior is dependent on whether coree has been
hooked, or whether a particular image has been loaded using the OS
loader, skipping the hook step effectively disables coree at runtime.
So this patch moves that step out of mono_init_internal and into
mono_main, where it is dependent on a runtime switch.

Even if this didn't break the verifier, I think it's an intrusive,
hacky change to how Mono loads things that almost no one needs, and so
having it default off makes sense. Also, (my real motive) it's a step
towards my goal of getting Wine's builtin mscoree.dll to use Mono's
mixed-mode support without indirectly causing itself to be hooked.
From 1a6218abd8a3bec45d09cb2ff3b1404eb0ffa8f2 Mon Sep 17 00:00:00 2001
From: Vincent Povirk vinc...@codeweavers.com
Date: Mon, 7 Mar 2011 13:41:46 -0600
Subject: [PATCH] Replace ENABLE_COREE with a runtime switch.

---
 mono/metadata/assembly.c |2 +-
 mono/metadata/coree.c|7 ---
 mono/metadata/domain.c   |5 +
 mono/metadata/image.c|   26 +-
 mono/mini/driver.c   |   17 +++--
 5 files changed, 30 insertions(+), 27 deletions(-)

diff --git a/mono/metadata/assembly.c b/mono/metadata/assembly.c
index cc9e980..621e450 100644
--- a/mono/metadata/assembly.c
+++ b/mono/metadata/assembly.c
@@ -1634,7 +1634,7 @@ mono_assembly_load_from_full (MonoImage *image, const 
char*fname,
loaded_assemblies = g_list_prepend (loaded_assemblies, ass);
mono_assemblies_unlock ();
 
-#ifdef ENABLE_COREE
+#ifdef HOST_WIN32
if (image-is_module_handle)
mono_image_fixup_vtable (image);
 #endif
diff --git a/mono/metadata/coree.c b/mono/metadata/coree.c
index c31dfaf..9e48a3f 100644
--- a/mono/metadata/coree.c
+++ b/mono/metadata/coree.c
@@ -33,14 +33,10 @@
 #include environment.h
 #include coree.h
 
-#ifdef ENABLE_COREE
-
 HMODULE coree_module_handle = NULL;
 
 static gboolean init_from_coree = FALSE;
 
-#endif
-
 gchar*
 mono_get_module_file_name (HMODULE module_handle)
 {
@@ -73,7 +69,6 @@ mono_get_module_file_name (HMODULE module_handle)
return file_name_utf8;
 }
 
-#ifdef ENABLE_COREE
 /* Entry point called by LdrLoadDll of ntdll.dll after _CorValidateImage. */
 BOOL STDMETHODCALLTYPE _CorDllMain(HINSTANCE hInst, DWORD dwReason, LPVOID 
lpReserved)
 {
@@ -928,6 +923,4 @@ mono_fixup_exe_image (MonoImage* image)
MonoFixupExe ((HMODULE) image-raw_data);
 }
 
-#endif /* ENABLE_COREE */
-
 #endif /* HOST_WIN32 */
diff --git a/mono/metadata/domain.c b/mono/metadata/domain.c
index 8e001df..cbeef36 100644
--- a/mono/metadata/domain.c
+++ b/mono/metadata/domain.c
@@ -1271,9 +1271,6 @@ mono_init_internal (const char *filename, const char 
*exe_filename, const char *
 #ifdef HOST_WIN32
/* Avoid system error message boxes. */
SetErrorMode (SEM_FAILCRITICALERRORS | SEM_NOOPENFILEERRORBOX);
-#ifdef ENABLE_COREE
-   mono_load_coree (exe_filename);
-#endif
 #endif
 
mono_perfcounters_init ();
@@ -1312,7 +1309,7 @@ mono_init_internal (const char *filename, const char 
*exe_filename, const char *
 * exe_image, and close it during shutdown.
 */
get_runtimes_from_exe (exe_filename, exe_image, runtimes);
-#ifdef ENABLE_COREE
+#ifdef HOST_WIN32
if (!exe_image) {
exe_image = mono_assembly_open_from_bundle 
(exe_filename, NULL, FALSE);
if (!exe_image)
diff --git a/mono/metadata/image.c b/mono/metadata/image.c
index 5d098a0..ef904da 100644
--- a/mono/metadata/image.c
+++ b/mono/metadata/image.c
@@ -121,7 +121,7 @@ mono_cli_rva_image_map (MonoImage *image, guint32 addr)
for (i = 0; i  top; i++){
if ((addr = tables-st_virtual_address) 
(addr  tables-st_virtual_address + 
tables-st_raw_data_size)){
-#ifdef ENABLE_COREE
+#ifdef HOST_WIN32
if (image-is_module_handle)
return addr;
 #endif
@@ -158,7 +158,7 @@ mono_image_rva_map (MonoImage *image, guint32 addr)
if (!mono_image_ensure_section_idx (image, i))
return NULL;
}
-#ifdef ENABLE_COREE
+#ifdef HOST_WIN32
if (image-is_module_handle)
return image-raw_data + addr;
 #endif
@@ -239,7 +239,7 @@ mono_image_ensure_section_idx (MonoImage *image, int 
section)
 
if (sect-st_raw_data_ptr + sect-st_raw_data_size  
image-raw_data_len)
return FALSE;
-#ifdef ENABLE_COREE
+#ifdef HOST_WIN32
if (image-is_module_handle)
iinfo-cli_sections [section] = image-raw_data + 
sect

Re: [Mono-dev] mixed-mode assemblies in wine

2011-03-01 Thread Vincent Povirk 
2011/3/1 Kornél Pál kornel...@gmail.com:
 Another possible approach, if we don't share mscoree.dll code, would
 be for Wine and Mono to both implement ICLRMetaHost
 (http://msdn.microsoft.com/en-us/library/dd233134.aspx) and
 ICLRRuntimeInfo, both of which can be accessed before a runtime is
 chosen and loaded, and for only Mono to implement ICLRRuntimeHost,
 which requires a loaded runtime. Wine's mscoree.dll's other functions
 (except for the _Cor functions which will have to be special) could
 then work based on those interfaces.

 This could work but if we keep the embedding API implementation MIT
 licensed, then any other project can reuse it and customize to its needs if
 needed.

Yes, I assume adding code to the Mono runtime implies an MIT license.

Let's see if we can flesh out this approach more fully.

This would mean that both Wine and Mono would implement the
CLRCreateInstance function:
http://msdn.microsoft.com/en-us/library/dd537633.aspx

Mono's CLRCreateInstance function would be part of the embedding API
(possibly with a different name), not Mono's mscoree, so that Wine can
access it directly.

Mono's mscoree would forward its CLRCreateInstance export to the
embedding API function.

All other exports in mscoree would be written based on
CLRCreateInstance and the IMetaHost interface (although Wine would use
its internal IMetaHost interface and Mono's mscoree would presumably
use one from the embedding api), except for the _Cor functions. Wine
would search for Mono installs and their runtimes the same way it does
now.

The methods GetInterface and GetProcAddress on Wine's ICLRRuntimeInfo
(http://msdn.microsoft.com/en-us/library/dd233121.aspx) would load the
appropriate libmono dll and then forward to its ICLRRuntimeInfo
implementation. LoadLibrary would forward only if Wine is unable to
handle the call itself. IsLoaded and IsStarted would forward only if
the appropriate libmono.dll is already loaded.

You should probably think about how you want LoadLibrary
(LoadLibraryShim) to work. AFAIK it's only generally used to load
fusion.dll. Wine already has an implementation of fusion.dll. You may
be able to use the native fusion.dll without any changes, or you may
want to have your own for some reason.

I think _CorValidateImage should always be implemented in mscoree.dll,
as it shouldn't require a runtime, and it is too early to select one.

As for _CorExeMain, _CorExeMain2, and _CorDllMain, those require a
runtime selection. I'm not sure how this selection should work. We
probably want the runtime version to be calculated by mscoree, and
when we forward those calls to Mono, we'll want to specify a runtime.
However, we probably want to make sure we use the same runtime version
for each call to one of these functions. Maybe we should select a
runtime on the first call to one of these functions, then use that
same selection on subsequent calls?

I'm inclined to forward _CorImageUnloading to the mono runtime if one
is loaded, even though you don't seem to use it at the moment.

It's not obvious to me how ClrCreateManagedInstance is supposed to map
to the .NET 4 interfaces (even though MSDN implies it can), and so I
currently use internal methods of Wine's ICLRRuntimeHost objects for
this. It really boils down to a call to the class's constructor with
no arguments, followed by a call to
System.Runtime.InteropServices.GetIUnknownForObject, but I can't
figure out how to do either of those things in the new API.

Both mscoree.dll's will need a way to notify the runtime that they
want libraries to be loaded with LoadLibrary instead of mapped
read-only in memory. Since this implies a promise to forward _Cor*Main
calls to the runtime, it may not be as difficult as I originally
thought.

Wine's mscoree currently uses an assembly preload hook to search the
Windows GAC for assemblies. You'll probably want to do that, but I
guess a preload hook is inappropriate on Windows because you'd end up
loading standard libraries from .NET. I'd really prefer to have Mono
doing this search (so it can ensure the proper order, and because its
GAC-searching code is probably better than ours), but my bug for this
was closed either INVALID or WONTFIX.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] mixed-mode assemblies in wine

2011-02-28 Thread Vincent Povirk 
Two very interesting things happened in Mono recently:

1. The implement type compare for 1b assert failure that would
usually occur when loading a mixed-mode assembly in Mono was fixed. So
whoever did that, thank you.
2. Rodrigo Kumpera added an ENABLE_COREE define, default off, because
that code was breaking the verifier. He tells me I can test this by
running a hello world program using --security=verifiable.

These two changes had the combined effect of getting me to think about
mixed-mode assemblies and forcing me to notice all of Mono's coree
code and how it works.

Apparently the native code in a mixed-mode assembly works like a
p/invoke, except that the invoked function is inside the assembly
instead of a library export. Before we can call that code, we need the
assembly to be loaded using the OS loader, so it's linked properly.
But because all assemblies link to mscoree.dll and execute _CorExeMain
or _CorDllMain (and the OS does that itself in recent Windows
versions), that would load MS .NET. So Mono loads mscoree.dll itself
on Windows before it loads any assemblies, and hooks the mscoree
functions so they go to implementations in libmono.

This makes sense on Windows, but it's no good on Wine, where
mscoree.dll loads Mono. I can't work sanely on the unmanaged API in
Wine if it's going to be bypassed by Mono half of the time.

But we still need Mono to load the assemblies using the OS loader so
it can invoke native methods.

So I would like to propose that both mixed-mode behaviors (using the
OS loader and hooking mscoree) be default off but optionally activated
by embedding API calls (which Wine would call), or switches (which
mono_main would translate into the appropriate embedding calls). That
is, we would have a function that, if called very early on, would load
mscoree.dll and do the hooking, and set a flag so that Mono tries to
load assemblies using the OS loader. We would have another,
independent function that only sets that flag, which Wine would use.
(I think we'll also need access to something like
mono_image_open_from_module_handle, so we can give Mono the handle to
an already-loaded exe file in _CorExeMain.)

Does this seem doable?

Once that's done, I'd like to get Wine's mscoree.dll to a point where
it's on par with Mono's mixed-mode assembly support. What is that
support currently used for, and what are you using to test it? AFAICT
an ordinary assembly written in managed c++ and compiled with VS will
always fail to load in Mono.

Do you have any sense of what's required to make assemblies linking
msvcrt (my eventual goal) work? I have so far been unable to create a
build of Mono that can call native functions without hooking mscoree,
so I can't really tell what's going on. There was speculation in a
Wine bug that _CorDllMain needs to call some entry points in
assemblies, named PostDllMain and PostRawDllMain, but given that they
were actually fields containing.. some number.. maybe it was an RVA?..
I wasn't sure what to do with that.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] mixed-mode assemblies in wine

2011-02-28 Thread Vincent Povirk 
 My preferred way would be to call exports that Windows calls:
 - _CorValidateImage on image load
 - _CorImageUnloading on image unload
 - _CorExeMain instead of exe entry point
 - _CorDllMain instaad of dll entry

Is there a reason for us to add this to the Wine loader soon? I've
been putting it off because I have to ask for someone else to do it.

 - the C runtime (not the OS) should also call CorExitProcess on normal
 termination (exit)

Yes, I added this to Wine's msvcrt last week so we can tear things
down properly. Although right now that doesn't work because of the
hooks. :)

 I also planned to get rid of MonoFixupExe  and drop support for mixed-mode
 assemblies by using mono.exe and introduce a loader that would call
 CreateProcess on the managed (may be mixed-mode) .exe, inject a loader .dll
 (or a custom mscoree.dll) by modifying IAT, remove IL-only flag so that the
 OS loader will not load MS.NET mscorlib.dll, and do inicialization in that
 loader .dll called by OS loader. This would not affect functionality of
 mono.dll just would not fixup mscoree.dll by default that also would play
 more nicely with standalone verifier, dumper, etc. tools and CoreCLR.

That's interesting.

It would seem (to me) that in this case your mscoree.dll and ours can
and should be the same one. The only difference is how libmono is
found and loaded.

 I also have the impression that implementing .NET Framework functionality in
 Wine may not be the right architecture. Ideally those belong to Mono. Since
 I know that Mono does not accept GPL to runtime (requires MIT X11 license or
 special permissions to Novell; althoug is licensed under GPL) and Wine
 prefers GPL this may not be suitable.

 Wine loader should call mscoree.dll just like Windows loader does
 (system32\mscoree.dll is hardcoded, cannot use your own).

 If you prefer to keep mscoree.dll code in Wine, then I belive that Wine
 mscoree.dll should load mono.dll (as it already does) and forward the above
 five basic exports to mono.dll and implement other exports on its own by
 calling native Mono API.

My only strong reason for wanting mscoree.dll to be in Wine is so that
it can load without any Mono present (which is enough to install many
apps, and pass tests), and so that it can select between multiple
available Mono setups at runtime (in order to cover .NET versions 1.1,
2.0, and 4.0 simultaneously). For that to work, we need a dll that
loads Mono dynamically rather than linking to it, and it needs to
support both embedding ABI's.

Licensing is not an issue. Wine is LGPL, and we can use MIT code. The
reverse isn't true, but I think it would be possible to relicense most
of Wine's current mscoree code as MIT, since most of that architecture
was written by me for CodeWeavers.

Still, if you want to work on the .NET embedding API, I think we
should find a way to collaborate, in whichever project.

Another possible approach, if we don't share mscoree.dll code, would
be for Wine and Mono to both implement ICLRMetaHost
(http://msdn.microsoft.com/en-us/library/dd233134.aspx) and
ICLRRuntimeInfo, both of which can be accessed before a runtime is
chosen and loaded, and for only Mono to implement ICLRRuntimeHost,
which requires a loaded runtime. Wine's mscoree.dll's other functions
(except for the _Cor functions which will have to be special) could
then work based on those interfaces.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] [PATCH] add missing case to conv_to_icall

2010-11-11 Thread Vincent Povirk 
This is needed for ref or out string arguments marshaled as LPTStr.
diff --git a/mono/metadata/marshal.c b/mono/metadata/marshal.c
index afec4e5..8d50889 100644
--- a/mono/metadata/marshal.c
+++ b/mono/metadata/marshal.c
@@ -1410,6 +1410,12 @@ conv_to_icall (MonoMarshalConv conv)
 	switch (conv) {
 	case MONO_MARSHAL_CONV_STR_LPWSTR:
 		return mono_marshal_string_to_utf16;		
+	case MONO_MARSHAL_CONV_LPTSTR_STR:
+#ifdef TARGET_WIN32
+		return mono_string_from_utf16;
+#else
+		return mono_string_new_wrapper;
+#endif
 	case MONO_MARSHAL_CONV_LPWSTR_STR:
 		return mono_string_from_utf16;
 	case MONO_MARSHAL_CONV_LPSTR_STR:
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] [PATCH] implement type comparison for MONO_TYPE_FNPTR

2010-09-24 Thread Vincent Povirk 
This patch copies the type comparison logic for FNPTR from metadata.c
to reflection.c, so that the recursive type comparisons have different
semantics.

I am in way over my head here, but it seems to work in that my test
program takes ever so slightly longer to crash.
diff --git a/mono/metadata/reflection.c b/mono/metadata/reflection.c
index 3ba44ea..1ae45c6 100644
--- a/mono/metadata/reflection.c
+++ b/mono/metadata/reflection.c
@@ -6148,6 +6148,34 @@ mymono_metadata_type_equal (MonoType *t1, MonoType *t2)
 	case MONO_TYPE_VAR:
 	case MONO_TYPE_MVAR:
 		return t1-data.generic_param == t2-data.generic_param;
+	case MONO_TYPE_FNPTR: {
+		gpointer iter1 = 0, iter2 = 0;
+		if (t1-data.method == t2-data.method)
+			return TRUE;
+		if (t1-data.method-call_convention != t2-data.method-call_convention)
+			return FALSE;
+		if (t1-data.method-sentinelpos != t2-data.method-sentinelpos)
+			return FALSE;
+		if (t1-data.method-hasthis != t2-data.method-hasthis)
+			return FALSE;
+		if (t1-data.method-explicit_this != t2-data.method-explicit_this)
+			return FALSE;
+		if (! mymono_metadata_type_equal (t1-data.method-ret, t2-data.method-ret))
+			return FALSE;
+		if (t1-data.method-param_count != t2-data.method-param_count)
+			return FALSE;
+
+		while (TRUE) {
+			MonoType *p1 = mono_signature_get_params (t1-data.method, iter1);
+			MonoType *p2 = mono_signature_get_params (t1-data.method, iter2);
+
+			if (p1 == NULL || p2 == NULL)
+return (p1 == p2);
+			if (! mymono_metadata_type_equal (p1, p2))
+return FALSE;
+		}
+		return TRUE;
+	}
 	default:
 		g_error (implement type compare for %0x!, t1-type);
 		return FALSE;
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] [PATCH] implement type comparison for MONO_TYPE_FNPTR

2010-09-24 Thread Vincent Povirk 
E there shouldn't have been a return TRUE at the end of that
case. The while loop confused me by being clever and only exiting via
returns.

On Fri, Sep 24, 2010 at 6:55 PM, Vincent Povirk madewokh...@gmail.com wrote:
 This patch copies the type comparison logic for FNPTR from metadata.c
 to reflection.c, so that the recursive type comparisons have different
 semantics.

 I am in way over my head here, but it seems to work in that my test
 program takes ever so slightly longer to crash.

diff --git a/mono/metadata/reflection.c b/mono/metadata/reflection.c
index 3ba44ea..0be8a6c 100644
--- a/mono/metadata/reflection.c
+++ b/mono/metadata/reflection.c
@@ -6148,6 +6148,33 @@ mymono_metadata_type_equal (MonoType *t1, MonoType *t2)
 	case MONO_TYPE_VAR:
 	case MONO_TYPE_MVAR:
 		return t1-data.generic_param == t2-data.generic_param;
+	case MONO_TYPE_FNPTR: {
+		gpointer iter1 = 0, iter2 = 0;
+		if (t1-data.method == t2-data.method)
+			return TRUE;
+		if (t1-data.method-call_convention != t2-data.method-call_convention)
+			return FALSE;
+		if (t1-data.method-sentinelpos != t2-data.method-sentinelpos)
+			return FALSE;
+		if (t1-data.method-hasthis != t2-data.method-hasthis)
+			return FALSE;
+		if (t1-data.method-explicit_this != t2-data.method-explicit_this)
+			return FALSE;
+		if (! mymono_metadata_type_equal (t1-data.method-ret, t2-data.method-ret))
+			return FALSE;
+		if (t1-data.method-param_count != t2-data.method-param_count)
+			return FALSE;
+
+		while (TRUE) {
+			MonoType *p1 = mono_signature_get_params (t1-data.method, iter1);
+			MonoType *p2 = mono_signature_get_params (t1-data.method, iter2);
+
+			if (p1 == NULL || p2 == NULL)
+return (p1 == p2);
+			if (! mymono_metadata_type_equal (p1, p2))
+return FALSE;
+		}
+	}
 	default:
 		g_error (implement type compare for %0x!, t1-type);
 		return FALSE;
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] AssemblyInstaller

2010-09-20 Thread Vincent Povirk 
I suspect that the Installer class is responsible for chaining the
Install, Uninstall, and Commit calls to children. If so,
AssemblyInstaller just needs to add all the runnable installers to
itself and let Installer do the work of making sure they're invoked.

This needs a test case.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] AssemblyInstaller

2010-09-18 Thread Vincent Povirk 
I believe Kornél's explanation is correct. I've seen some Windows
installers instantiate ManagedInstallerClass using the .NET embedding
API and use IManagedInstaller as a COM server to start an install.
Wine implements that API based on Mono, and I'm hoping to see
ManagedInstallerClass implemented so these installers can start
working.

It appears that Mono's COM interop code translates exceptions to
HRESULT returns, so Mono currently provides an IManagedInstaller
object whose ManagedInsall method just returns E_NOTIMPL.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] AssemblyInstaller

2010-09-17 Thread Vincent Povirk 
I don't know much about these classes, but my impression was that
ManagedInstallerClass corresponds most directly to installutil.exe,
but that that class must use AssemblyInstaller. It seems installutil
duplicates some functionality of both of those, and it should probably
call on them instead.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] changing the location of mono's global assembly cache

2010-09-12 Thread Vincent Povirk 
I'm working on a bug that occurs when Mono is used with Wine's
mscoree.dll to replace .NET in Wine,
http://bugs.winehq.org/show_bug.cgi?id=24172

A Windows program fails trying to load some assemblies that it
installed in c:\windows\assembly\GAC_MSIL. Mono only searches
c:\Program Files\Mono-2.6.7\lib\mono\gac.

It appears to be impossible for me to direct Mono to the GAC_MSIL
folder using the embedding API. I can only change the location of lib,
and Mono will look for the global assembly cache in lib/mono.

I prefer to avoid using symlinks for this. While they are available on
Windows, I don't think Wine supports them properly, and it's a clunky
solution anyway.

Is there any way I can solve this problem with the currently-released
Mono 2.6.7 for Windows?

Failing that, can the embedding API be extended for this?

Failing that, where is the code I need to hack to change this?

Vincent Povirk
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] changing the location of mono's global assembly cache

2010-09-12 Thread Vincent Povirk 
Michael Hutchinson on IRC suggested that I grep the source for
MONO_GAC_PREFIX, and, based on that, add a function to the embedding
API that adds a single fallback path (without appending lib/mono/gac
to it). That seems reasonable to me.

Is this approach likely to be acceptable for Mono?
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Mono integration, and when do we ship Mono with Wine?

2010-09-01 Thread Vincent Povirk 
Dan Kegel recently listed this as a possible 1.4 goal:

 Mono integration similar to the current Gecko integration

He may have meant one or both of the following things:
1. A more-or-less complete mscoree.dll that works based on the mono
embedding api, as well as replacements for all the utilities that ship
with .NET.
2. A wine-mono package similar to the current wine-gecko package to be
installed automatically in new prefixes.

I am making very slow progress with 1. I believe the current major
shortcomings are functions that create COM wrappers for managed
objects (ClrCreateManagedInstance and DllGetClassObject) and functions
that search for and load different .NET versions (I believe these will
be needed so that the managed objects we create will load and function
properly). Mono already provides COM wrappers, so all we have to do is
create the objects and pass COM wrappers to applications.

I'm making this judgment based on the limited pool of mscoree bugs in
the Wine bugzilla. I wish more people would file bugs when Mono
doesn't work.

I figure 2 can't be very technically difficult in and of itself, but
when will we be ready to do that? What are the requirements? Do we
want to go the offer to download and install on first use route
first, and if so when will we be ready for that?

Do those functions I mentioned earlier have to actually work first?

The one hard requirement I have and have not met is that a working
mono package can be built by me using only free software and that I
can explain the build process to other people. I can do this for the
core runtime and libraries, but I cannot do this for the gluezilla
dependency.

This gluezilla thing is sort of explained here:
http://www.mono-project.com/WebBrowser

Basically, .NET provides a web browser control, which Mono implements
based on Gecko (or, optionally, WebKit). The official installer of
Mono for Windows, which is what anyone who uses Mono in Wine uses,
ships with Mozilla. It also ships with gluezilla, which is a C++
library that helps the managed code link Gecko.

I don't think it'd be acceptable to leave out WebBrowser support.

I am not currently able to create a Windows build of gluezilla or
gecko using only free software. As I understand it, the official
Windows build relies on Visual Studio. I do not know whether it's
feasible for gluezilla to link to wine gecko, so that we don't have to
install two versions of gecko.

I also know that shipping gluezilla and gecko on Windows is wrong.
Mono's wiki tells me that it's possible in .NET to access the
underlying IE embedding objects through the winforms api, and those
only exist if we're embedding IE. So the correct approach is to embed
IE (in this case, Wine's IE replacement) by writing another WebBrowser
backend. I don't know how hard that is. Maybe it'd make a good Summer
of Code project?

So, does anyone have other requirements, or thoughts on resolving the
WebBrowser requirement?
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] [Mono-patches] [mono/mono] b9d711fa: Add a null check to LDFLDA, the spec requires it.

2010-08-14 Thread Vincent Povirk 
I think this patch broke the mono 2.6 build. It seems 2.6 lacks
MONO_EMIT_NULL_CHECK.

Last lines of failure:

libtool: link: i586-mingw32msvc-g++ -shared -nostdlib
/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/lib/dllcrt2.o
/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/crtbegin.o  .libs/mini.o
.libs/method-to-ir.o .libs/decompose.o .libs/jit-icalls.o
.libs/trace.o .libs/dominators.o .libs/cfold.o .libs/regalloc.o
.libs/helpers.o .libs/liveness.o .libs/ssa.o .libs/abcremoval.o
.libs/ssapre.o .libs/local-propagation.o .libs/driver.o
.libs/debug-mini.o .libs/linear-scan.o .libs/aot-compiler.o
.libs/aot-runtime.o .libs/graph.o .libs/mini-codegen.o
.libs/mini-exceptions.o .libs/mini-trampolines.o .libs/declsec.o
.libs/wapihandles.o .libs/branch-opts.o .libs/mini-generic-sharing.o
.libs/regalloc2.o .libs/tasklets.o .libs/simd-intrinsics.o
.libs/unwind.o .libs/image-writer.o .libs/dwarfwriter.o
.libs/mini-gc.o .libs/debugger-agent.o .libs/mini-x86.o
.libs/exceptions-x86.o .libs/tramp-x86.o .libs/mini-windows.o
-Wl,--whole-archive ../../mono/metadata/.libs/libmonoruntime.a
../../mono/io-layer/.libs/libwapi.a
../../mono/utils/.libs/libmonoutils.a ../../libgc/.libs/libmonogc.a
-Wl,--no-whole-archive  -ladvapi32 -ladvapi32 -lmswsock -ladvapi32
-L/usr/i586-mingw32msvc/lib -lgthread-2.0 -lglib-2.0 -lintl -lws2_32
-lpsapi -lole32 -lwinmm -loleaut32 -ladvapi32 -lversion
-L/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj
-L/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/lib
-lstdc++ -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32
-lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex
-lmsvcrt /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/crtend.o
-mms-bitfields -Wl,--kill-at
-Wl,-version-script=../../../mono/mini/ldscript   -o .libs/libmono.dll
-Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker
.libs/libmono.dll.a
Creating library file: .libs/libmono.dll.a
.libs/method-to-ir.o: In function `mono_method_to_ir':
/home/meh/work/mono26/build-cross-windows/mono/mini/../../../mono/mini/method-to-ir.c:8304:
undefined reference to `_MONO_EMIT_NULL_CHECK'
collect2: ld returned 1 exit status
make[4]: *** [libmono.la] Error 1
make[4]: Leaving directory `/home/meh/work/mono26/build-cross-windows/mono/mini'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/meh/work/mono26/build-cross-windows/mono/mini'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/meh/work/mono26/build-cross-windows/mono'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/meh/work/mono26/build-cross-windows'
make: *** [all] Error 2
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Can libgdiplus be used in wine or windows?

2010-07-13 Thread Vincent Povirk 
If there's a problem with Wine's gdiplus, it should be fixed in Wine.

I would be very surprised if cairo on Windows uses gdiplus. All the
evidence I've seen shows that gdiplus on Windows does everything in
software, and cairo's software rendering is probably better.

 3. As both wine and mono implements he same C Flat API as the GDIPLUS.DLL.
 Can we use mono's libgdiplus tho replace wine's?

 Maybe, I don't know enough about wine to tell you how exhaustive the
 change would need to be.

The best way would be to build a gdiplus.dll that works on Windows. It
could then be used in Wine as well.

To build it as a winelib dll (using the native cairo instead of a
Windows build of cairo), you'd need to use some special commands to
get things like X drawables from gdi32 handles, and you'd have to
provide a software fallback in case X drawables don't exist. That
said, bypassing the Windows API layers and accessing X resources
directly may break some things.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Can libgdiplus be used in wine or windows?

2010-07-13 Thread Vincent Povirk 
 Mono's Windows Forms implementation makes heavy use of GdiPlus, and Wine's
 builtin gdiplus.dll is not very good. (under Known Issues on
 http://wiki.winehq.org/Mono)

I stand by that statement. You are likely to encounter problems.

Still, I believe your effort would be better directed toward getting
these bugs documented and fixed than the (judging by the other
responses in this thread) non-trivial task of building a windows or
winelib libgdiplus.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] [PATCH] Implement System.Net.WebClient.set_CachePolicy.

2010-07-06 Thread Vincent Povirk 
The value is currently ignored, but that is a problem for WebRequest.

For wine bug 23458.
diff --git a/class/System/System.Net/WebClient.cs 
b/class/System/System.Net/WebClient.cs
index 8ada916..de62c50 100644
--- a/class/System/System.Net/WebClient.cs
+++ b/class/System/System.Net/WebClient.cs
@@ -139,6 +139,8 @@ namespace System.Net
return new NotImplementedException ();
}

+   private RequestCachePolicy cachePolicy;
+   
[MonoTODO]
public RequestCachePolicy CachePolicy
{
@@ -146,7 +148,7 @@ namespace System.Net
throw GetMustImplement ();
}
set {
-   throw GetMustImplement ();
+   cachePolicy = value;
}
}
 
@@ -942,6 +944,8 @@ namespace System.Net
 #if NET_2_0
if (Proxy != null)
request.Proxy = Proxy;
+   if (cachePolicy != null)
+   request.CachePolicy = cachePolicy;
 #endif
request.Credentials = credentials;
 
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] [PATCH] Read timezones from the registry on Windows. (try 2)

2010-06-18 Thread Vincent Povirk 
This patch makes TimeZoneInfo.GetSystemTimeZones and
FindSystemTimeZoneById work based on the registry on non-Unix
platforms, if the appropriate registry key exists. Mono currently
reads from /usr/share/zoneinfo, which doesn't exist on Windows.

This should fix bug 606084.

It won't fix the Local property on Windows. I think that requires a
Windows API call to get the id of the local timezone.

This was modified from the previous version to not check the registry
on Unix platforms. (Sorry it took me so long to do this. I have very
little time to spend on Mono-related work.)

This patch is licensed under the MIT X11 license.
From f596ee87eae00cae83cc7d4ced6c0a6b83d8c337 Mon Sep 17 00:00:00 2001
From: Vincent Povirk madewokh...@gmail.com
Date: Fri, 18 Jun 2010 14:09:50 -0500
Subject: [PATCH] Read timezones from the registry on Windows.

---
 class/System.Core/System/TimeZoneInfo.cs |  170 +++---
 1 files changed, 155 insertions(+), 15 deletions(-)

diff --git a/class/System.Core/System/TimeZoneInfo.cs b/class/System.Core/System/TimeZoneInfo.cs
index d5e77e8..0f5889e 100644
--- a/class/System.Core/System/TimeZoneInfo.cs
+++ b/class/System.Core/System/TimeZoneInfo.cs
@@ -43,6 +43,8 @@ using System.IO;
 using Mono;
 #endif
 
+using Microsoft.Win32;
+
 namespace System
 {
 #if NET_4_0 || BOOTSRAP_NET_4_0
@@ -131,6 +133,23 @@ namespace System
 #endif
 		private AdjustmentRule [] adjustmentRules;
 
+		static RegistryKey timeZoneKey = null;
+		static bool timeZoneKeySet = false;
+		static RegistryKey TimeZoneKey {
+			get {
+if (!timeZoneKeySet) {
+	int p = (int) Environment.OSVersion.Platform;
+	/* Only use the registry on non-Unix platforms. */
+	if ((p != 4)  (p != 6)  (p != 128))
+		timeZoneKey = Registry.LocalMachine.OpenSubKey (
+			SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Time Zones,
+			false);
+	timeZoneKeySet = true;
+}
+return timeZoneKey;
+			}
+		}
+
 		public static void ClearCachedData ()
 		{
 			local = null;
@@ -288,6 +307,13 @@ namespace System
 			//FIXME: this method should check for cached values in systemTimeZones
 			if (id == null)
 throw new ArgumentNullException (id);
+			if (TimeZoneKey != null)
+			{
+RegistryKey key = TimeZoneKey.OpenSubKey (id, false);
+if (key == null)
+	throw new TimeZoneNotFoundException ();
+return FromRegistryKey(id, key);
+			}
 #if LIBC	
 			string filepath = Path.Combine (TimeZoneDirectory, id);
 			return FindSystemTimeZoneByFileName (id, filepath);
@@ -320,6 +346,110 @@ namespace System
 		}
 #endif
 
+		private static TimeZoneInfo FromRegistryKey (string id, RegistryKey key)
+		{
+			byte [] reg_tzi = (byte []) key.GetValue (TZI);
+
+			if (reg_tzi == null)
+throw new InvalidTimeZoneException ();
+
+			int bias = BitConverter.ToInt32 (reg_tzi, 0);
+			TimeSpan baseUtcOffset = new TimeSpan (0, -bias, 0);
+
+			string display_name = (string) key.GetValue (Display);
+			string standard_name = (string) key.GetValue (Std);
+			string daylight_name = (string) key.GetValue (Dlt);
+
+			ListAdjustmentRule adjustmentRules = new ListAdjustmentRule ();
+
+			RegistryKey dst_key = key.OpenSubKey (Dynamic DST, false);
+			if (dst_key != null) {
+int first_year = (int) dst_key.GetValue (FirstEntry);
+int last_year = (int) dst_key.GetValue (LastEntry);
+int year;
+
+for (year=first_year; year=last_year; year++) {
+	byte [] dst_tzi = (byte []) dst_key.GetValue (year.ToString ());
+	if (dst_tzi != null) {
+		int start_year = year == first_year ? 1 : year;
+		int end_year = year == last_year ?  : year;
+		ParseRegTzi(adjustmentRules, start_year, end_year, dst_tzi);
+	}
+}
+			}
+			else
+ParseRegTzi(adjustmentRules, 1, , reg_tzi);
+
+			return CreateCustomTimeZone (id, baseUtcOffset, display_name, standard_name, daylight_name, ValidateRules (adjustmentRules).ToArray ());
+		}
+
+		private static void ParseRegTzi (ListAdjustmentRule adjustmentRules, int start_year, int end_year, byte [] buffer)
+		{
+			//int standard_bias = BitConverter.ToInt32 (buffer, 4); /* not sure how to handle this */
+			int daylight_bias = BitConverter.ToInt32 (buffer, 8);
+
+			int standard_year = BitConverter.ToInt16 (buffer, 12);
+			int standard_month = BitConverter.ToInt16 (buffer, 14);
+			int standard_dayofweek = BitConverter.ToInt16 (buffer, 16);
+			int standard_day = BitConverter.ToInt16 (buffer, 18);
+			int standard_hour = BitConverter.ToInt16 (buffer, 20);
+			int standard_minute = BitConverter.ToInt16 (buffer, 22);
+			int standard_second = BitConverter.ToInt16 (buffer, 24);
+			int standard_millisecond = BitConverter.ToInt16 (buffer, 26);
+
+			int daylight_year = BitConverter.ToInt16 (buffer, 28);
+			int daylight_month = BitConverter.ToInt16 (buffer, 30);
+			int daylight_dayofweek = BitConverter.ToInt16 (buffer, 32);
+			int daylight_day = BitConverter.ToInt16 (buffer, 34);
+			int daylight_hour = BitConverter.ToInt16 (buffer, 36

[Mono-dev] [PATCH] Read timezones from the registry on Windows.

2010-05-16 Thread Vincent Povirk 
This patch makes TimeZoneInfo.GetSystemTimeZones and
FindSystemTimeZoneById work based on the registry on Windows. Mono
currently reads from /usr/share/zoneinfo, which doesn't exist on
Windows.

This should fix bug 606084.

The code doesn't check whether it's running on (or compiled for)
Windows, just whether the appropriate registry key exists. I don't
know if that's the preferred way of doing things.

It won't fix the Local property on Windows. I think that requires a
Windows API call to get the id of the local timezone.

This patch is licensed under the MIT X11 license.
From 30176f2bab58310fa52b71fef94a4d7daeaeb992 Mon Sep 17 00:00:00 2001
From: Vincent Povirk madewokh...@gmail.com
Date: Sun, 16 May 2010 16:43:08 -0500
Subject: [PATCH] Read timezones from the registry on Windows.

---
 class/System.Core/System/TimeZoneInfo.cs |  167 +++---
 1 files changed, 152 insertions(+), 15 deletions(-)

diff --git a/class/System.Core/System/TimeZoneInfo.cs b/class/System.Core/System/TimeZoneInfo.cs
index d5e77e8..2902c3a 100644
--- a/class/System.Core/System/TimeZoneInfo.cs
+++ b/class/System.Core/System/TimeZoneInfo.cs
@@ -43,6 +43,8 @@ using System.IO;
 using Mono;
 #endif
 
+using Microsoft.Win32;
+
 namespace System
 {
 #if NET_4_0 || BOOTSRAP_NET_4_0
@@ -131,6 +133,20 @@ namespace System
 #endif
 		private AdjustmentRule [] adjustmentRules;
 
+		static RegistryKey timeZoneKey = null;
+		static bool timeZoneKeySet = false;
+		static RegistryKey TimeZoneKey {
+			get {
+if (!timeZoneKeySet) {
+	timeZoneKey = Registry.LocalMachine.OpenSubKey (
+		SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Time Zones,
+		false);
+	timeZoneKeySet = true;
+}
+return timeZoneKey;
+			}
+		}
+
 		public static void ClearCachedData ()
 		{
 			local = null;
@@ -288,6 +304,13 @@ namespace System
 			//FIXME: this method should check for cached values in systemTimeZones
 			if (id == null)
 throw new ArgumentNullException (id);
+			if (TimeZoneKey != null)
+			{
+RegistryKey key = TimeZoneKey.OpenSubKey (id, false);
+if (key == null)
+	throw new TimeZoneNotFoundException ();
+return FromRegistryKey(id, key);
+			}
 #if LIBC	
 			string filepath = Path.Combine (TimeZoneDirectory, id);
 			return FindSystemTimeZoneByFileName (id, filepath);
@@ -320,6 +343,110 @@ namespace System
 		}
 #endif
 
+		private static TimeZoneInfo FromRegistryKey (string id, RegistryKey key)
+		{
+			byte [] reg_tzi = (byte []) key.GetValue (TZI);
+
+			if (reg_tzi == null)
+throw new InvalidTimeZoneException ();
+
+			int bias = BitConverter.ToInt32 (reg_tzi, 0);
+			TimeSpan baseUtcOffset = new TimeSpan (0, -bias, 0);
+
+			string display_name = (string) key.GetValue (Display);
+			string standard_name = (string) key.GetValue (Std);
+			string daylight_name = (string) key.GetValue (Dlt);
+
+			ListAdjustmentRule adjustmentRules = new ListAdjustmentRule ();
+
+			RegistryKey dst_key = key.OpenSubKey (Dynamic DST, false);
+			if (dst_key != null) {
+int first_year = (int) dst_key.GetValue (FirstEntry);
+int last_year = (int) dst_key.GetValue (LastEntry);
+int year;
+
+for (year=first_year; year=last_year; year++) {
+	byte [] dst_tzi = (byte []) dst_key.GetValue (year.ToString ());
+	if (dst_tzi != null) {
+		int start_year = year == first_year ? 1 : year;
+		int end_year = year == last_year ?  : year;
+		ParseRegTzi(adjustmentRules, start_year, end_year, dst_tzi);
+	}
+}
+			}
+			else
+ParseRegTzi(adjustmentRules, 1, , reg_tzi);
+
+			return CreateCustomTimeZone (id, baseUtcOffset, display_name, standard_name, daylight_name, ValidateRules (adjustmentRules).ToArray ());
+		}
+
+		private static void ParseRegTzi (ListAdjustmentRule adjustmentRules, int start_year, int end_year, byte [] buffer)
+		{
+			//int standard_bias = BitConverter.ToInt32 (buffer, 4); /* not sure how to handle this */
+			int daylight_bias = BitConverter.ToInt32 (buffer, 8);
+
+			int standard_year = BitConverter.ToInt16 (buffer, 12);
+			int standard_month = BitConverter.ToInt16 (buffer, 14);
+			int standard_dayofweek = BitConverter.ToInt16 (buffer, 16);
+			int standard_day = BitConverter.ToInt16 (buffer, 18);
+			int standard_hour = BitConverter.ToInt16 (buffer, 20);
+			int standard_minute = BitConverter.ToInt16 (buffer, 22);
+			int standard_second = BitConverter.ToInt16 (buffer, 24);
+			int standard_millisecond = BitConverter.ToInt16 (buffer, 26);
+
+			int daylight_year = BitConverter.ToInt16 (buffer, 28);
+			int daylight_month = BitConverter.ToInt16 (buffer, 30);
+			int daylight_dayofweek = BitConverter.ToInt16 (buffer, 32);
+			int daylight_day = BitConverter.ToInt16 (buffer, 34);
+			int daylight_hour = BitConverter.ToInt16 (buffer, 36);
+			int daylight_minute = BitConverter.ToInt16 (buffer, 38);
+			int daylight_second = BitConverter.ToInt16 (buffer, 40);
+			int daylight_millisecond = BitConverter.ToInt16 (buffer, 42

[Mono-dev] run-test-onwine target

2010-04-13 Thread Vincent Povirk 
It would be useful for Wine development if we had an easy way to run
the Mono testsuite on whichever CLI implementation happens to be set
up in Wine (Mono or MS .NET). To this end, I've made a small
proof-of-concept patch that adds a run-test-onwine target.

Note that I don't really understand most of this, and my approach was
to search for ondotnet, replace it with onwine and add wine to
the start of the command line. Also, any tests that would normally be
excluded on either Mono or .NET are excluded here, since we don't care
about Mono-specific features in Wine.

I haven't gotten this to run all the tests yet, but have I done
anything obviously wrong?
diff --git a/build/Makefile b/build/Makefile
index 69721f7..b55b039 100644
--- a/build/Makefile
+++ b/build/Makefile
@@ -4,7 +4,7 @@ include ../build/rules.make
 
 BUILT_FILES = common/Consts.cs
 
-all-local install-local test-local run-test-local csproj-local run-test-ondotnet-local uninstall-local doc-update-local: $(BUILT_FILES)
+all-local install-local test-local run-test-local csproj-local run-test-ondotnet-local run-test-onwine-local uninstall-local doc-update-local: $(BUILT_FILES)
 	@:
 
 clean-local:
diff --git a/build/executable.make b/build/executable.make
index 6030f5e..03405ec 100644
--- a/build/executable.make
+++ b/build/executable.make
@@ -72,6 +72,8 @@ run-test-local:
 	@:
 run-test-ondotnet-local:
 	@:
+run-test-onwine-local:
+	@:
 
 DISTFILES = $(sourcefile) $(base_prog_config) $(EXTRA_DISTFILES)
 
diff --git a/build/library.make b/build/library.make
index 7bf697e..58aa9df 100644
--- a/build/library.make
+++ b/build/library.make
@@ -166,7 +166,7 @@ endif # NO_INSTALL
 clean-local:
 	-rm -f $(tests_CLEAN_FILES) $(library_CLEAN_FILES) $(CLEAN_FILES)
 
-test-local run-test-local run-test-ondotnet-local:
+test-local run-test-local run-test-ondotnet-local run-test-onwine-local:
 	@:
 
 DISTFILES = $(wildcard *$(LIBRARY)*.sources) $(EXTRA_DISTFILES)
diff --git a/build/rules.make b/build/rules.make
index 08bdc22..81de3a5 100644
--- a/build/rules.make
+++ b/build/rules.make
@@ -122,7 +122,7 @@ gacutil = $(topdir)/class/lib/basic/gacutil.exe
 GACUTIL = MONO_PATH=$(topdir)/class/lib/basic$(PLATFORM_PATH_SEPARATOR)$$MONO_PATH $(RUNTIME) $(RUNTIME_FLAGS) $(gacutil)
 endif
 
-STD_TARGETS = test run-test run-test-ondotnet clean install uninstall doc-update
+STD_TARGETS = test run-test run-test-ondotnet run-test-onwine clean install uninstall doc-update
 
 $(STD_TARGETS): %: do-%
 
diff --git a/build/tests.make b/build/tests.make
index 98e1eb8..0d7066c 100644
--- a/build/tests.make
+++ b/build/tests.make
@@ -57,20 +57,26 @@ check: run-test
 test-local: $(test_assemblies)
 run-test-local: run-test-lib
 run-test-ondotnet-local: run-test-ondotnet-lib
+run-test-onwine-local: run-test-onwine-lib
 
 TEST_HARNESS_EXCLUDES = -exclude=$(PLATFORM_TEST_HARNESS_EXCLUDES)NotWorking,ValueAdd,CAS,InetAccess
 TEST_HARNESS_EXCLUDES_ONDOTNET = /exclude:$(PLATFORM_TEST_HARNESS_EXCLUDES)NotDotNet,CAS
+TEST_HARNESS_EXCLUDES_ONWINE = /exclude:$(PLATFORM_TEST_HARNESS_EXCLUDES)NotWorking,NotDotNet,ValueAdd,CAS,InetAccess
 
 ifdef TEST_HARNESS_VERBOSE
 TEST_HARNESS_OUTPUT = -labels
 TEST_HARNESS_OUTPUT_ONDOTNET = -labels
+TEST_HARNESS_OUTPUT_ONWINE = -labels
 TEST_HARNESS_POSTPROC = :
 TEST_HARNESS_POSTPROC_ONDOTNET = :
+TEST_HARNESS_POSTPROC_ONWINE = :
 else
 TEST_HARNESS_OUTPUT = -output=TestResult-$(PROFILE).log
 TEST_HARNESS_OUTPUT_ONDOTNET = -output=TestResult-ondotnet-$(PROFILE).log
+TEST_HARNESS_OUTPUT_ONWINE = -output=TestResult-onwine-$(PROFILE).log
 TEST_HARNESS_POSTPROC = (echo ''; cat TestResult-$(PROFILE).log) | sed '1,/^Tests run: /d'; xsltproc $(topdir)/build/nunit-summary.xsl TestResult-$(PROFILE).xml  TestResult-$(PROFILE).log
 TEST_HARNESS_POSTPROC_ONDOTNET = (echo ''; cat TestResult-ondotnet-$(PROFILE).log) | sed '1,/^Tests run: /d'; xsltproc $(topdir)/build/nunit-summary.xsl TestResult-ondotnet-$(PROFILE).xml  TestResult-ondotnet-$(PROFILE).log
+TEST_HARNESS_POSTPROC_ONWINE = (echo ''; cat TestResult-onwine-$(PROFILE).log) | sed '1,/^Tests run: /d'; xsltproc $(topdir)/build/nunit-summary.xsl TestResult-onwine-$(PROFILE).xml  TestResult-onwine-$(PROFILE).log
 endif
 
 ifdef FIXTURE
@@ -91,6 +97,11 @@ run-test-ondotnet-lib: test-local
 	ok=:; \
 	$(TEST_HARNESS) $(test_assemblies) -noshadow $(TEST_HARNESS_FLAGS) $(LOCAL_TEST_HARNESS_ONDOTNET_FLAGS) $(TEST_HARNESS_EXCLUDES_ONDOTNET) $(TEST_HARNESS_OUTPUT_ONDOTNET) -xml=TestResult-ondotnet-$(PROFILE).xml $(FIXTURE_ARG) $(TESTNAME_ARG) || ok=false; \
 	$(TEST_HARNESS_POSTPROC_ONDOTNET) ; $$ok
+
+run-test-onwine-lib: test-local
+	ok=:; \
+	wine $(TEST_HARNESS) $(test_assemblies) -noshadow $(TEST_HARNESS_FLAGS) $(LOCAL_TEST_HARNESS_ONWINE_FLAGS) $(TEST_HARNESS_EXCLUDES_ONWINE) $(TEST_HARNESS_OUTPUT_ONWINE) -xml=TestResult-onwine-$(PROFILE).xml $(FIXTURE_ARG) $(TESTNAME_ARG) || ok=false; \
+	$(TEST_HARNESS_POSTPROC_ONWINE) ; $$ok
 endif # test_assemblies
 
 TEST_FILES =