Re: [Mono-dev] mono crash on exits when using COM.
Tom,
I beleive that we had a problem with this before and I applied a fix.
http://anonsvn.mono-project.com/viewvc?view=revisionrevision=121114
IIRC this code/fix should release all outstanding rcws before the
final collect of other mono objects, including ccws.
Can you investigate if this change (121114) has been broken, or needs enhanced?
-bill
On Fri, Jan 22, 2010 at 8:26 PM, tom hindle tom_hin...@sil.org wrote:
I have added a check in mono_gc_run_finalize (void *obj, void *data)
(gc.c):
---
if (suspend_finalizers)
return;
+ if (mono_marshal_ccw_refcount(o) 0)
+ {
+ return;
+ }
domain = o-vtable-domain;
This seems to solve the problem. The ccw isn't freed, which means when
the rcw releases its reference to the ccw, so it no longer segv's.
Does this seem like an valid approach? I'm not sure If this means that
finalize_domain_objects needs to make multiple passes at freeing the
ccw's? I guess this change would also mean the badly written native COM
objects would prevent ccw from being freed. Is this a problem?
Thanks
Tom
On Fri, 2010-01-22 at 16:16 -0700, tom hindle wrote:
Hi all,
I have been investigating some seemingly random crash on exit problems
that our application has been having.
I have managed mostly reliably to reproduce the issue by following this
set of steps:
1. Create a managed object ManagedObj
2. Create a COM object COMObj for which its rcw is likely to be Garbage
collected after ManagedObj and during mono shutdown.
3. Make COMObj contain a ref to ManagedObj's ccw
4. Set ManagedObj ref to null
5. Call GC.Collect() to encourage GC.
If Garbage Collection of COMObj's rcw happens after the Garbage
Collection of ManagedObj's ccw, then when COMObj calls Release on its
ref to ManagedObj's ccw a segv is produced.
Normally it seems that ref counts for the wrappers are respected,
however this doesn't seem to be the case on program shutdown.
Some pseudo code which reproduces the problem:
public class TestComRelease
{
static COMObj cObj;
[Test]
public void Test()
{
ManagedObj mObj = new ManagedObj()
cObj = new COMObj();
cObj.SetManagedRef(mObj);
mObj = null;
GC.Collect();
}
}
I am attempting to find the cause of this in mono. Any pointers would be
grateful received.
Thanks
Tom
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] COM Interop - Support for [in] parameters of type SAFEARRAY[VARIANT]
Sylvain Committed to the trunk. r149817 Thanks -bill On Mon, Nov 9, 2009 at 7:17 AM, Sylvain Dupont dupo...@gmail.com wrote: Hi, The patch attached is a continuation of my previous patch committed in r136836. It adds support for [in] parameters of type SAFEARRAY[VARIANT], and also for other variations of in/out/byval/byref options. In addition to the tests included in the patch, I have also tested this against other COM components, both on Windows and Linux (using Mainwin and with the MONO_COM environment variable set to MS). Contributed under MIT/X11 license. Thanks, Sylvain ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Remoting with generics
Hi, The attached bug fixes calling a remoting method that has an arguments that is an out generic. There is also a test attached. 2009-10-05 Bill Holmes billholme...@gmail.com * object.c (mono_method_return_message_restore) : Adding the MONO_TYPE_GENERICINST case to handle generic arguments. * generic-remoting.cs : Added to test remotng with generic arguments. * Makefile.am : Adding generic-remoting. Code is contributed under MIT/X11 license. -bill generic-remoting.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Calling COM methods with delegates
Hi, The attached patch fixes a bug with calling a COM method using a delegate. I have also added a unit test for this bug. 2009-09-09 Bill Holmes billholme...@gmail.com * object.c (mono_object_get_virtual_method) : Call mono_cominterop_get_invoke if the object is a COM object. * mini-trampolines.c (mono_delegate_trampoline) : Call mono_cominterop_get_invoke if the delegate target object is a COM object. * cominterop.cs : Adding a test for invoking delegates that target COM methods. Code is contributed under MIT/X11 license. -bill invoke_com_delegate.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] ShellExecuteEx
Hi, The attached patch fixes Mono on Windows not respecting the WindowStyle property of the start info when calling Process.Start with UseShellExecute set to true. -bill 2009-07-10 Bill Holmes billholme...@gmail.com * process.c (ves_icall_System_Diagnostics_Process_ShellExecuteEx_internal) : Applying the window_style field to the SHELLEXECUTEINFO struct. Contributed under MIT/X11 license. ShellExecuteEx.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] CultureInfo_construct datetime_format and number_format fix for Windows.
Hi, I have updated this patch to correct a bug we found since it was originally posted. -bill On Tue, Jun 23, 2009 at 5:41 PM, Bill Holmesbillholme...@gmail.com wrote: Hi, On Windows users can customize the regional options for their language. To get this information you can call GetLocaleInfo to obtain each individual setting. The attached patch is a new implementation of ves_icall_System_Globalization_CultureInfo_construct_datetime_format and ves_icall_System_Globalization_CultureInfo_construct_number_format for Windows to obtain the correct settings. Also this patch contains a fix the missing implementation of g_win32_getlocale in eglib. -bill 2009-06-23 Bill Holmes billholme...@gmail.com * locales.c (ves_icall_System_Globalization_CultureInfo_construct_datetime_format) (ves_icall_System_Globalization_CultureInfo_construct_number_format) : For Windows call GetLocaleInfoA when possible to populate the culture info. This is needed when users customize a language for the regional options. * locales.c (get_current_locale_name) : Replace the eglib call to g_win32_getlocale. Contributed under MIT/X11 license. CultureInfo_construct.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] COM Interop - Support for out parameters of type SAFEARRAY[VARIANT]
Committed to trunk. r136836. On Sun, Jun 7, 2009 at 11:50 PM, Sylvain Dupontdupo...@gmail.com wrote: Bill, Thanks for the feedback. I attach an updated patch that addresses the issues you found. Here are the details: 1) Failing cominterop.exe tests: Sorry for not catching that. There was a flaw in my initial testing approach. Basically I only tested with assemblies compiled with the Microsoft compiler and never tested assemblies compiled with the mono mcs compiler. Due to a bug in the mcs compiler the SafeArraySubType marshal attribute option was not properly generated. It was being dropped. I fixed that issue in the attached patch by making changes to two files: reflection.c and CustomAttributeBuilder.cs. 2) Tab problems in cominterop.cs: I fixed the issues you noticed in cominterop.cs. I also did one pass on all the files to clean-up tabs, white spaces, formatting, etc. 3) Changelog entries: I updated the changelogs in the 3 directories where I made changes. Thanks, Sylvain On Wed, Jun 3, 2009 at 5:02 PM, Bill Holmes billholme...@gmail.com wrote: Sorry I should have mentioned that I tested this on Win32 and Winx64. On Wed, Jun 3, 2009 at 5:00 PM, Bill Holmes billholme...@gmail.com wrote: I tested this patch out and the cominterop.exe test does not work. I get a return value of 62. Second I noticed some tab problems with your formatting in cominterop.cs. Finally It makes it easier for me to commit a patch if you include ChangeLog entirs. thanks -bill On Sun, May 17, 2009 at 8:43 PM, Sylvain Dupont dupo...@gmail.com wrote: Hi, The patch attached adds support for marshalling out parameters of type SAFEARRAY[VARIANT]. In addition to the tests included in the patch, I have also tested this successfully against other COM components, both on Windows and Linux (using Mainwin and with the MONO_COM environment variable set to MS). Contributed under MIT/X11 license. Thanks, Sylvain ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] CultureInfo_construct datetime_format and number_format fix for Windows.
Hi, On Windows users can customize the regional options for their language. To get this information you can call GetLocaleInfo to obtain each individual setting. The attached patch is a new implementation of ves_icall_System_Globalization_CultureInfo_construct_datetime_format and ves_icall_System_Globalization_CultureInfo_construct_number_format for Windows to obtain the correct settings. Also this patch contains a fix the missing implementation of g_win32_getlocale in eglib. -bill 2009-06-23 Bill Holmes billholme...@gmail.com * locales.c (ves_icall_System_Globalization_CultureInfo_construct_datetime_format) (ves_icall_System_Globalization_CultureInfo_construct_number_format) : For Windows call GetLocaleInfoA when possible to populate the culture info. This is needed when users customize a language for the regional options. * locales.c (get_current_locale_name) : Replace the eglib call to g_win32_getlocale. Contributed under MIT/X11 license. CultureInfo_construct.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Interrupting socket calls on Windows during shutdown.
Hi, We have run into another problem on Windows with socket calls on background threads not stopping during shutdown. The attached patch sets a flag on the thread struct around the socket calls. If this flag is set when thread manage is called that thread will be killed during the APC call. http://msdn.microsoft.com/en-us/library/ms684954(VS.85).aspx This only applies to threads that are stopping (process shutdown) and are background threads. -bill 2009-06-22 Bill Holmes billholme...@gmail.com * object-internals.h : Adding interrupt_on_stop field. * threads.c (mono_thread_request_interruption) : On Windows exit the thread if interrupt_on_stop is set. * socket-io.c (ves_icall_System_Net_Sockets_Socket_Accept_internal) : Removing old interrupt logic and setting the interrupt_on_stop for the thread when calling accept. * socket-io.c (ves_icall_System_Net_Sockets_Socket_Receive_internal) : setting the interrupt_on_stop for the thread when calling accept. * Thread.cs : Adding interrupt_on_stop field. Contributed under MIT/X11 license. socket_interrupt.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Adding to the PInvoke search path.
After more discussion on IRC this it was decided to do this using the dllmap and not an environment variable. If the target is set to . the declaring assembly directory will be used when attempting to locate the un-manged library. -bill 2009-06-03 Bill Holmes billholme...@gmail.com * loader.c (mono_lookup_pinvoke_call): If the dllmap target is equal to . the declaring assembly path will be used to find the shared library first. Code is contributed under MIT/X11 license. On Mon, Jun 1, 2009 at 12:41 PM, Bill Holmes billholme...@gmail.com wrote: Hi, The attached patch was discussed on IRC last week. We found that MS.Net uses the directory of the declaring assembly when searching for shared libraries to invoke unmanaged code. The outcome of the conversation was that we did not want the behavior by default in Mono. However an environment variable could control this behavior. Whit this patch setting MONO_PINVOKE_SEARCH to USE_ASSEMBLY_PATH will enable this. -bill 2009-06-01 Bill Holmes billholme...@gmail.com * loader.c (mono_loader_init): Check for and process the MONO_PINVOKE_SEARCH environment variable. * loader.c (mono_lookup_pinvoke_call): If MONO_PINVOKE_SEARCH is set to USE_ASSEMBLY_PATH, add the declaring assembly directory to resolve shared libraries. Code is contributed under MIT/X11 license. mono_pinvoke_search.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] COM Interop - Support for out parameters of type SAFEARRAY[VARIANT]
I tested this patch out and the cominterop.exe test does not work. I get a return value of 62. Second I noticed some tab problems with your formatting in cominterop.cs. Finally It makes it easier for me to commit a patch if you include ChangeLog entirs. thanks -bill On Sun, May 17, 2009 at 8:43 PM, Sylvain Dupont dupo...@gmail.com wrote: Hi, The patch attached adds support for marshalling out parameters of type SAFEARRAY[VARIANT]. In addition to the tests included in the patch, I have also tested this successfully against other COM components, both on Windows and Linux (using Mainwin and with the MONO_COM environment variable set to MS). Contributed under MIT/X11 license. Thanks, Sylvain ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] COM Interop - Support for out parameters of type SAFEARRAY[VARIANT]
Sorry I should have mentioned that I tested this on Win32 and Winx64. On Wed, Jun 3, 2009 at 5:00 PM, Bill Holmes billholme...@gmail.com wrote: I tested this patch out and the cominterop.exe test does not work. I get a return value of 62. Second I noticed some tab problems with your formatting in cominterop.cs. Finally It makes it easier for me to commit a patch if you include ChangeLog entirs. thanks -bill On Sun, May 17, 2009 at 8:43 PM, Sylvain Dupont dupo...@gmail.com wrote: Hi, The patch attached adds support for marshalling out parameters of type SAFEARRAY[VARIANT]. In addition to the tests included in the patch, I have also tested this successfully against other COM components, both on Windows and Linux (using Mainwin and with the MONO_COM environment variable set to MS). Contributed under MIT/X11 license. Thanks, Sylvain ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Allows cominterop_ccw_queryinterface to find interfaces implemented by base classes.
Tom, Can you test the attached patch against your code? You patch worked just fine, but I did not want to add the mono_class_get_all_implemented_interfaces to class.c. Please let me know if this works for you. -bill On Wed, Apr 29, 2009 at 7:20 PM, Tom Hindle tom_hin...@sil.org wrote: Hi, Could someone review this patch? Patch attached to following: https://bugzilla.novell.com/show_bug.cgi?id=499566 Given this is a potential frequently called function would it be worth doing either of the following optimizations? 1. Don't look looking for interfaces on Object class. 2. Cache the results of the function, eg a map of classname, array of all implemented interfaces Thanks Tom ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list bug-499566.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Windows fix for eglib g_find_program_in_path
Hi, The attached patch for eglib g_find_program_in_path uses additional suffixes when searching for the program. http://library.gnome.org/devel/glib/unstable/glib-Miscellaneous-Utility-Functions.html#g-find-program-in-path On Windows, if program does not have a file type suffix, tries with the suffixes .exe, .cmd, .bat and .com, and the suffixes in the PATHEXT environment variable. -bill 2009-06-02 Bill Holmes billholme...@gmail.com * src/gpath.c (g_find_program_in_path): While searching on Windows also try additional suffixes .exe, .cmd, .bat, and.com. Contributed under MIT/X11 license. g_find_program_in_path.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Adding to the PInvoke search path.
Hi, The attached patch was discussed on IRC last week. We found that MS.Net uses the directory of the declaring assembly when searching for shared libraries to invoke unmanaged code. The outcome of the conversation was that we did not want the behavior by default in Mono. However an environment variable could control this behavior. Whit this patch setting MONO_PINVOKE_SEARCH to USE_ASSEMBLY_PATH will enable this. -bill 2009-06-01 Bill Holmes billholme...@gmail.com * loader.c (mono_loader_init): Check for and process the MONO_PINVOKE_SEARCH environment variable. * loader.c (mono_lookup_pinvoke_call): If MONO_PINVOKE_SEARCH is set to USE_ASSEMBLY_PATH, add the declaring assembly directory to resolve shared libraries. Code is contributed under MIT/X11 license. mono_pinvoke_search.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Adding hooks for BSTR Marshaling
Hi, I have added and attached the work mentioned in my original dealing with Marshal.AllocCoTaskMem and Marshal.AllocHGlobal. The problem I am trying to solve is the same as before. Our application expects to use its own allocator for these calls, not g_malloc and g_free. monomarshalhooks5.patch contains all the changes for BSTR, CoTaskMem and HGlobal, but I will commit the BSTR fix first and then other allocator changes second. -bill 2009-05-28 Bill Holmes billholme...@gmail.com * marshal-hooks.h : Adding declaration for mono_install_alloc_hglobal_funcs and mono_install_alloc_cotaskmem_funcs. * marshal.c : Adding mono_install_alloc_hglobal_funcs to override alloc, realloc and free functions for HGlobal * marshal.c : Adding mono_install_alloc_cotaskmem_funcs to override alloc, realloc and free functions for CoTaskMem Code is contributed under MIT/X11 license. On Fri, May 22, 2009 at 12:15 PM, Bill Holmes billholme...@gmail.com wrote: Hi, The attached patch allows hook functions to be registered with mono to use when marshaling BSTRs. I need this functionality because the Win32 API emulator we use requires that the encoding is ucs4 and another allocator be used. This patch only correct part of my problem. If this is approved I will be adding similar code for Marshal.AllocCoTaskMem and Marshal.AllocHGlobal, which will be a separate commit. 2009-05-22 Bill Holmes billholme...@gmail.com * cominterop.c : mono_string_to_bstr, mono_string_from_bstr and mono_free_bstr changed to call external hooks if installed. mono_install_bstr_funcs added to the set the hooks. * marshal-hooks.h : Added to declare mono_install_bstr_funcs * Makefile.am : Adding marshal-hooks.h to the list of public API header files. Code is contributed under MIT/X11 license. -bill monocomstring_new4.patch Description: Binary data monomarshalhooks5.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Adding hooks for BSTR Marshaling
Hi, The attached patch allows hook functions to be registered with mono to use when marshaling BSTRs. I need this functionality because the Win32 API emulator we use requires that the encoding is ucs4 and another allocator be used. This patch only correct part of my problem. If this is approved I will be adding similar code for Marshal.AllocCoTaskMem and Marshal.AllocHGlobal, which will be a separate commit. 2009-05-22 Bill Holmes billholme...@gmail.com * cominterop.c : mono_string_to_bstr, mono_string_from_bstr and mono_free_bstr changed to call external hooks if installed. mono_install_bstr_funcs added to the set the hooks. * marshal-hooks.h : Added to declare mono_install_bstr_funcs * Makefile.am : Adding marshal-hooks.h to the list of public API header files. Code is contributed under MIT/X11 license. -bill monocomstring_new4.patch Description: Binary data ___ 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 mono_thread_get_stack_bounds on windows
I tested the patch and the test program on my x64 XP machine. (64-bit and WOW64.) The test program runs as expected and the runtime tests show no problems. -bill On Thu, May 21, 2009 at 9:40 AM, Rodrigo Kumpera kump...@gmail.com wrote: Here is a test program that can be used to verify how it works. Cheers, Rodrigo On Wed, May 20, 2009 at 7:32 PM, Rodrigo Kumpera kump...@gmail.com wrote: And, of course, I forgot to attach the patch. On Wed, May 20, 2009 at 7:31 PM, Rodrigo Kumpera kump...@gmail.com wrote: Forgot to mention that there is another well know hack to discover stack bounds and why I rather like this one. The hack is to use VirtualQuery on %esp and expand the range to upward regions. I think the VirtualQuery hack is worse as it works by using a somewhat ok heuristics and OTOH the NtCurrentTe one provides precise information and I doubt it will disapear overnight. On Wed, May 20, 2009 at 7:25 PM, Rodrigo Kumpera kump...@gmail.com wrote: Hey, Attached is a patch that implements this function on windows. Tested only on XP/win32. Cheers, Rodrigo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Small fix for MSVC builds.
Hi, socket-wrappers.h includes sys/select.h and sys/time.h. These files are not available for the MSVC builds. The attached patch moves those include statements to the !WINDOWS part of socket-wrappers.h. 2009-04-24 Bill Holmes billholme...@gmail.com * socket-wrappers.h : Move include statements to fix the MSVC builds. Code is contributed under MIT/X11 license. -bill socket-wrappers_h.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Windows runtime tests hung.
Hi, On Windows some of the runtime tests are not completing since r127661 (I believe.) The attached patch is a workaround for the affected tests. On Windows we rely on QueueUserAPC to increment thread_interruption_requested. The way the tests are currently written there is no opportunity to execute the APC. Adding a sleep provides that opportunity. -bill 2009-04-01 Bill Holmes billholme...@gmail.com * finalizer-abort.cs, finalizer-exception.cs, finalizer-exit.cs : Adding a sleep to the waiting thread to give Mono on Windows an opportunity to interrupt the thread via QueueUserAPC. Contributed under MIT/X11 license. runtime_test.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Windows runtime tests hung.
Understood, that is why I said it was a workaround. In my opinion the problems with QueueUserAPC are well know and do not need these particular three tests to remind us of that. Can we work around a well know issue to allow these tests to exercise what they are intended to. -bill On Wed, Apr 1, 2009 at 10:33 AM, Rodrigo Kumpera kump...@gmail.com wrote: This is only a hack around the fact the we don't support proper interruption on windows. 2009/4/1 Bill Holmes billholme...@gmail.com Hi, On Windows some of the runtime tests are not completing since r127661 (I believe.) The attached patch is a workaround for the affected tests. On Windows we rely on QueueUserAPC to increment thread_interruption_requested. The way the tests are currently written there is no opportunity to execute the APC. Adding a sleep provides that opportunity. -bill 2009-04-01 Bill Holmes billholme...@gmail.com * finalizer-abort.cs, finalizer-exception.cs, finalizer-exit.cs : Adding a sleep to the waiting thread to give Mono on Windows an opportunity to interrupt the thread via QueueUserAPC. Contributed under MIT/X11 license. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Changes for CreateThread calls.
Hi, That fix does not work with the MSVC builds. That attached patch is one way to fix it. thanks -bill On Fri, Mar 27, 2009 at 9:36 AM, Zoltan Varga var...@gmail.com wrote: Hi, This is now fixed in r130385 by adding a new 'mono_create_thread' helper function. Zoltan 2009/3/25 Bill Holmes billholme...@gmail.com Hi, The attached patch fixes some problems I was seeing with thread IDs on Winx64. What I found was that the thread ID argument of CreateThread is a ulong which is not 64 bits on Winx64. So when called with the address of a size variable the top 32 bits are garbage. This patch simply initializes all thread ID variables to zero before calling CreateThread. Is there a better way to fix this? -bill 2009-03-25 Bill Holmes billholme...@gmail.com * appdomain.c (mono_domain_unload), * attach.c (transport_start_receive), * threads.c (mono_thread_create_internal), * threads.c (ves_icall_System_Threading_Thread_Thread_internal): Initialize the tid variable to 0 before calls to CreateThread. This is needed for Winx64 because that argument is only 32 bits. Code is contributed under MIT/X11 license. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ttypes.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Changes for CreateThread calls.
Hi, The attached patch fixes some problems I was seeing with thread IDs on Winx64. What I found was that the thread ID argument of CreateThread is a ulong which is not 64 bits on Winx64. So when called with the address of a size variable the top 32 bits are garbage. This patch simply initializes all thread ID variables to zero before calling CreateThread. Is there a better way to fix this? -bill 2009-03-25 Bill Holmes billholme...@gmail.com * appdomain.c (mono_domain_unload), * attach.c (transport_start_receive), * threads.c (mono_thread_create_internal), * threads.c (ves_icall_System_Threading_Thread_Thread_internal): Initialize the tid variable to 0 before calls to CreateThread. This is needed for Winx64 because that argument is only 32 bits. Code is contributed under MIT/X11 license. CreateThread.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Changes for CreateThread calls.
Kornél, Yes that would work too. Thanks -bill 2009/3/25 Kornél Pál kornel...@gmail.com: Wouldn't just this be enough? in mono_thread_create_internal: #ifdef PLATFORM_WIN32 DWORD tid; #else gsize tid; #endif Kornél Bill Holmes wrote: Hi, The attached patch fixes some problems I was seeing with thread IDs on Winx64. What I found was that the thread ID argument of CreateThread is a ulong which is not 64 bits on Winx64. So when called with the address of a size variable the top 32 bits are garbage. This patch simply initializes all thread ID variables to zero before calling CreateThread. Is there a better way to fix this? -bill 2009-03-25 Bill Holmes billholme...@gmail.com * appdomain.c (mono_domain_unload), * attach.c (transport_start_receive), * threads.c (mono_thread_create_internal), * threads.c (ves_icall_System_Threading_Thread_Thread_internal): Initialize the tid variable to 0 before calls to CreateThread. This is needed for Winx64 because that argument is only 32 bits. Code is contributed under MIT/X11 license. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Marshaling bools native-managed
Hi, After discussing this patch with Zoltan last night on IRC we decided to make two variations of this patch. One for the trunk and one for the 2.4 branch. The reasoning being that we should not change the default behavior of marshaling bools from native to managed this close to the branch release. For the trunk patch we will now marshal bools as 32-bit integers by default and for the branch we will continue to marshal bools as bytes as it has been done in the past. In both patches if a MarshalAs attribute is specified it will now be processed. This patch does affect all calls from native to managed that include bool arguments and is not exclusive to COM. -bill trunk: 2009-02-13 Bill Holmes billholme...@gmail.com * object-internals.h : Fixing a typo in the MonoReflectionComVisibleAttribute struct. * marshal.c (cominterop_com_visible): Check the implemented interfaces for ComImport. * marshal.c (cominterop_get_native_wrapper_adjusted): For COM calls assume that bools should be treated as VARIANTBOOLs. * marshal.c (emit_marshal_boolean): Adding cases for MARSHAL_ACTION_MANAGED_CONV_IN and MARSHAL_ACTION_MANAGED_CONV_OUT. * marshal.c (mono_marshal_emit_managed_wrapper): Adding calls to emit_marshal MARSHAL_ACTION_MANAGED_CONV_IN and OUT for bools. * marshal.c (cominterop_get_ccw): For COM calls assume that bools should be treated as VARIANTBOOLs. Code is contributed under MIT/X11 license. branch: 2009-02-13 Bill Holmes billholme...@gmail.com Backport of r(fill in later). This is a safer variant of the trunk for the 2.4 branch. The default in emit_marshal_boolean for this version is I1. * object-internals.h : Fixing a typo in the MonoReflectionComVisibleAttribute struct. * marshal.c (cominterop_com_visible): Check the implemented interfaces for ComImport. * marshal.c (cominterop_get_native_wrapper_adjusted): For COM calls assume that bools should be treated as VARIANTBOOLs. * marshal.c (emit_marshal_boolean): Adding cases for MARSHAL_ACTION_MANAGED_CONV_IN and MARSHAL_ACTION_MANAGED_CONV_OUT. * marshal.c (mono_marshal_emit_managed_wrapper): Adding calls to emit_marshal MARSHAL_ACTION_MANAGED_CONV_IN and OUT for bools. * marshal.c (cominterop_get_ccw): For COM calls assume that bools should be treated as VARIANTBOOLs. Code is contributed under MIT/X11 license. On Wed, Feb 11, 2009 at 7:29 PM, Zoltan Varga var...@gmail.com wrote: Hi, This looks ok, I'm just concerned that the new code will be run even in non-com situations, and it might cause problems, like it uses CEE_LDIND_I4 to load a bool value. Zoltan 2009/2/12 Bill Holmes billholme...@gmail.com: Hi, The attached patch fixes some problems we are seeing with marshaling bools and IDspatch types in Native code. I can split the patch separating the bool changes form the dispatch changes if needed. I would like to apply this to the 2.4 branch as well. -bill 2009-02-12 Bill Holmes billholme...@gmail.com * object-internals.h : Fixing a typo in the MonoReflectionComVisibleAttribute struct. * marshal.c (cominterop_com_visible): Check the implemented interfaces for ComImport. * marshal.c (cominterop_get_native_wrapper_adjusted): For COM calls assume that bools should be treated as VARIANTBOOLs. * marshal.c (emit_marshal_boolean): Adding cases for MARSHAL_ACTION_MANAGED_CONV_IN and MARSHAL_ACTION_MANAGED_CONV_OUT. * marshal.c (mono_marshal_emit_managed_wrapper): Adding calls to emit_marshal MARSHAL_ACTION_MANAGED_CONV_IN and OUT for bools. * marshal.c (cominterop_get_ccw): For COM calls assume that bools should be treated as VARIANTBOOLs. Code is contributed under MIT/X11 license. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Index: mono/metadata/ChangeLog === --- mono/metadata/ChangeLog (revision 126719) +++ mono/metadata/ChangeLog (working copy) @@ -1,3 +1,25 @@ +2009-02-13 Bill Holmes billholme...@gmail.com + + * object-internals.h : Fixing a typo in the + MonoReflectionComVisibleAttribute struct. + + * marshal.c (cominterop_com_visible): Check the implemented + interfaces for ComImport. + + * marshal.c (cominterop_get_native_wrapper_adjusted): For COM calls + assume that bools should be treated as VARIANTBOOLs. + + * marshal.c (emit_marshal_boolean): Adding cases for + MARSHAL_ACTION_MANAGED_CONV_IN and MARSHAL_ACTION_MANAGED_CONV_OUT. + + * marshal.c (mono_marshal_emit_managed_wrapper): Adding calls
[Mono-dev] [PATCH] Marshaling bools native-managed
Hi,
The attached patch fixes some problems we are seeing with marshaling
bools and IDspatch types in Native code.
I can split the patch separating the bool changes form the dispatch
changes if needed. I would like to apply this to the 2.4 branch as
well.
-bill
2009-02-12 Bill Holmes billholme...@gmail.com
* object-internals.h : Fixing a typo in the
MonoReflectionComVisibleAttribute struct.
* marshal.c (cominterop_com_visible): Check the implemented
interfaces for ComImport.
* marshal.c (cominterop_get_native_wrapper_adjusted): For COM calls
assume that bools should be treated as VARIANTBOOLs.
* marshal.c (emit_marshal_boolean): Adding cases for
MARSHAL_ACTION_MANAGED_CONV_IN and MARSHAL_ACTION_MANAGED_CONV_OUT.
* marshal.c (mono_marshal_emit_managed_wrapper): Adding calls to
emit_marshal MARSHAL_ACTION_MANAGED_CONV_IN and OUT for bools.
* marshal.c (cominterop_get_ccw): For COM calls assume that bools
should be treated as VARIANTBOOLs.
Code is contributed under MIT/X11 license.
Index: mono/metadata/ChangeLog
===
--- mono/metadata/ChangeLog (revision 126646)
+++ mono/metadata/ChangeLog (working copy)
@@ -1,3 +1,25 @@
+2009-02-12 Bill Holmes billholme...@gmail.com
+
+ * object-internals.h : Fixing a typo in the
+ MonoReflectionComVisibleAttribute struct.
+
+ * marshal.c (cominterop_com_visible): Check the implemented
+ interfaces for ComImport.
+
+ * marshal.c (cominterop_get_native_wrapper_adjusted): For COM calls
+ assume that bools should be treated as VARIANTBOOLs.
+
+ * marshal.c (emit_marshal_boolean): Adding cases for
+ MARSHAL_ACTION_MANAGED_CONV_IN and MARSHAL_ACTION_MANAGED_CONV_OUT.
+
+ * marshal.c (mono_marshal_emit_managed_wrapper): Adding calls to
+ emit_marshal MARSHAL_ACTION_MANAGED_CONV_IN and OUT for bools.
+
+ * marshal.c (cominterop_get_ccw): For COM calls assume that bools
+ should be treated as VARIANTBOOLs.
+
+ Code is contributed under MIT/X11 license.
+
2009-02-11 Mark Probst mark.pro...@gmail.com
* class.c, class-internals.h: mono_method_get_context_general()
Index: mono/metadata/marshal.c
===
--- mono/metadata/marshal.c (revision 126646)
+++ mono/metadata/marshal.c (working copy)
@@ -495,24 +495,39 @@
{
static MonoClass *ComVisibleAttribute = NULL;
MonoCustomAttrInfo *cinfo;
+ GPtrArray *ifaces;
+ MonoBoolean visible = 0;
/* Handle the ComVisibleAttribute */
if (!ComVisibleAttribute)
ComVisibleAttribute = mono_class_from_name (mono_defaults.corlib, System.Runtime.InteropServices, ComVisibleAttribute);
- cinfo = mono_custom_attrs_from_class (klass);
+ cinfo = mono_custom_attrs_from_class (klass);
if (cinfo) {
MonoReflectionComVisibleAttribute *attr = (MonoReflectionComVisibleAttribute*)mono_custom_attrs_get_attr (cinfo, ComVisibleAttribute);
- if (!attr)
- return FALSE;
+ if (attr)
+ visible = attr-visible;
if (!cinfo-cached)
mono_custom_attrs_free (cinfo);
-
- if (attr-visible)
+ if (visible)
return TRUE;
}
- return FALSE;
+
+ ifaces = mono_class_get_implemented_interfaces (klass);
+ if (ifaces) {
+ int i;
+ for (i = 0; i ifaces-len; ++i) {
+ MonoClass *ic = NULL;
+ ic = g_ptr_array_index (ifaces, i);
+ if (MONO_CLASS_IS_IMPORT (ic))
+visible = TRUE;
+
+ }
+ g_ptr_array_free (ifaces, TRUE);
+ }
+ return visible;
+
}
static void cominterop_raise_hr_exception (int hr)
@@ -3296,6 +3311,10 @@
mspecs[mspec_index] = g_new0 (MonoMarshalSpec, 1);
mspecs[mspec_index]-native = MONO_NATIVE_INTERFACE;
}
+ else if (sig_native-params[i]-type == MONO_NATIVE_BOOLEAN) {
+mspecs[mspec_index] = g_new0 (MonoMarshalSpec, 1);
+mspecs[mspec_index]-native = MONO_NATIVE_VARIANTBOOL;
+ }
}
}
@@ -3315,6 +3334,10 @@
mspecs[0] = g_new0 (MonoMarshalSpec, 1);
mspecs[0]-native = MONO_NATIVE_INTERFACE;
}
+ else if (sig-ret-type == MONO_NATIVE_BOOLEAN) {
+mspecs[0] = g_new0 (MonoMarshalSpec, 1);
+mspecs[0]-native = MONO_NATIVE_VARIANTBOOL;
+ }
}
}
@@ -8489,6 +8512,68 @@
mono_mb_emit_stloc (mb, 3);
break;
+ case MARSHAL_ACTION_MANAGED_CONV_IN: {
+ gint variant_bool = 0;
+ guint8 ldop = CEE_LDIND_I4;
+ if (!t-byref)
+ break;
+
+ conv_arg = mono_mb_add_local (mb, mono_defaults.boolean_class-byval_arg);
+
+ *conv_arg_type = mono_defaults.int32_class-byval_arg;
+
+ if (spec) {
+ switch (spec-native) {
+ case MONO_NATIVE_I1:
+ case MONO_NATIVE_U1:
+*conv_arg_type = mono_defaults.byte_class-this_arg;
+ldop = CEE_LDIND_I1;
+break;
+ case MONO_NATIVE_VARIANTBOOL:
+*conv_arg_type = mono_defaults.int16_class-this_arg;
+variant_bool = 1;
+ldop = CEE_LDIND_I2;
+break;
+ default:
+g_warning (marshalling bool as native type %x is currently not supported, spec
Re: [Mono-dev] [PATCH] Windows Socket Accept Fix.
Can someone look at this? I will fix my spelling in the ChangeLog before I commit. ;) On Tue, Feb 3, 2009 at 1:15 PM, Bill Holmes billholme...@gmail.com wrote: Hi, The attached patch corrects an error I introduced with r122252. I would like to apply it to the 2.4 branch as well. -bill 2009-02-03 Bill Holmes billholme...@gmail.com * socket-io.c (ves_icall_System_Net_Sockets_Socket_Accept_internal): For Win32, add additoinal break conditons for accept. Code is contributed under MIT/X11 license. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Windows Socket Accept Fix.
Hi,
The attached patch corrects an error I introduced with r122252. I
would like to apply it to the 2.4 branch as well.
-bill
2009-02-03 Bill Holmes billholme...@gmail.com
* socket-io.c (ves_icall_System_Net_Sockets_Socket_Accept_internal):
For Win32, add additoinal break conditons for accept.
Code is contributed under MIT/X11 license.
Index: mono/metadata/ChangeLog
===
--- mono/metadata/ChangeLog (revision 125560)
+++ mono/metadata/ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2009-02-03 Bill Holmes billholme...@gmail.com
+
+ * socket-io.c (ves_icall_System_Net_Sockets_Socket_Accept_internal):
+ For Win32, add additoinal break conditons for accept.
+
+ Code is contributed under MIT/X11 license.
+
2009-02-03 Rodrigo Kumpera rkump...@novell.com
* verify.c: Added stack_slot_full_name to provide decent and more meanfull
Index: mono/metadata/socket-io.c
===
--- mono/metadata/socket-io.c (revision 125560)
+++ mono/metadata/socket-io.c (working copy)
@@ -853,6 +853,7 @@
if (curthread) {
for (;;) {
int selectret;
+int optlen = sizeof (gint);
TIMEVAL timeout;
fd_set readfds;
FD_ZERO (readfds);
@@ -864,6 +865,15 @@
break;
if (curthread-state ThreadState_StopRequested)
return NULL;
+/* A negative return from select means that an error has occurred.
+ * Let _wapi_accept handle that.*/
+if (selectret != 0)
+ break;
+/* The socket's state may have changed. If it is no longer listening, stop.*/
+if (!getsockopt (sock, SOL_SOCKET, SO_ACCEPTCONN, (char*)selectret, optlen)) {
+ if (!selectret)
+ break;
+}
}
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mini-OS patches.
Miguel, Please add the attached patch to your changes. thanks -bill 2009/1/28 Miguel de Icaza mig...@novell.com: Hello folks, For the sake of better supporting proprietary operating systems, we need to split some of the functionality that today lives inside #ifdefs in mini.c The current patch splits out the OS-specific functionality into three files mini-darwin.c, mini-posix.c and mini-windows.c, these mostly deal with setting up exceptions today. Hopefully we can move some more OS-specific code into these files. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Index: msvc/libmono.vcproj === --- msvc/libmono.vcproj (revision 124931) +++ msvc/libmono.vcproj (working copy) @@ -6967,6 +6967,10 @@ /File File +RelativePath=..\mono\mini\mini-windows.c + + /File + File RelativePath=..\mono\mini\mini.c FileConfiguration ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Uri.IsWellFormedUriString should not throw an exception.
Hello Miguel,
Thanks for taking a closer look at this. I have attached another
patch that should work.
-bill
On Wed, Jan 28, 2009 at 9:28 AM, Miguel De Icaza mig...@novell.com wrote:
Hello,
1) MonoTests.System.UriTest3.IsWellFormedUriString_BadUriKind :
System.ArgumentException was expected
It seems that all we have to do is make sure that we do validate the UriKind
value that is passed to IsWellFormedUriString.
This test in particular passes a value that is out of range (an invalid
UriKind), so the new patch should just make sure that it is validating and
throwing an exception on the second parameter to IsWerllFormedUriString.
Miguel.
On Sat, Jan 24, 2009 at 9:06 PM, Miguel De Icaza mig...@novell.com
wrote:
Hello Bill,
Any chance of redoing the code as suggested by Robert?
If so, it is OK to get this on the 2.4 branch.
Miguel.
On Jan 21, 2009, at 12:01 PM, Bill Holmes wrote:
Hi,
The attached patch fixes the attached test.cs.
Uri.IsWellFormedUriString calls the .ctor which throws an exception.
The .ctor throwing the exception is expected behavior,
IsWellFormedUriString throwing is not expected.
I would also like to apply this to the 2.4 branch.
-bill
2009-01-21 Bill Holmes billholme...@gmail.com
* Uri.cs (IsWellFormedUriString): Changing IsWellFormedUriString
to not throw an exception but return false instead.
Contributed under MIT/X11 license.
test
.cs
IsWellFormedOriginalString
.patch___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Index: mcs/class/System/System/ChangeLog
===
--- mcs/class/System/System/ChangeLog (revision 124785)
+++ mcs/class/System/System/ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2009-01-28 Bill Holmes billholme...@gmail.com
+
+ * Uri.cs (IsWellFormedUriString): Changing IsWellFormedUriString
+ to not throw an exception but return false instead.
+
+ Contributed under MIT/X11 license.
+
2009-15-01 Leeszek Ciesielski skol...@gmail.com
* Uri.cs: Use registered UriParser when a custom schema is passed
Index: mcs/class/System/System/Uri.cs
===
--- mcs/class/System/System/Uri.cs (revision 124785)
+++ mcs/class/System/System/Uri.cs (working copy)
@@ -1992,8 +1992,18 @@
{
if (uriString == null)
return false;
- Uri uri = new Uri (uriString, uriKind);
- return uri.IsWellFormedOriginalString ();
+
+ if (uriKind != UriKind.RelativeOrAbsolute
+uriKind != UriKind.Absolute
+uriKind != UriKind.Relative) {
+string msg = Locale.GetText (Invalid UriKind value '{0}'., uriKind);
+throw new ArgumentException (uriKind, msg);
+ }
+
+ Uri uri;
+ if (Uri.TryCreate (uriString, uriKind, out uri))
+return uri.IsWellFormedOriginalString ();
+ return false;
}
public static bool TryCreate (string uriString, UriKind uriKind, out Uri result)
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Uri.IsWellFormedUriString should not throw an exception.
With the changes I get a test failure. I will not be committing this. 1) MonoTests.System.UriTest3.IsWellFormedUriString_BadUriKind : System.ArgumentException was expected On Sat, Jan 24, 2009 at 9:06 PM, Miguel De Icaza mig...@novell.com wrote: Hello Bill, Any chance of redoing the code as suggested by Robert? If so, it is OK to get this on the 2.4 branch. Miguel. On Jan 21, 2009, at 12:01 PM, Bill Holmes wrote: Hi, The attached patch fixes the attached test.cs. Uri.IsWellFormedUriString calls the .ctor which throws an exception. The .ctor throwing the exception is expected behavior, IsWellFormedUriString throwing is not expected. I would also like to apply this to the 2.4 branch. -bill 2009-01-21 Bill Holmes billholme...@gmail.com * Uri.cs (IsWellFormedUriString): Changing IsWellFormedUriString to not throw an exception but return false instead. Contributed under MIT/X11 license. test .cs IsWellFormedOriginalString .patch___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] C++, COM interop
Hi, Look at the ExtensibleClassFactory.RegisterObjectCreationCallback method. http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.extensibleclassfactory.registerobjectcreationcallback.aspx -bill On Tue, Jan 20, 2009 at 4:22 PM, QbProg tho...@gmail.com wrote: Hello Mono users and developers! I have a native C++ class library , a COM wrapper written in ATL and a .NET wrapper written in C++/CLI. Now, I'm thinking how it would be possible to write a mono wrapper that runs mainly in LINUX. Basically I see two suggested ways: - Write a flatten C version on the library and use P/Invoke - Use SWIG to do such a thing I don't like neither of these, since the wrapper has many functions and classes. I see a better in using a sort of COM / XPCOM interfaces. I have no problems in making the wrapper based on interfaces (like I did for the COM one). The only thing that I can not use are class factories since COM is not available in Windows. Hoever , I've got no problem in eventually writing a custom factory for required COM Classes. I see that there is a main difference between COM and XPCOM interop. (?) In com you can write CClass c = new cClass () and the COM layer will call the relative class factory. In XPCOm you have to call manually a function to create the class. The question is : is there a way to redirect the new for a COM class (in linux) so I can directly call a custom class factory function (this time internal) ? I.e. COMClass C = new COMClass; i.e. instead of calling CoCreateObject should call an internal function CreateCOMClass ? I don't know if I made it clear... I'll continue trying, and I'll share my experience, so maybe users can find an additional way to wrap C++ classes. Thank you. QbProg -- View this message in context: http://www.nabble.com/C%2B%2B%2C-COM-interop-tp21539294p21539294.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] PInvoke and language interopelability
Alfredo, I may not fully understand the problem. Are you simply asking how to call back into C# from C++? We use 2 different approaches. Function pointers. If you pass a C# delegate through the PInvoke layer C++ will view that as a function pointer. COM Interop. (Only supported on Windows and Linux.) This allows you to marshal a Managed object to C++ which then can call methods on that objects' interface(s). -bill ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] UNC support on Windows.
Hi,
The attached patch fixes a bug with launching an application on a
network share with mono.
-bill
2009-01-13 Bill Holmes billholme...@gmail.com
* gmisc-win32.c (g_path_is_absolute): Adding support for UNC
paths on Windows.
* mono-path.c (mono_path_canonicalize): Adding support for UNC
paths on Windows.
Contributed under MIT/X11 license.
Index: eglib/ChangeLog
===
--- eglib/ChangeLog (revision 123239)
+++ eglib/ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2009-01-13 Bill Holmes billholme...@gmail.com
+
+ * gmisc-win32.c (g_path_is_absolute): Adding support for UNC
+ paths on Windows.
+
+ Contributed under MIT/X11 license.
+
2009-01-08 Bill Holmes billholme...@gmail.com
* winconfig.h, src/gfile-posix.c :
Index: eglib/src/gmisc-win32.c
===
--- eglib/src/gmisc-win32.c (revision 123239)
+++ eglib/src/gmisc-win32.c (working copy)
@@ -93,11 +93,16 @@
{
g_return_val_if_fail (filename != NULL, FALSE);
- if (filename[0] != '\0' filename[1] != '\0' filename[1] == ':'
- filename[2] != '\0' (filename[2] == '\\' || filename[2] == '/'))
- return TRUE;
- else
- return FALSE;
+ if (filename[0] != '\0' filename[1] != '\0')
+ if (filename[1] == ':' filename[2] != '\0'
+ (filename[2] == '\\' || filename[2] == '/'))
+ return TRUE;
+ /* UNC paths */
+ else if (filename[0] == '\\' filename[1] == '\\'
+ filename[2] != '\0')
+ return TRUE;
+
+ return FALSE;
}
const gchar *
Index: mono/utils/ChangeLog
===
--- mono/utils/ChangeLog (revision 123239)
+++ mono/utils/ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2009-01-13 Bill Holmes billholme...@gmail.com
+
+ * mono-path.c (mono_path_canonicalize): Adding support for UNC
+ paths on Windows.
+
+ Contributed under MIT/X11 license.
+
2009-01-08 Bill Holmes billholme...@gmail.com
* mono-dl.c (mono_dl_open): Fix the MSVC build.
Index: mono/utils/mono-path.c
===
--- mono/utils/mono-path.c (revision 123239)
+++ mono/utils/mono-path.c (working copy)
@@ -67,6 +67,11 @@
lastpos = pos + 1;
pos = strchr (lastpos, G_DIR_SEPARATOR);
}
+
+#ifdef PLATFORM_WIN32 /* For UNC paths the first '\' is removed. */
+ if (*(lastpos-1) == G_DIR_SEPARATOR *(lastpos-2) == G_DIR_SEPARATOR)
+ lastpos = lastpos-1;
+#endif
if (dest != lastpos) strcpy (dest, lastpos);
return g_strreverse (abspath);
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Winx64 non-volatile register bug.
Hi,
I was debugging a problem with our application on Winx64 and tracked
it to some non-volatile registers not being preserved (rdi rsi)
Without finding the actual problem I simple scanned the code for
places referencing the other non-volatile registers and added code for
the missing registers.
I am not sure that all my changes are actually necessary since I am
not sure what some of these methods do and when they are used.
Could someone look at this patch file and let me know which changes,
if any, are not necessary. (Looking in Zoltan's direction.)
thanks
-bill
Index: mono/mini/exceptions-amd64.c
===
--- mono/mini/exceptions-amd64.c (revision 122701)
+++ mono/mini/exceptions-amd64.c (working copy)
@@ -589,6 +589,10 @@
new_ctx-r13 = lmf_addr-r13;
new_ctx-r14 = lmf_addr-r14;
new_ctx-r15 = lmf_addr-r15;
+#ifdef PLATFORM_WIN32
+ new_ctx-rdi = lmf_addr-rdi;
+ new_ctx-rsi = lmf_addr-rsi;
+#endif
}
else {
offset = omit_fp ? 0 : -1;
@@ -625,6 +629,14 @@
case AMD64_RBP:
new_ctx-rbp = reg;
break;
+#ifdef PLATFORM_WIN32
+ case AMD64_RDI:
+ new_ctx-rdi = reg;
+ break;
+ case AMD64_RSI:
+ new_ctx-rsi = reg;
+ break;
+#endif
default:
g_assert_not_reached ();
}
@@ -692,6 +704,10 @@
new_ctx-r13 = (*lmf)-r13;
new_ctx-r14 = (*lmf)-r14;
new_ctx-r15 = (*lmf)-r15;
+#ifdef PLATFORM_WIN32
+ new_ctx-rdi = (*lmf)-rdi;
+ new_ctx-rsi = (*lmf)-rsi;
+#endif
*lmf = (gpointer)(((guint64)(*lmf)-previous_lmf) ~1);
Index: mono/mini/mini-amd64.c
===
--- mono/mini/mini-amd64.c (revision 122701)
+++ mono/mini/mini-amd64.c (working copy)
@@ -1031,12 +1031,19 @@
regs = g_list_prepend (regs, (gpointer)AMD64_R13);
regs = g_list_prepend (regs, (gpointer)AMD64_R14);
regs = g_list_prepend (regs, (gpointer)AMD64_R15);
+
+#ifdef PLATFORM_WIN32
+ regs = g_list_prepend (regs, (gpointer)AMD64_RDI);
+ regs = g_list_prepend (regs, (gpointer)AMD64_RSI);
+#endif
regs = g_list_prepend (regs, (gpointer)AMD64_R10);
regs = g_list_prepend (regs, (gpointer)AMD64_R9);
regs = g_list_prepend (regs, (gpointer)AMD64_R8);
+#ifndef PLATFORM_WIN32
regs = g_list_prepend (regs, (gpointer)AMD64_RDI);
regs = g_list_prepend (regs, (gpointer)AMD64_RSI);
+#endif
regs = g_list_prepend (regs, (gpointer)AMD64_RDX);
regs = g_list_prepend (regs, (gpointer)AMD64_RCX);
regs = g_list_prepend (regs, (gpointer)AMD64_RAX);
@@ -1050,6 +1057,10 @@
regs = g_list_prepend (regs, (gpointer)AMD64_R13);
regs = g_list_prepend (regs, (gpointer)AMD64_R14);
regs = g_list_prepend (regs, (gpointer)AMD64_R15);
+#ifdef PLATFORM_WIN32
+ regs = g_list_prepend (regs, (gpointer)AMD64_RDI);
+ regs = g_list_prepend (regs, (gpointer)AMD64_RSI);
+#endif
}
return regs;
@@ -1082,12 +1093,18 @@
regs = g_list_prepend (regs, (gpointer)AMD64_R13);
regs = g_list_prepend (regs, (gpointer)AMD64_R14);
regs = g_list_prepend (regs, (gpointer)AMD64_R15);
+#ifdef PLATFORM_WIN32
+ regs = g_list_prepend (regs, (gpointer)AMD64_RDI);
+ regs = g_list_prepend (regs, (gpointer)AMD64_RSI);
+#endif
regs = g_list_prepend (regs, (gpointer)AMD64_R10);
regs = g_list_prepend (regs, (gpointer)AMD64_R9);
regs = g_list_prepend (regs, (gpointer)AMD64_R8);
+#ifndef PLATFORM_WIN32
regs = g_list_prepend (regs, (gpointer)AMD64_RDI);
regs = g_list_prepend (regs, (gpointer)AMD64_RSI);
+#endif
regs = g_list_prepend (regs, (gpointer)AMD64_RDX);
regs = g_list_prepend (regs, (gpointer)AMD64_RCX);
regs = g_list_prepend (regs, (gpointer)AMD64_RAX);
@@ -4537,6 +4554,10 @@
amd64_mov_membase_reg (code, cfg-frame_reg, lmf_offset + G_STRUCT_OFFSET (MonoLMF, r13), AMD64_R13, 8);
amd64_mov_membase_reg (code, cfg-frame_reg, lmf_offset + G_STRUCT_OFFSET (MonoLMF, r14), AMD64_R14, 8);
amd64_mov_membase_reg (code, cfg-frame_reg, lmf_offset + G_STRUCT_OFFSET (MonoLMF, r15), AMD64_R15, 8);
+#ifdef PLATFORM_WIN32
+ amd64_mov_membase_reg (code, cfg-frame_reg, lmf_offset + G_STRUCT_OFFSET (MonoLMF, rdi), AMD64_RDI, 8);
+ amd64_mov_membase_reg (code, cfg-frame_reg, lmf_offset + G_STRUCT_OFFSET (MonoLMF, rsi), AMD64_RSI, 8);
+#endif
}
/* Save callee saved registers */
@@ -4977,6 +4998,14 @@
if (cfg-used_int_regs (1 AMD64_R15)) {
amd64_mov_reg_membase (code, AMD64_R15, cfg-frame_reg, lmf_offset + G_STRUCT_OFFSET (MonoLMF, r15), 8);
}
+#ifdef PLATFORM_WIN32
+ if (cfg-used_int_regs (1 AMD64_RDI)) {
+ amd64_mov_reg_membase (code, AMD64_RDI, cfg-frame_reg, lmf_offset + G_STRUCT_OFFSET (MonoLMF, rdi), 8);
+ }
+ if (cfg-used_int_regs (1 AMD64_RSI)) {
+ amd64_mov_reg_membase (code, AMD64_RSI, cfg-frame_reg, lmf_offset + G_STRUCT_OFFSET (MonoLMF, rsi), 8);
+ }
+#endif
} else {
if (cfg-arch.omit_fp) {
___
Mono-devel-list mailing list
Re: [Mono-dev] [PATCH] patches that allow calling mono_init_com_types from native using ICall's.
Tom, I agree with Kornél. Please add mono_init_com_types to GetIUnknownForObjectInternal and GetIDispatchForObjectInternal. I do not understand why it would be needed in QueryInterfaceInternal. Even if the object is managed, cominterop_ccw_queryinterface would need the mono_init_com_types call, but that should have been called from GetIUnknownForObjectInternal (when you add it.) Another way to put it is, what are you calling QueryInterface on that needs the types initialized from mono_init_com_types? -bill ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] TcpChannel hang on Windows.
Kornél, I do agree that this is a general problem and not only an issue with accept. Also I do know that the patch is a workaround, or as we like to say treading the symptom and not that cause. I have spent much time trying to understand the shutdown behavior of MS. From what I can gather I does appear that MS kills the thread or simply ignores it. (So we agree on that as well.) For Mono I would suggest that killing all background threads on shutdown. (and only shutdown.) Ignoring the thread and allowing it to live on allows a window of opportunity to attempt to interact with other Mono internal objects that have been destroyed. Therefore killing the thread I believe is the better option. Another reason I believe that MS simply kills the thread is a different sample I tried. Consider a program that spawns a background thread. That thread only PInvokes into a call that simply loops. (while (1);) The program does exit with MS.Net. I have discussed this on IRC with a few others and exiting the thread is an unpopular solution. Killing a thread is about as accepted as using goto statements. ;) To be honest, even though I have spent 2 weeks looking at this I still do not feel comfortable that the Mono shutdown logic can handle killing threads. Another way to put it I am afraid that changing the shutdown logic would cause currently working Mono apps to start bombing because I just do not understand the full picture. -bill ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] TcpChannel hang on Windows.
Kornél, I do not understand what you example shows. I can understand the thread state problems. Is that all? Are you suggesting that I add to my patch to fix the state problem? Are you suggesting that the socket implementation is fine in svn and we need to address the abort/stop thread in a more general manner? Do you have any suggestions? What I do know is background threads that are blocked are causing mono to hang on exit. Foreground threads that are blocked should cause the process to hang on exit as that is how MS .Net behaves. Do you feel that we should not wait on background threads on exit, but simply kill them? I know it is a lot of questions but I am not certain of the direction you are trying to point me. This is a bug that I REALLY need fixed now. -bill ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] TcpChannel hang on Windows.
Kornél, After reading your mail a bunch more times and messing with the sample I think I finally get what you were saying. What I discovered was that the APC callback being a managed method gives mono a chance to check the thread state when crossing to and from the managed thread boundary. It is not the fact that you called an APC that was important. What is important is that the APC was a managed call. This does in fact give me some ideas on new things to try. I will let you know what I find. I suspect that my new conclusion will be a risky change that will require much testing. -bill ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Creating Managed COM objects from C++ (on linux).
We have dealt with this by registering a global class factory method
(that is implemented in C#) with native C++ code.
I assume you are hosting the mono runtime?
Take a look at the poor code example below and see if that gives you the idea.
-bill
/* C++ code */
void cppMain ()
{
// Init Mono Runtme
// Call managed InitManagedCOMFactory
IUnknown* pObj;
ManagedCOMFactoryCreateObject (CLSID_MyObj, pObj);
IFoo* pFoo;
pObj-QueryInterface (IID_IFoo, (void**)pFoo);
}
uint (*ManagedCOMFactoryCreateObject) (GUID*, IUnknown**);
void RegsterManagedCOMFactoryCreateObject (void* ptr)
{
ManagedCOMFactoryCreateObject = ptr;
}
/* C# code */
void InitManagedCOMFactory ()
{
RegsterManagedCOMFactoryCreateObject (ManagedCOMFactoryCreateObject);
}
uint ManagedCOMFactoryCreateObject (guid g, [MarshalAs (IUnknown)] out
object retObj)
{
if (g == myGuid)
retObj = new MyObject ();
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] System.Environment fixes for Windows
HI,
The attached patch fixes two problems we found System.Environment.
Calling Environment.GetEnvironmentVariable (IsNotSet,
EnvironmentVariableTarget.User) causes a nre with mono on Windows.
Calling Environment.SetEnvironmentVariable (...,
EnvironmentVariableTarget.User) does not notify the OS that a variable
has changed.
See http://msdn.microsoft.com/en-us/library/ms682653(VS.85).aspx
Thanks
-bill
2008-12-18 Bill Holmes billholme...@gmail.com
* Environment.cs (GetEnvironmentVariable) : Avoiding an nre if
the variable is not set.
* Environment.cs (SetEnvironmentVariable) : Adding a call to
internalBroadcastSettingChange to notify Windows that an environment
variable has changed.
* icall-def.h : Adding an internal call definition for
System.Environment.internalBroadcastSettingChange.
* icall.c : Adding a Windows only implementation to broadcast a
WM_SETTINGCHANGE when an environment variable has changed.
Contributed under MIT/X11 license.
Index: mcs/class/corlib/System/ChangeLog
===
--- mcs/class/corlib/System/ChangeLog (revision 121806)
+++ mcs/class/corlib/System/ChangeLog (working copy)
@@ -1,3 +1,14 @@
+2008-12-18 Bill Holmes billholme...@gmail.com
+
+ * Environment.cs (GetEnvironmentVariable) : Avoiding an nre if
+ the variable is not set.
+
+ * Environment.cs (SetEnvironmentVariable) : Adding a call to
+ internalBroadcastSettingChange to notify Windows that an environment
+ variable has changed.
+
+ Contributed under MIT/X11 license.
+
2008-12-18 Jb Evain jbev...@novell.com
* String.cs: the Compare methods that were specific to SL2 are now
Index: mcs/class/corlib/System/Environment.cs
===
--- mcs/class/corlib/System/Environment.cs (revision 121806)
+++ mcs/class/corlib/System/Environment.cs (working copy)
@@ -557,6 +557,9 @@
return GetLogicalDrivesInternal ();
}
+ [MethodImplAttribute (MethodImplOptions.InternalCall)]
+ private static extern void internalBroadcastSettingChange ();
+
#if NET_2_0
public static string GetEnvironmentVariable (string variable, EnvironmentVariableTarget target)
{
@@ -568,14 +571,16 @@
if (!IsRunningOnWindows)
return null;
using (Microsoft.Win32.RegistryKey env = Microsoft.Win32.Registry.LocalMachine.OpenSubKey (@SYSTEM\CurrentControlSet\Control\Session Manager\Environment)) {
- return env.GetValue (variable).ToString ();
+ object regvalue = env.GetValue (variable);
+ return (regvalue == null) ? null : regvalue.ToString ();
}
case EnvironmentVariableTarget.User:
new EnvironmentPermission (PermissionState.Unrestricted).Demand ();
if (!IsRunningOnWindows)
return null;
using (Microsoft.Win32.RegistryKey env = Microsoft.Win32.Registry.CurrentUser.OpenSubKey (Environment, false)) {
- return env.GetValue (variable).ToString ();
+ object regvalue = env.GetValue (variable);
+ return (regvalue == null) ? null : regvalue.ToString ();
}
default:
throw new ArgumentException (target);
@@ -645,6 +650,7 @@
env.DeleteValue (variable, false);
else
env.SetValue (variable, value);
+ internalBroadcastSettingChange ();
}
break;
case EnvironmentVariableTarget.User:
@@ -655,6 +661,7 @@
env.DeleteValue (variable, false);
else
env.SetValue (variable, value);
+ internalBroadcastSettingChange ();
}
break;
default:
Index: mono/mono/metadata/ChangeLog
===
--- mono/mono/metadata/ChangeLog (revision 121806)
+++ mono/mono/metadata/ChangeLog (working copy)
@@ -1,4 +1,14 @@
+2008-12-18 Bill Holmes billholme...@gmail.com
+
+ * icall-def.h : Adding an internal call definition for
+ System.Environment.internalBroadcastSettingChange.
+
+ * icall.c : Adding a Windows only implementation to broadcast a
+ WM_SETTINGCHANGE when an environment variable has changed.
+
+ Code is contributed under MIT/X11 license.
+
Thu Dec 18 16:35:22 CET 2008 Paolo Molaro lu...@ximian.com
* image.c: deal with the mmap failing when loading an image.
Index: mono/mono/metadata/icall-def.h
===
--- mono/mono/metadata/icall-def.h (revision 121806)
+++ mono/mono/metadata/icall-def.h (working copy)
@@ -243,6 +243,7 @@
ICALL(ENV_14, get_ProcessorCount, mono_cpu_count)
ICALL(ENV_15, get_TickCount, mono_msec_ticks)
ICALL(ENV_16, get_UserName, ves_icall_System_Environment_get_UserName)
+ICALL(ENV_16m, internalBroadcastSettingChange, ves_icall_System_Environment_BroadcastSettingChange)
ICALL(ENV_17, internalGetEnvironmentVariable, ves_icall_System_Environment_GetEnvironmentVariable)
ICALL(ENV_18, internalGetGacPath, ves_icall_System_Environment_GetGacPath)
ICALL(ENV_19
[Mono-dev] [PATCH] io-layer get_module_name patch
Hi,
In the get_module_name method the size argument is used as a byte
count but the callers consider it a character count.
See http://msdn.microsoft.com/en-us/library/ms683196(VS.85).aspx
This patch corrects that inconsistency.
Thanks
-bill
2008-12-18 Bill Holmes billholme...@gmail.com
* processes.c (get_module_name) : adjust size for unicode characters.
Code is contributed under MIT/X11 license.
Index: mono/mono/io-layer/ChangeLog
===
--- mono/mono/io-layer/ChangeLog (revision 121809)
+++ mono/mono/io-layer/ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2008-12-18 Bill Holmes billholme...@gmail.com
+
+ * processes.c (get_module_name) : adjust size for unicode characters.
+
+ Code is contributed under MIT/X11 license.
+
2008-11-21 Zoltan Varga var...@gmail.com
* atomic.h: Applied patch from Mihai Chelaru kef...@ngnetworks.ro. Add
Index: mono/mono/io-layer/processes.c
===
--- mono/mono/io-layer/processes.c (revision 121809)
+++ mono/mono/io-layer/processes.c (working copy)
@@ -1993,6 +1993,8 @@
__func__, process, module);
#endif
+ size = size*sizeof(gunichar2); /* adjust for unicode characters */
+
if (basename == NULL || size == 0) {
return(0);
}
___
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.ListViewItem.ListViewSubItem nre fix.
Hi,
The attached patch fixes the attached Program.cs.
2008-12-17 Bill Holmes billholme...@gmail.com
* ListViewItem.cs (ListViewSubItem.ctor): Initalizing the
SubItemStyle member field.
Contributed under MIT/X11 license.
-bill
class Program
{
static void Main (string[] args)
{
System.Windows.Forms.ListViewItem.ListViewSubItem test = new
System.Windows.Forms.ListViewItem.ListViewSubItem ();
test.BackColor = test.BackColor;
test.ForeColor = test.ForeColor;
test.Font = test.Font;
}
}Index: mcs/class/Managed.Windows.Forms/System.Windows.Forms/ChangeLog
===
--- mcs/class/Managed.Windows.Forms/System.Windows.Forms/ChangeLog
(revision 121702)
+++ mcs/class/Managed.Windows.Forms/System.Windows.Forms/ChangeLog
(working copy)
@@ -1,3 +1,10 @@
+2008-12-17 Bill Holmes billholme...@gmail.com
+
+ * ListViewItem.cs (ListViewSubItem.ctor): Initalizing the
+ SubItemStyle member field.
+
+ Contributed under MIT/X11 license.
+
2008-12-16 Carlos Alberto Cortez calberto.cor...@gmail.com
* ListBox.cs: In MultiColumn mode don't use top_index to calculate the
Index: mcs/class/Managed.Windows.Forms/System.Windows.Forms/ListViewItem.cs
===
--- mcs/class/Managed.Windows.Forms/System.Windows.Forms/ListViewItem.cs
(revision 121702)
+++ mcs/class/Managed.Windows.Forms/System.Windows.Forms/ListViewItem.cs
(working copy)
@@ -1223,6 +1223,8 @@
#region Public Constructors
public ListViewSubItem ()
+ : this (null, string.Empty, Color.Empty,
+ Color.Empty, null)
{
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] TcpChannel hang on Windows.
Kornél,
I tested your case and it appears to work fine with my changes. I
believe that this is because I check for the ThreadState_StopRequested
state. I do not check for ThreadState_AbortRequested. That is
intentional because that is the behavior I observed with MS .net.
Also if I understand it correctly mono_thread_manage wait on all non
background threads to complete before it sets the
ThreadState_StopRequested on the background threads only and waits for
those.
I also toggled the background flag in you example to ensure the two
runtimes behave the same.
Thanks so much for your review!
-bill
For those interested this is the case I am attempting to fix...
static void Main (string[] args)
{
TcpChannel tc = new TcpChannel (0);
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] COM Interop changes for COM objects in VARIANTs
Hi, The attached patches should only apply to COM interop. They fix some inconsistencies that we found in mono dealing with VARIANTs. When an IUnknown (or IDispatch) object is passed as a VARIANT to native code the vt field was different with mono. There is not great documentation for this but what I was able to pull together was the following. When a native object is wrapped with a VARIANT a QI is performed to determine if IDispatch is supported. If so then VT_DISPATCH is the value of vt otherwise VT_UNKNOWN. Managed object are the same, but it is the question of when a managed object supports Dispatch that is the tricky part. From what I have read and what I have observed a public object with the ComVisible attribute set to true support IDispatch. All others only support IUnknown. -bill For CCW_Dispatch.diff 2008-12-09 Bill Holmes [EMAIL PROTECTED] * object-internals.h : Adding a definition for MonoReflectionComVisibleAttribute. * marshal.c (cominterop_com_visible) : Method added to check the ComVisible attribute of a class. * marshal.c (cominterop_raise_hr_exception, cominterop_get_interface) : cominterop_raise_hr_exception added to consolidate common code to raise hr exceptions. * marshal.c (cominterop_can_support_dispatch) : Method added to determine if a managed class should support IDispatch. * marshal.c (cominterop_get_idispatch_for_objec, cominterop_ccw_queryinterfacet) : Added additional checks for managed object when getting an IDispatch interface. Code is contributed under MIT/X11 license. For VARIANT.diff 2008-12-09 Bill Holmes [EMAIL PROTECTED] * Variant.cs (SetValue): Changing the behavior for COM object in VARIANTs to match MS. Also adding support for BStrWrapper, UnknownWrapper, and DispatchWrapper. Contributed under MIT/X11 license. CCW_Dispatch.diff Description: Binary data VARIANT.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] String.GetHashCode on Mac
David,
We may have hit this before. See
http://www.nabble.com/String.GetHashCode-Discussion.-to18496625ef1367.html#a18496625
I lost tack of this issue after that thread but maybe it will help
someone else remember.
-bill
On Mon, Dec 1, 2008 at 9:25 AM, David Suarez
[EMAIL PROTECTED] wrote:
Hi,
I've run into a problem with the String.GetHashCode method in macosx
(10.5.3, intel). The point is I get the same hashcode for very different
strings, apparently only taking into account the last 7 chars of the
string. This happens with mono 2.0 installer.
Consider this test case:
using System;
namespace hashtest
{
class Class2
{
private static string[] testStrings2 = new string[]
{
something to worry about,
ing to worry about,
to worry about,
orry about,
y about,
about
};
[STAThread]
static void Main(string[] args)
{
foreach (string s in testStrings2) PrintHash(s,
s.GetHashCode());
}
private static void PrintHash(string str, int hash)
{
Console.WriteLine( hash [{1}] line: [{0}], str,
hash.ToString(X8));
}
}
}
Running on mac, I get this result:
hash [9DA57994] line: [something to worry about]
hash [9DA57994] line: [ing to worry about]
hash [9DA57994] line: [to worry about]
hash [9DA57994] line: [orry about]
hash [9DA57994] line: [y about]
hash [1DA57994] line: [ about]
It seems to me that the String.GetHashCode in String.cs is not getting
called, because this method works fine (I tested separately). Is this
happening to anybody else? Any clue on what code is being called on the
mac for getting the hash code of strings?
Thanks,
David
Is this happening to anybody else??
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] COM Interop cleanup needed in mini_cleanup.
Hi, We are seeing a problem with applications that host the mono and use COM. The attached patch includes code that will cause the runtime to release all COM objects that are registered in the rcw hash map in marshal.c. -bill 2008-11-20 Bill Holmes [EMAIL PROTECTED] * mini.c (mini_cleanup) : Adding a call to cominterop_release_all_rcws to release all runtime callable wrappers held by the runtime. * marshal.c : Adding cominterop_release_all_rcws to release all runtime callable wrappers held by the runtime. * marshal.h : Adding deceleration for cominterop_release_all_rcws. Contributed under MIT/X11 license. cominterop_release_all_rcws.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] COM change needed in marshal.c for IMarshal.
Hi, The attached patch adds an implementation for IMarshal to all COM callable wrappers. This patch should only affect Windows builds. I also would like to get this patch into the 2.2 branch. -bill 2008-11-17 Bill Holmes [EMAIL PROTECTED] * marshal.h : cominterop_ccw_getfreethreadedmarshaler added to return the free threaded marshaler when QueryInterface is called on a COM callable wrapper requesting the IMarshal interface. Code is contributed under MIT/X11 license. FreeThreadedMarshalerCCW2.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Implement Process.WaitForInputIdle on Windows.
Hi, The attached patch is a better implementation of Process.WaitForInputIdle for Windows. The behavior for all other platforms has not changed. I would also like to add this to the 2.2 branch. 2008-11-12 Bill Holmes [EMAIL PROTECTED] * process.h : Adding method declaration for ves_icall_System_Diagnostics_Process_WaitForInputIdle_internal. * process.c : Adding implementation for ves_icall_System_Diagnostics_Process_WaitForInputIdle_internal. * icall-def.h : Registering ICALL Processs.WaitForInputIdle_internal to ves_icall_System_Diagnostics_Process_WaitForInputIdle_internal. * wait.h : Adding method declaration for WaitForInputIdle. * wait.c : Adding implementation for WaitForInputIdle. * Process.cs : Adding an implementation for WaitForInputIdle to call the an internal call. The internal call is only implemented properly on Windows. Code is contributed under MIT/X11 license. -bill WaitForInputIdle.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Lining error while compilation Mono under Windows/VS2008
Hi, This configuration works correctly for me. I believe the problem is that you are using the VS Dependency zip-archive. That archive has not been kept up to date. I know there is documentation somewhere that points to using it but that should be changed. From http://www.mono-project.com/Compiling_Mono_VSNET... All required libraries for building mono in Visual Studio are referenced via the MONO_DEPENDENCIES_PREFIX environment variable. Set this variable to a previous installed mono (C:\Mono-1.2.5.2 for example), or to a cygwin environment setup for building mono (D:\cygwin\opt for example). I did verify that g_str_has_prefix is not an exposed method in the dll that is contained in the VS Dependency zip-archive, but it does exist in the 2.0 installed version of libglib. -bill On Mon, Nov 10, 2008 at 1:17 PM, Alexander M. Batishchev [EMAIL PROTECTED] wrote: Hi everybody, I'm trying to compile Mono under VS2008. Configuration 'Debug_eblib' is compiled successfully. But just 'Debug' - is not. Error LNK2019: unresolved external symbol _g_str_has_prefix referenced in function _mono_class_generic_sharing_enabled occurs. In case of 'Debug_eblib' implementation of 'g_str_has_prefix' is contained in eglib.lib which is compiling before libmono, and all works fine. But in case of just 'Debug' implementation is contained in glib-2.0.lib which must be downloaded with VS Dependency zip-archive. Is it possible that glib-2.0.lib doesn't contains proper data? Thanks for any information! === Best regards, Alexander M. Batishchev ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Ximian-mono-list] Mono unit test failures on windows...
Hi, I believe that r118412 fixes https://bugzilla.novell.com/show_bug.cgi?id=443056 at least. -bill ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] compiling mono using vs 2005
I'm trying to build Win32_Release_eglib release. genmdesc and monoburg projects are missing ;..\eglib\src from additional include directories path. Also eglib library is built too late for both those projects. This is due to my only laziness. I did not set up the dependency list correctly for the solution because it was causing linker errors on the non eglib targets. I found the solution and have fixed it. Thanks for trying the VS builds and giving feedback. -bill ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] System.IO.TextReader.Null implementation.
Hi, Attached is a patch to implement the Null field of the TextReader. There is also a test. 2008-11-07 William Holmes [EMAIL PROTECTED] * corlib_test.dll.sources: Add TextReaderTest.cs. * TextReaderTest.cs: Added a test for the Null field of the TextReader. * TextReader.cs : Adding the NullTextReader as a private class to the TestReader class for the Null field of the TestReader. Code is contributed under MIT/X11 license. Thanks -bill TextReaderNull.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] System.Type.FindMembers return type.
Hi, The attached patch changes FindMembers to instantiate the correct type of array to be returned as a MemberInfo []. Basically typeof (object).GetMember (Dummy, MemberTypes.Method, BindingFlags.Public).GetType (); Should be a MethodInfo [] and not a MemberInfo []. I have also added a test for this. 2008-11-06 Bill Holmes [EMAIL PROTECTED] * Type.cs (FindMembers): Changing the instantiated type of the returned MemberInfo array to match the MemberTypes flag passed in argument 1. * TypeTest.cs: TypeGetMemberReturnTypeTest added to check that the instantiated type of the returned MemberInfo array matches the MemberTypes flag passed in. Contributed under MIT/X11 license. thanks -bill FindMembersReturn.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Error in eglib while compiling mono under Windows\VS2008
I am fixing this right now.
On Wed, Nov 5, 2008 at 1:36 PM, Alexander M. Batishchev
[EMAIL PROTECTED] wrote:
Hello everybody,
I'm trying to compile Mono from SVN under VS 2008. Opened mono\msvc\mono.sln
and got error (after successful conversion of course) in eglib:
First of all options Threat warnings as errors is On, could you please say
me what for?
Line 1854 in mono\eglib\src\unicode-data.h:
simple_upper_case_mapping_lowarea_table_count = 8;
instead of
int simple_upper_case_mapping_lowarea_table_count = 8;
And i got broken compilation immediately because of
Warning C4431: missing type specifier - int assumed. Note: C no longer
supports default-int
Warning C4218: nonstandard extension used : must specify at least a storage
class or a type
Ok, add int and go to my general problem.
Lines after 123 in mono\eglib\src\gunicode.c:
gunichar
g_unichar_case (gunichar c, gboolean upper)
{
gint8 i, i2 = 0;
guint32 cp = (guint32) c, v;
for (i = 0; i simple_case_map_ranges_count; i++) {
if (cp simple_case_map_ranges [i].start)
return c;
if (simple_case_map_ranges [i].end = cp)
continue;
if (c 0x1) {
guint16 *tab16 = upper ?
simple_upper_case_mapping_lowarea [i] : simple_lower_case_mapping_lowarea
[i];
v = tab16 [cp - simple_case_map_ranges [i].start];
} else {
i2 = i - (upper ?
simple_upper_case_mapping_lowarea_table_count :
simple_lower_case_mapping_lowarea_table_count);
guint32 *tab32 = upper ?
simple_upper_case_mapping_higharea [i2] : simple_lower_case_mapping_higharea
[i2];
v = tab32 [cp - simple_case_map_ranges [i].start];
}
return v != 0 ? (gunichar) v : c;
}
return c;
}
Error output:
Error C2275: 'guint32' : illegal use of this type as an expression
d:\visual studio 2008\projects\mono\trunk\mono\eglib\src\gunicode.c:139
Error C2065: 'tab32' : undeclared identifier
d:\visual studio 2008\projects\mono\trunk\mono\eglib\src\gunicode.c:139
Error C2065: 'tab32' : undeclared identifier
d:\visual studio 2008\projects\mono\trunk\mono\eglib\src\gunicode.c:140
Error C2109: subscript requires array or pointer type
d:\visual studio 2008\projects\mono\trunk\mono\eglib\src\gunicode.c:140
Error is contained in line 138:
i2 = i - (upper ? simple_upper_case_mapping_lowarea_table_count :
simple_lower_case_mapping_lowarea_table_count);
If remove declaration of the variable from method's head and put it into the
line everything compiles good!
gint8 i2 = i - (upper ? simple_upper_case_mapping_lowarea_table_count :
simple_lower_case_mapping_lowarea_table_count);
Why it could be so?? Is it bug of Microsoft Visual C++ compiler or something
else?
Thanks a lot for tip!
PS. Am I right to write it here or is there a better place to do that?
===
Best regards,
Alexander M. Batishchev
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Error in eglib while compiling mono under Windows\VS2008
Fixed in trunk. r118012
On Wed, Nov 5, 2008 at 1:42 PM, Bill Holmes [EMAIL PROTECTED] wrote:
I am fixing this right now.
On Wed, Nov 5, 2008 at 1:36 PM, Alexander M. Batishchev
[EMAIL PROTECTED] wrote:
Hello everybody,
I'm trying to compile Mono from SVN under VS 2008. Opened mono\msvc\mono.sln
and got error (after successful conversion of course) in eglib:
First of all options Threat warnings as errors is On, could you please say
me what for?
Line 1854 in mono\eglib\src\unicode-data.h:
simple_upper_case_mapping_lowarea_table_count = 8;
instead of
int simple_upper_case_mapping_lowarea_table_count = 8;
And i got broken compilation immediately because of
Warning C4431: missing type specifier - int assumed. Note: C no longer
supports default-int
Warning C4218: nonstandard extension used : must specify at least a storage
class or a type
Ok, add int and go to my general problem.
Lines after 123 in mono\eglib\src\gunicode.c:
gunichar
g_unichar_case (gunichar c, gboolean upper)
{
gint8 i, i2 = 0;
guint32 cp = (guint32) c, v;
for (i = 0; i simple_case_map_ranges_count; i++) {
if (cp simple_case_map_ranges [i].start)
return c;
if (simple_case_map_ranges [i].end = cp)
continue;
if (c 0x1) {
guint16 *tab16 = upper ?
simple_upper_case_mapping_lowarea [i] : simple_lower_case_mapping_lowarea
[i];
v = tab16 [cp - simple_case_map_ranges [i].start];
} else {
i2 = i - (upper ?
simple_upper_case_mapping_lowarea_table_count :
simple_lower_case_mapping_lowarea_table_count);
guint32 *tab32 = upper ?
simple_upper_case_mapping_higharea [i2] : simple_lower_case_mapping_higharea
[i2];
v = tab32 [cp - simple_case_map_ranges [i].start];
}
return v != 0 ? (gunichar) v : c;
}
return c;
}
Error output:
Error C2275: 'guint32' : illegal use of this type as an expression
d:\visual studio 2008\projects\mono\trunk\mono\eglib\src\gunicode.c:139
Error C2065: 'tab32' : undeclared identifier
d:\visual studio 2008\projects\mono\trunk\mono\eglib\src\gunicode.c:139
Error C2065: 'tab32' : undeclared identifier
d:\visual studio 2008\projects\mono\trunk\mono\eglib\src\gunicode.c:140
Error C2109: subscript requires array or pointer type
d:\visual studio 2008\projects\mono\trunk\mono\eglib\src\gunicode.c:140
Error is contained in line 138:
i2 = i - (upper ? simple_upper_case_mapping_lowarea_table_count :
simple_lower_case_mapping_lowarea_table_count);
If remove declaration of the variable from method's head and put it into the
line everything compiles good!
gint8 i2 = i - (upper ? simple_upper_case_mapping_lowarea_table_count :
simple_lower_case_mapping_lowarea_table_count);
Why it could be so?? Is it bug of Microsoft Visual C++ compiler or something
else?
Thanks a lot for tip!
PS. Am I right to write it here or is there a better place to do that?
===
Best regards,
Alexander M. Batishchev
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] VS changes needed for MonoPosixHelper.dll in mono/support.
Can someone please look at this? -bill On Tue, Oct 21, 2008 at 10:18 AM, Bill Holmes [EMAIL PROTECTED] wrote: The attached patch is to add some additional preprocessor to support/map.c. I am starting to add MonoPosixHelper.dll to the VS build for Winx64. I do have some questions about changing configure.in. Where is the right place to add AC_CHECK_HEADERS(dirent.h)? There are AC_CHECK_HEADERS checks for sys/time.h and utime.h already. There does not appear to be a check for unistd.h but #define HAVE_UNISTD_H does appear in config.h. Does a check need to be added? Is it obvious that I know nothing about autogen, autoconf and make? ;) -bill 2008-10-21 Bill Holmes [EMAIL PROTECTED] * configure.in : Adding a auto configure check for dirent.h. * support/Makefile.am : For generation of map.c adding preprocessor checks for sys/time.h, unistd.h, dirent.h and utime.h. * support/map.c : Re-run 'make refresh' to add preprocessor checks for sys/time.h, unistd.h, dirent.h and utime.h. Code is contributed under MIT/X11 license. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] VS changes needed for MonoPosixHelper.dll in mono/support.
The attached patch is to add some additional preprocessor to support/map.c. I am starting to add MonoPosixHelper.dll to the VS build for Winx64. I do have some questions about changing configure.in. Where is the right place to add AC_CHECK_HEADERS(dirent.h)? There are AC_CHECK_HEADERS checks for sys/time.h and utime.h already. There does not appear to be a check for unistd.h but #define HAVE_UNISTD_H does appear in config.h. Does a check need to be added? Is it obvious that I know nothing about autogen, autoconf and make? ;) -bill 2008-10-21 Bill Holmes [EMAIL PROTECTED] * configure.in : Adding a auto configure check for dirent.h. * support/Makefile.am : For generation of map.c adding preprocessor checks for sys/time.h, unistd.h, dirent.h and utime.h. * support/map.c : Re-run 'make refresh' to add preprocessor checks for sys/time.h, unistd.h, dirent.h and utime.h. Code is contributed under MIT/X11 license. support_map.c.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] problems compiling using System.Configuration using Mono 2.0
Hi, Try gmcs instead of mcs. -bill 2008/10/14 mike horsley [EMAIL PROTECTED]: I can use the following on MS: System.Configuration.ConfigurationManager.AppSettings(……..) This requires a reference to System.Configuration. I'm trying to do the same on mono 2.0 (using the VMWARE image) but cant figure out what reference I need to give mcs to get it to compile. I've tried -r:System.Configuration.dll and get the mcs error cannot find metadata file 'System.Configuration.dll whereas if I use -r:System.Configuration.Install.dll (having found the dlls in /user/lib/mono/2.0/) I get the mcs error Error CS0234 the type or namespace 'ConfigurationManager' does not exist in the namespace 'System.Configuration' are you missing an assembly reference? I can use the legacy mode ConfigurationSettings.AppSettings but this then means I have 2 variants of code (one for Windows, one for Linux) Any help appreciated! Mike ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] MonoLoadImage Windows change.
Hello All, I have found a problem loading ms generated COM interop assemblies. This patch fixes the problem. -bill LoadLib_08_09_18.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] System.Diagnostics/Process fix
Hello All, The attached patch fixes some problems I was having with Process.ErrorDataReceived and Process.BeginErrorReadLine. There are actually two fixes here. The most critical is that the fields of ProcessAsyncReader dd not match MonoSocketAsyncResult. The second part removes the extra '\r' on windows when spitting the string. I also need this in the 2.0 branch. -bill Process.cs.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.Diagnostics/Process fix
If it's not abusing of your good will. Please add some comments to Process.cs, Sockets.cs and socket-io.h mentioning this needs to be sync'ed in 3 places. I was thinking the same thing. I will add that. About stripping the '\r', won't that cause problems on unix machines? I will have to check. The quick answer is that I don't think so. I can remove this part of the patch for now as it is not mission critical to me. I simply found it while I was debugging the first problem. To recap. I will add the comments. remove the \r checks commit to the trunk and branch look at the \r problem another day. -bill ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] StringToHGlobalAnsi and Uni
Hello All, The following patch was created from the 2.0 branch. I would like to commit it to the branch as well as the trunk. Basically on Windows we need to allocate the memory using GlobalAlloc for these calls. I have plans to revisit ves_icall_System_Runtime_InteropServices_Marshal_StringToHGlobalAnsi to avoid allocating memory twice. Similar to what was attempted in mono_string_new in object.c. To do this we need to implement some more e-glib methods so we have to live with the double alloc for 2.0. -bill hglobal_08_09_02.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] eglib memory allocation changes
It would be useful to add unit test cases so this behavior is also
enforced in the code. Mind adding those?
I may not understand what you want. I attached a test for what I
think you want.
-bill
#include glib.h
#include test.h
RESULT
test_memory_zero_size_allocations ()
{
gpointer p;
p = g_malloc (0);
if (p)
return FAILED (Calling g_malloc with size zero should return
NULL.);
p = g_malloc0 (0);
if (p)
return FAILED (Calling g_malloc0 with size zero should return
NULL.);
p = g_realloc (NULL, 0);
if (p)
return FAILED (Calling g_realloc with size zero should return
NULL.);
p = g_new (int, 0);
if (p)
return FAILED (Calling g_new with size zero should return
NULL.);
p = g_new0 (int, 0);
if (p)
return FAILED (Calling g_new0 with size zero should return
NULL.);
return OK;
}
static Test memory_tests [] = {
{ zero_size_allocations, test_memory_zero_size_allocations},
{NULL, NULL}
};
DEFINE_TEST_GROUP_INIT(memory_tests_init, memory_tests)
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] eglib memory allocation changes
Hello All, Attached is a patch to change eglib memory allocation methods to return NULL if the size is passed in is zero. If this is approved I would also like to put it into the 2.0 branch. I tracked a bug to load_modules in image.c. In this particular case image-modules was being set to a non-null value when the image-module_count was equal to 0. There is another area of the code later that checks the modules but not he module_count and causes an assert. I could have simply changed this code but after reading the glib documentation I believe that this patch is the right change. Also there may be more critical areas that I have not discovered yet that could hit this problem. Documentation malloc If size is 0, either a null pointer or a unique pointer that can be successfully passed to free() shall be returned. calloc If either nelem or elsize is 0, then either a null pointer or a unique pointer value that can be successfully passed to free() shall be returned. realloc If size is 0, either a null pointer or a unique pointer that can be successfully passed to free() shall be returned. If size is 0 and ptr is not a null pointer, the object pointed to is freed. g_malloc If n_bytes is 0 it returns NULL. g_malloc0 () If n_bytes is 0 it returns NULL. g_realloc () n_bytes may be 0, in which case NULL will be returned and mem will be freed unless it is NULL. thanks -bill g_allocation_08_08_01.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Backport of r108759
Hello All, Does anyone mind if I backport r108759 to the 2-0 branch? The diff for that change is attached. -bill 108759.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Winx64 Linear IR Fixes
Hello All, I have a patch for the trunk that gets WInx64 back to a running state with the new Linear IR code. As Zoltan promised it was mostly relocating some of my previous commits to a new location. If this patch is too large and needs to be split into smaller changes I can do that. As far as I can tell this patch should have no affect on any other platform except Winx64. I am only seeing one regression for Winx64 currently in the trunk. The remoting2 and remotng3 tests are now failing in the trunk and are passing in the 2.0 branch. -bill linearIR_winx64_08_07_28.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Win32 pinvoke3 runtime tests fixes
Hello All,
I am sending an update to this patch since there have been some
discussion since the original posting.
The 2 changes since the previous patch are in mono_arch_emit_epilog.
@@ -4186,6 +4192,11 @@
}
}
+ if (MONO_TYPE_ISSTRUCT (mono_method_signature (cfg-method)-ret)
(cinfo-ret.storage == ArgOnStack) (cfg-vret_addr)) {
+ /* When return structs are passed on the stack the address
needs to
be stored in eax. */
+ x86_mov_reg_membase (code, X86_EAX, cfg-vret_addr-sreg1,
cfg-vret_addr-inst_offset, sizeof (gpointer));
+ }
+
x86_leave (code);
if (CALLCONV_IS_STDCALL (sig)) {
It was brought to my attention on IRC that the address of the return
struct needs to be in the return register for more platforms than just
Win32. I removed the 'if Win32' preprocessor check so that this
occurs on all platforms.
@@ -4177,6 +4177,12 @@
break;
case ArgOnDoubleFpStack:
x86_fld_membase (code, cfg-ret-inst_basereg,
cfg-ret-inst_offset + (quad * sizeof (gpointer)), TRUE);
+#ifdef PLATFORM_WIN32
+ /* Structs that contain only a double are
stored spanning eax and edx. */
+ /* This is needed for calling methods that were
compiled the MSVC
compiler. */
+ x86_mov_reg_membase (code, return_regs[0],
cfg-ret-inst_basereg, cfg-ret-inst_offset, 4);
+ x86_mov_reg_membase (code, return_regs[1],
cfg-ret-inst_basereg, cfg-ret-inst_offset + sizeof (gpointer), 4);
+#endif
break;
case ArgNone:
break;
I found that this is a difference between the way the MSVC and the
Cygwin gcc compiler handle structs with doubles. MS stores the double
across the 2 return registers while gcc uses the float registers. I
am suggesting that for Windows we store the value in both locations as
we can not determine which compiler generated the method that we are
attempting to call.
I would also like to put this change into the branch as well.
-bill
On Thu, Jul 17, 2008 at 7:14 PM, Bill Holmes [EMAIL PROTECTED] wrote:
Hello All,
I did some investigation on Win32 about why the pinvoke3 runtime test
was failing. What I found was a calling convention error in the test,
and two struct marshaling bugs.
For the calling convention problem I simply added a __stdcall
statement in libtest.c to the function pointer declaration that was
missing it.
The two calling convention bugs I was able to handle in the epilog.
See comments in patch for more detail.
The final problem I found was similar to a problem I observed before
when working on Winx64. Zoltan fixed the problem with r104552 so I
decided to take a chance and try that fix out for x86 and the problem
went away.
One last thing to point out is that this test does not even run on
.NET. Does this mean that Mono is better than .Net in this case? ;)
Unhandled Exception: System.Reflection.TargetInvocationException:
Exception has been thrown by the target of an invocation. ---
System.Runtime.InteropServices.MarshalDirectiveException: Method's
type signature is not PInvoke compatible.
at Tests.mono_test_marshal_delegate2(SimpleDelegate2 d)
at Tests.test_0_marshal_struct_delegate()
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle._InvokeMethodFast(Object target,
Object[] arguments, SignatureStruct sig, MethodAttributes
methodAttributes, RuntimeTypeHandletypeOwner)
at System.RuntimeMethodHandle.InvokeMethodFast(Object target,
Object[] arguments, Signature sig, MethodAttributes methodAttributes,
RuntimeTypeHandle typeOwner)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj,
BindingFlags invokeAttr, Binder binder, Object[] parameters,
CultureInfo culture, Boolean skipVisibilityChecks)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj,
BindingFlags invokeAttr, Binder binder, Object[] parameters,
CultureInfo culture)
at TestDriver.RunTests(Type type, String[] args)
at TestDriver.RunTests(Type type)
at Tests.Main()
-bill
pinvoke3_08_07_28.diff
Description: Binary data
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Win32 pinvoke3 runtime tests fixes
Hello Zoltan, This was a link that was shared with me on IRC. From http://www.sco.com/developers/devspecs/abi386-4.pdf A function that returns a structure or union also sets %eax to the value of the original address of the caller's area before it returns. Thus when the caller receives control again, the address of the returned object resides in register %eax and can be used to access the object. Both the calling and the called functions must cooperate to pass the return value successfully: Also, this should only be needed for methods which can be called from native code ( method-wrapper_type == MONO_WRAPPER_NATIVE_TO_MANAGED). I will add this. -bill ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Winx64 float ABI fix
Hello All, The attached patch fixes problems on Winx64 with method calls that have floats and non-float types mixed in the argument list. This patch should only affect Winx64 code. I am asking for approval for the trunk as well as the 2.0 branch. thanks -bill float_x64_08_07_21.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Winx64 struct argument changes
Hello All, The attached patch focuses on fixes needed for calls to manged from native that pass structs by value. Although there are no PLATFORM_WIN32 checks in this patch, it should have no runtime impact on any other platform. This patch only adds implementation to the ArgValuetypeAddrInIReg cases, which only occur when running Winx64. Please let me know if you have any suggestions or if this is good to commit to trunk and the 2.0 branch. thanks -bill ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Winx64 struct argument changes
Thanks Rodrigo! I still need this code considered for the branch. thanks -bill On Mon, Jul 21, 2008 at 7:25 PM, Rodrigo Kumpera [EMAIL PROTECTED] wrote: Hi Bill, You forgot to attach the patch. Anyway, since Zoltan is merging linear-il tomorrow it might be better for you to rebase your patch first. Rodrigo On Mon, Jul 21, 2008 at 8:20 PM, Bill Holmes [EMAIL PROTECTED] wrote: Hello All, The attached patch focuses on fixes needed for calls to manged from native that pass structs by value. Although there are no PLATFORM_WIN32 checks in this patch, it should have no runtime impact on any other platform. This patch only adds implementation to the ArgValuetypeAddrInIReg cases, which only occur when running Winx64. Please let me know if you have any suggestions or if this is good to commit to trunk and the 2.0 branch. thanks -bill ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list struct_08_07_21.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Small Winx64 change.
Hello All, The attached patch fixes the vararg.exe runtime test on Winx64. The MonoTypedRef is not always passed on the stack on Windows. Calling add_valuetype will select the correct operation. -bill MONO_TYPE_TYPEDBYREF.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] String.GetHashCode Discussion.
I have been asked to move this discussion to the e-mail list from IRC. Basically we (my company and I) have new unit tests errors in 2.0 that did not occur at 1.9. The errors were traced to the String.GetHashCode change. I had one of our interns (Mike) research the change and I wanted to share his findings with you. His final document s attached. I can also send the test case Mike used to generate his data. I believe it is too large to send to all of your inboxes. http://docs.google.com/Doc?id=dhnnms3p_3fpmfq8dm (1:28:15 PM) holmes: Have there been any discussions about r106887 which was a change to String.GetHashCode? (1:31:54 PM) holmes: This change is causing some of our tests to fail. I will admit that our tests are relying on the sting hash code a bit too much. However after some investigation I am wondering if the new algorithm is generating a unique enough result. (I say that as respectfully as I can.) (1:34:33 PM) holmes: We conducted a short test where 58000 English string were tested and the new code only results in 60% unique results compared to the previous code's performance of 100% (1:38:36 PM) holmes: We have found the current algorithm only considers the last ~6 characters of a string, which may be the problem. That is the last thing I will say here I promise. (1:42:21 PM) kumpera: marek: how have you tested the distribution of your new string hashing algorithm? (1:42:54 PM) marek: kumpera: I used english dictionary (1:43:57 PM) marek: holmes: how big is your dictionary? (1:45:05 PM) holmes: marek: 58110 (1:46:12 PM) holmes: I think the real problem is not that a word hashes unique enough as a sentence producing a unique result. (1:46:56 PM) holmes: the last 6 characters define the whole algorithm. (or at least I think so) (1:56:50 PM) lupus: it's likely better to revert the change, string hashing is also supposed to be synced with the implementation in C in the runtime anyway -bill ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Thread.Interrupt bug.
Hello All, I have a small threading patch that needs reviewed. Also contained in this patch are two unit tests that the changes to threads.c are meant to address. -bill threadInterrupt.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Winx64 stack cleanup for calls
Hello All, Attached (cleanStack_08_07_07.diff) is a small patch that should be specific to Winx64 only that will cleanup the stack after each call emitted from mono_arch_output_basic_block. The calling convention on Winx64 requires that the caller always cleans the stack. (At least as far as I am aware.) Also I have some tests (unitTests_404729.diff ) that tests bug #404729 on Winx64. -bill cleanStack_08_07_07.diff Description: Binary data unitTests_404729.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Winx64 stack cleanup for calls
Zoltan, Agreed. I have attached an update. -bill On Mon, Jul 7, 2008 at 3:03 PM, Zoltan Varga [EMAIL PROTECTED] wrote: Hi, It might be easier to define IS_STDCALL as FALSE on windows, since afaik there is no stdcall calling convention on winx64. Zoltan 2008/7/7 Bill Holmes [EMAIL PROTECTED]: Hello All, Attached (cleanStack_08_07_07.diff) is a small patch that should be specific to Winx64 only that will cleanup the stack after each call emitted from mono_arch_output_basic_block. The calling convention on Winx64 requires that the caller always cleans the stack. (At least as far as I am aware.) Also I have some tests (unitTests_404729.diff ) that tests bug #404729 on Winx64. -bill ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list cleanStack_08_07_07.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Exceptions on Winx64
Hello All, I have made another change to patch. The difference from the last is that the unwindinfo pointer has been moved from MonoCompile to MonoCompileArch struct. -bill On Tue, Jun 24, 2008 at 2:59 PM, Bill Holmes [EMAIL PROTECTED] wrote: I have updated the patch with Robert's suggestion. -bill On Sat, Jun 14, 2008 at 6:26 AM, Robert Jordan [EMAIL PROTECTED] wrote: Bill Holmes wrote: Hello All, After a week of digging though awful online documentation I have finally got a patch for the exception unit tests in the runtime for Winx64. The attached patch appends the information to the code block for a method using structures that MS SEH understands. There is also a small stack alignment fix n this patch as well. For information on the unwind_info/code structs see. http://msdn.microsoft.com/en-us/library/ms794374.aspx http://msdn.microsoft.com/en-us/library/ms794567.aspx Suggestions? OK to commit? In mini.c, the local `unwindlen' remains uninitialized for !WIN64 and !MONO_ARCH_HAVE_UNWIND_TABLE. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list exceptoins_08_07_07.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] What is the status of the Windows x64 port?
Hello, Jonathan has summarized my efforts correctly. My main focus has been to fix the tests under mono/tests. I have not attemped to run any other tests but I was thinking about running the mscorlib tests next. Given the tentative release schedule from Miguel and the rate problems are being addressed we will not be done with the x64 port at the branch (July 14.) I have not spoke with anyone else on the team about if work will be allowed to continue in the branch for the 2.0 release. -bill On Mon, Jun 30, 2008 at 2:37 PM, Jonathan Chambers [EMAIL PROTECTED] wrote: Hello, I'll let Bill Holmes give more details, as he has been working on finishing the port. At this point, I believe the regressions tests on Win64 are only slightly worse than on Win32 (maybe 5-10 more tests failing, IIRC). I don't believe a full bootstrap has been attempted with mcs yet. The biggest problem for automated build/release is integrating into the current cygwin based mono build process. This may only be the biggest problem as I/Bill have little Makefile/autotools experience. I started working on producing a make target for the mono runtime to be built with MSVC and using the output for the full build, but have been busy with a few other things at this point. Thanks, Jonathan 2008/6/30 Kornél Pál [EMAIL PROTECTED]: Hi, The fact that I was able to run mixed-mode assemblies on Windows x64 makes me believe that there hase been a quite impressive progress in implementing support for Windows x64. Congratulations and thank you! Could someone woring on this let us know the actual status and whether it will be a supported platform in Mono 2.0? Thanks. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Exceptions on Winx64
I have updated the patch with Robert's suggestion. -bill On Sat, Jun 14, 2008 at 6:26 AM, Robert Jordan [EMAIL PROTECTED] wrote: Bill Holmes wrote: Hello All, After a week of digging though awful online documentation I have finally got a patch for the exception unit tests in the runtime for Winx64. The attached patch appends the information to the code block for a method using structures that MS SEH understands. There is also a small stack alignment fix n this patch as well. For information on the unwind_info/code structs see. http://msdn.microsoft.com/en-us/library/ms794374.aspx http://msdn.microsoft.com/en-us/library/ms794567.aspx Suggestions? OK to commit? In mini.c, the local `unwindlen' remains uninitialized for !WIN64 and !MONO_ARCH_HAVE_UNWIND_TABLE. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list exceptoins_08_06_24.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Exceptions on Winx64
Hello All, After a week of digging though awful online documentation I have finally got a patch for the exception unit tests in the runtime for Winx64. The attached patch appends the information to the code block for a method using structures that MS SEH understands. There is also a small stack alignment fix n this patch as well. For information on the unwind_info/code structs see. http://msdn.microsoft.com/en-us/library/ms794374.aspx http://msdn.microsoft.com/en-us/library/ms794567.aspx Suggestions? OK to commit? -bill exceptoins_08_06_13.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Marshaling structs on Winx64
I have been doing more work with passing arguments to native calls on Winx64. The attached patch handles the case of an argument that is a struct that is not able to be passed in a register. http://msdn.microsoft.com/en-us/library/ms235286(VS.80).aspx I spoke to some of you about this on IRC. The summary of this solution is that when one of these structs are identified a local variable is created and the argument is copied to that local variable. Then the local variable is passed by reference (address of the variable) either in a register if available or on the stack. I have added more unit tests for this as well as cleaned up the tests some to make the code shorter. I still believe that there is a problem with native code calling managed. I will be looking into that soon. OK to commit? Suggestions? What do I not understand? ;) fyi. This week I have been looking into SEH on Winx64. I am working on a patch to add unwind data for each method to register with the Winx64 function table. -bill struct_08_06_11.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] MSVC implementation of my_g_bit_nth_msf
The attached patch fixes the compilation errors in MSVC with the eglib targets. -bill my_g_bit_nth_msf.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Marshaling structs on Winx64
The attached code is some of the fixes needed for marshaling structs on Winx64. In mini-amd64 two things have been fixed. 1) Structs containing floats are passed in the integer registers, not the float registers. 2) Only structs that are 1,2,4,or 8 bytes will be copied into a register. All others are pushed at the beginning of the stack (depending on your point of reference) and the address of that stack location is stored in the argument register. I still am struggling to figure out how to fix the case where the struct will not fit into the register because of the criteria listed above. What needs to happen is that the struct is copied onto the stack and the address of that location is stored in an argument register. Any suggestion of how to do this or something that I should be reading would be appreciated. I have also attached a new set of unit tests that represents the code I am using to debug some of these issues. I have disabled the Test_In_Args_Value_On_Stack_ADDR_In_RCX portion of the test because of the problem mentioned above. More tests are needed for return values as well as calling managed code from native. I will be adding theses soon. I have encountered another problem that I have decided to ignore for the time being. Originally the C# portion of my tests contained char types instead of byte types. This worked fine when run under .net. However mono assumes 2 bytes for the char. Is this just another Winx64 bug that needs addressed? As always suggestions are not only welcome but encouraged. I am defiantly a fish out of water in this code. OK to commit? thanks -bill winx64_struct_08_06_04.diff Description: Binary data winx64_struct_tests_08_06_04.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Update to Winx64 stack patch
I have updated this patch based off a discussion with Zoltan on IRC. -bill On Wed, May 28, 2008 at 11:00 AM, Bill Holmes [EMAIL PROTECTED] wrote: I have a small patch that seems to have fix a bunch of issues with the unit tests under mono/tests for Windows x64. Please review and let me know if I am headed in the right direction. I am still a bit lost in this code but I fell that I am learning. ;) There are still a small number of tests failing that I am looking at. The first set I will be tackling are the ones that call into libtest.so (or dll.) I will be adding a build project to the VS solution for this dll next. I will also be doing some cleanup in the VS solution and projects to make the output directories more uniform. This is in preparation for adding a vsbuild target to the current cygwin make process that Jonathan and Miguel discussed in an earlier thread. -bill mini-amd64_x64_stack_align.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Fixes for libtest.c and VS
Last patch for the week. I promise. These changes are to make libtest.c ready to be compiled in Visual Studio. I will be sending the patch for the new VS project and update to the solution. The STDCALL statements had to be moved and I added declspec(dllexport) statements to all methods. At least I hope I got them all. Sorry no ChangeLog, I will add it Monday. It is late and my wife is calling again. Thanks all and have a good weekend. -bill libtest_c_forVS.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] UI Developer Needed
Hello All, First of all I apologize to those of you who may view this as spam. I work for ANSYS Inc. and we have full time positions available that may be of interest to some of you in this group. The particular position that I list below works closely with my group and we are hoping to fill it as soon as possible. If interested you can apply directly at our website. http://careers.vurvexpress.com/jobprofile.cfm?szWID=10336szCID=46514szSiteID=1467szOrderID=494232szStart=1 If that link does not work properly you can access it and others through http://www.ansys.com/corporate/careers.asp It is listed under North America and the Job ID is 1653 Although the job is listed a Canonsbrug there may be an opportunity to work at some of our other sites. Feel free to send me any questions. Thanks -bill Senior Software Developer Job Description Summary The Senior Software Developer will work on the UI framework for the Next Generation Platform. The primary technologies the candidate would be working with are C#, C++, Qt, Windows Forms, targeting Windows and Linux. Primary responsibilities would include defining and implementing the core subsystems and architecture in a new, cross-platform application framework. The ideal candidate would have significant experience with an established GUI toolkit such as Qt, Java Swing, Windows Forms, etc., and experience in the design of large object oriented interactive software systems. Minimum Requirements: BS in Computer Science / Software Engineering or the equivalent Significant experience in object oriented design, and implementation in C++ / C# The ability to work with a geographically distributed team Excellent written and verbal communication skills The ability to mentor less experienced developers ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compiling Mono from Source Code
Paramesh, The following link is what I use. I have found it extremely useful. http://shana.iidbbs.com/en/mono_cygwin_tutorial.html ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] ucs4 and utf16 conversion functions for eglib
=== --- mono/eglib/ChangeLog (revision 100107) +++ mono/eglib/ChangeLog (working copy) @@ -1,5 +1,15 @@ -2007-03-19 Bill Holmes [EMAIL PROTECTED] +2008-04-08 Bill Holmes [EMAIL PROTECTED] + * src/glib.h : Adding declarations for g_ucs4_to_utf16 and g_utf16_to_ucs4. + + * src/gutf8.c : Adding implementation for g_ucs4_to_utf16 and g_utf16_to_ucs4. + + * test/utf8.c Adding tests for g_ucs4_to_utf16 and g_utf16_to_ucs4. + + Contributed under MIT/X11 license. + +2008-03-19 Bill Holmes [EMAIL PROTECTED] + * src/gpath.c (g_path_is_absolute) : Adding a case for '/' on Windows. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] [Windows] MSVC mono build fixes
Theses changes are needed for building the mono runtime with Visual Studio. Please review and let me know if it is OK to commit. The diff file has Windows end of lines. thanks -bill msvcBuildFixes_2008_03_10.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] [Windows] MSVC mono build fixes
Thanks Zoltan. Committed r97889 -bill On Mon, Mar 10, 2008 at 1:34 PM, Zoltan Varga [EMAIL PROTECTED] wrote: Hi, This is ok to check in. Zoltan 2008/3/10 Bill Holmes [EMAIL PROTECTED]: Theses changes are needed for building the mono runtime with Visual Studio. Please review and let me know if it is OK to commit. The diff file has Windows end of lines. thanks -bill ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] [Windows] eglib changes for Windows.
Please review the attached diff file and let me know if it is OK to commit. It is fixes for a couple of build errors, and bugs with eglib on Windows. I am not very confident of my implementation of g_get_charset but it does work for what I need it to do. Any suggestions on how to make this right is appreciated. -bill eglib_Windows_2008_03_10.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] [Windows] eglib changes for Windows.
Sorry All. I have to send this again because I found a bug in my refactoring about 30 seconds after I hit send. -bill On Mon, Mar 10, 2008 at 6:52 PM, Bill Holmes [EMAIL PROTECTED] wrote: Please review the attached diff file and let me know if it is OK to commit. It is fixes for a couple of build errors, and bugs with eglib on Windows. I am not very confident of my implementation of g_get_charset but it does work for what I need it to do. Any suggestions on how to make this right is appreciated. -bill eglib_Windows_2008_03_10_2.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] GC Question.
I did not want to file a bug on this just yet as it may be related to
https://bugzilla.novell.com/show_bug.cgi?id=319247 . Or it just may
be a bad test case.
The following code under MS.net displays
_activeCount = 1
_activeCount = 0
Where mono displays
_activeCount = 1
_activeCount = 1
Should I file a bug report on this?
thanks
-bill
using System;
public class Test
{
private static int _activeCount = 0;
Test ()
{
System.Threading.Interlocked.Increment (ref _activeCount);
}
~Test ()
{
// are we allowed to do this in a finaliser?
System.Threading.Interlocked.Decrement (ref _activeCount);
}
[STAThread]
static void Main (string[] args)
{
if (args.Length == 0)
{
Test test = new Test ();
Console.WriteLine (_activeCount = + _activeCount);
GC.KeepAlive (test);
test = null;
}
GC.Collect ();
GC.WaitForPendingFinalizers ();
Console.WriteLine (_activeCount = + _activeCount);
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Bug in MCS or Mono Runtime 1.2.6
I have been able to reproduce this with the 1.2.6_4 install on
Windows. I was able to compile the library and exe using csc and it
does run fine on Mono. Also I have compiled using gmcs and run with
the MS runtime and I get the following exception.
Unhandled Exception: System.InvalidProgramException: Common Language
Runtime detected an invalid program.
at Sample.MainWindow..ctor()
at Sample.MainClass.Main(String[] args)
It appears that this is a mcs bug.
After further investigation I have a smaller sample that shows the
bug. It occurs when you have a unconditional return statement before
a local variable declaration that is assigned inside an anonymous
delegate. If you move the variable declaration above the return
statement the bug goes away.
I have also verified that this still occurs at the trunk version.
Mono JIT compiler version 1.2.6 (/trunk/ r92000)
I would suggest filing a compiler bug for this.
public class Test
{
static public void TestFunc ()
{
return;
string testStr;
System.AppDomain.CurrentDomain.AssemblyLoad += delegate
(object Sender, System.AssemblyLoadEventArgs e)
{
testStr = sss;
};
}
public static void Main (string[] args)
{
TestFunc ();
}
}
On Dec 27, 2007 6:24 PM, Laurent Debacker [EMAIL PROTECTED] wrote:
Hi,
I'm developing a Gtk# application using MonoDevelop Beta 2 and Mono 1.2.6.
However Mono could not execute the compiled assembly. The error provided is
the following one:
Unhandled Exception: System.InvalidProgramException: Invalid IL code in
Sample.MainWindow:.ctor (): IL_007e: nop
at Sample.MainClass.Main (System.String[] args) [0xf] in
/home/gizmo/Sample/Main.cs:12
I have attached both the generated assembly, and the tarball generated by
MonoDevelop.
For your conveniance, I have copy-pasted the IL code as dissasembled by
Reflector of Sample.MainWindow:.ctor () is:
.method public hidebysig specialname
rtspecialname instance void
.ctor() cil managed
{
.maxstack 12
.locals init (
[0] class
Sample.MainWindow/c__CompilerGenerated0
generated,
[1] class [
gtk-sharp]Gtk.VBox box,
[2
] class [Ribbons]
Ribbons.Button button,
[3] class [
gtk-sharp]Gtk.Menu menu,
[4
] class [
gtk-sharp]Gtk.MenuItem item,
[
5] class [
gtk-sharp]Gtk.MenuItem item2,
[
6] class [Ribbons]
Ribbons.Button button2,
[7] class [
Ribbons]Ribbons.Button button3,
[8]
class [gtk-sharp
]Gtk.Menu menu2,
[9]
class [gtk-sharp
]Gtk.MenuItem item3,
[10
] class [Ribbons]
Ribbons.ToolPack pack,
[11] class [
Ribbons]Ribbons.ToolPack pack2,
[12
] class [Ribbons]
Ribbons.ToolPack pack3,
[13] class [
gtk-sharp]Gtk.ComboBox box2,
[
14] class Sample.MainWindow/
c__CompilerGenerated1 generated2,
[15] class [
gtk-sharp]Gtk.HBox box3,
[16
] class [
gtk-sharp]Gtk.HBox box4,
[17
] class [
gtk-sharp]Gtk.HBox box5,
[18
] class [Ribbons]
Ribbons.RibbonGroup group,
[19] class [
gtk-sharp]Gtk.HBox box6,
[20
] class [
gtk-sharp]Gtk.Label label,
[
21] class [
gtk-sharp]Gtk.Label label2,
[
22] class [Ribbons]
Ribbons.Button button4,
[23] class
Sample.MainWindow/c__CompilerGenerated4
generated3,
[24] class [
gtk-sharp]Gtk.MenuItem item4,
[
25] class [
gtk-sharp]Gtk.TextView view)
L_:
nop
L_0001: ldc.i4 1
L_0006:
pop
L_0007: nop
L_0008:
newobj instance void
Sample.MainWindow/c__CompilerGenerated0
::.ctor()
L_000d:
stloc.0
L_000e: ldarg.0
L_000f:
ldc.i4.0
L_0010: call instance
void [Ribbons]
Ribbons.SyntheticWindow::.ctor(valuetype
[gtk-sharp]
Gtk.WindowType)
L_0015: ldarg.0
L_0016:
ldc.i4 0x304
L_001b: call instance
void [gtk-sharp]
Gtk.Widget::AddEvents(
int32)
L_0020: ldarg.0
L_0021:
ldstr Hello World
L_0026:
newobj instance void [
Ribbons]Ribbons.Button::
.ctor(string)
L_002b:
call instance void [
gtk-sharp]Gtk.Container::
Add(class [
gtk-sharp]Gtk.Widget)
L_0030:
ldarg.0
L_0031: ldc.i4 200
L_0036:
ldc.i4 200
L_003b: call instance
void [gtk-sharp]
Gtk.Window::Resize(
int32, int32)
L_0040:
ldarg.0
L_0041: call instance
void [gtk-sharp]
Gtk.Widget::ShowAll()
L_0046:
ret
L_0047: nop
L_0048:
ldc.i4 2
L_004d: pop
L_004e:
nop
L_004f: newobj instance
void
Sample.MainWindow/c__CompilerGenerated1
::.ctor()
L_0054:
stloc.s generated2
L_0056: ldloc.s generated2
L_0058: ldloc.0
L_0059:
stfld class Sample.MainWindow/
c__CompilerGenerated0 Sample.MainWindow/
c__CompilerGenerated1::
2:scope1
L_005e: nop
L_005f:
ldc.i4 3
L_0064: pop
L_0065:
nop
L_0066: newobj instance
void
Sample.MainWindow/c__CompilerGenerated4
::.ctor()
L_006b:
stloc.s generated3
L_006d: ldloc.s generated3
L_006f: ldloc.s generated2
L_0071:
stfld class Sample.MainWindow/
c__CompilerGenerated1 Sample.MainWindow/
c__CompilerGenerated4::
3:scope2
L_0076: ldloc.s generated3
L_0078:
ldloc.0
L_0079: stfld class
Re: [Mono-dev] [PATCH] Marshaling booleans as U1
On 10/18/07, Paolo Molaro [EMAIL PROTECTED] wrote:
You need to also add a test case to the test suite to exercise the new
code.
Here are the tests for my previous commit. OK to commit?
-bill
Index: mono/mono/tests/pinvoke2.cs
===
--- mono/mono/tests/pinvoke2.cs (revision 87787)
+++ mono/mono/tests/pinvoke2.cs (working copy)
@@ -157,6 +157,24 @@
[DllImport (libtest, EntryPoint=mono_test_marshal_bool_byref)]
public static extern int mono_test_marshal_bool_byref (int a, ref bool b, int c);
+ [DllImport (libtest, EntryPoint=mono_test_marshal_bool_in_as_I1_U1)]
+ public static extern int mono_test_marshal_bool_in_as_I1 ([MarshalAs (UnmanagedType.I1)] bool bTrue, [MarshalAs (UnmanagedType.I1)] bool bFalse);
+
+ [DllImport (libtest, EntryPoint=mono_test_marshal_bool_in_as_I1_U1)]
+ public static extern int mono_test_marshal_bool_in_as_U1 ([MarshalAs (UnmanagedType.U1)] bool bTrue, [MarshalAs (UnmanagedType.U1)] bool bFalse);
+
+ [DllImport (libtest, EntryPoint=mono_test_marshal_bool_out_as_I1_U1)]
+ public static extern int mono_test_marshal_bool_out_as_I1 ([MarshalAs (UnmanagedType.I1)] out bool bTrue, [MarshalAs (UnmanagedType.I1)] out bool bFalse);
+
+ [DllImport (libtest, EntryPoint=mono_test_marshal_bool_out_as_I1_U1)]
+ public static extern int mono_test_marshal_bool_out_as_U1 ([MarshalAs (UnmanagedType.U1)] out bool bTrue, [MarshalAs (UnmanagedType.U1)] out bool bFalse);
+
+ [DllImport (libtest, EntryPoint=mono_test_marshal_bool_ref_as_I1_U1)]
+ public static extern int mono_test_marshal_bool_ref_as_I1 ([MarshalAs (UnmanagedType.I1)] ref bool bTrue, [MarshalAs (UnmanagedType.I1)] ref bool bFalse);
+
+ [DllImport (libtest, EntryPoint=mono_test_marshal_bool_ref_as_I1_U1)]
+ public static extern int mono_test_marshal_bool_ref_as_U1 ([MarshalAs (UnmanagedType.U1)] ref bool bTrue, [MarshalAs (UnmanagedType.U1)] ref bool bFalse);
+
[DllImport (libtest, EntryPoint=mono_test_marshal_array)]
public static extern int mono_test_marshal_array (int [] a1);
@@ -619,6 +637,62 @@
return 0;
}
+ public static int test_0_marshal_bool_as_I1 () {
+
+ int ret;
+ bool bTrue, bFalse;
+ if ((ret = mono_test_marshal_bool_in_as_I1 (true, false)) != 0)
+ return ret;
+
+ if ((ret = mono_test_marshal_bool_out_as_I1 (out bTrue, out bFalse)) != 0)
+ return ret;
+
+ if(!bTrue)
+ return 10;
+
+ if(bFalse)
+ return 11;
+
+ if ((ret = mono_test_marshal_bool_ref_as_I1 (ref bTrue, ref bFalse)) != 0)
+ return ret;
+
+ if(bTrue)
+ return 12;
+
+ if(!bFalse)
+ return 13;
+
+ return 0;
+ }
+
+ public static int test_0_marshal_bool_as_U1 () {
+
+ int ret;
+ bool bTrue, bFalse;
+ if ((ret = mono_test_marshal_bool_in_as_U1 (true, false)) != 0)
+ return ret;
+
+ if ((ret = mono_test_marshal_bool_out_as_U1 (out bTrue, out bFalse)) != 0)
+ return ret;
+
+ if(!bTrue)
+ return 10;
+
+ if(bFalse)
+ return 11;
+
+ if ((ret = mono_test_marshal_bool_ref_as_U1 (ref bTrue, ref bFalse)) != 0)
+ return ret;
+
+ if(bTrue)
+ return 12;
+
+ if(!bFalse)
+ return 13;
+
+ return 0;
+ }
+
public static int test_0_return_vtype () {
SimpleStruct ss = mono_test_return_vtype (new IntPtr (5));
Index: mono/mono/tests/ChangeLog
===
--- mono/mono/tests/ChangeLog (revision 87787)
+++ mono/mono/tests/ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2007-10-18 William Holmes [EMAIL PROTECTED]
+
+ * pinvoke2.cs, libtest.c Adding test cases for marshaling
+ booleans as I1 and U1. Tests commit r87725.
+
+ Code is contributed under MIT/X11 license.
+
2007-10-17 Mark Probst [EMAIL PROTECTED]
* bug-331798-tb.2.cs: added for Rodrigo
Index: mono/mono/tests/libtest.c
===
--- mono/mono/tests/libtest.c (revision 87787)
+++ mono/mono/tests/libtest.c (working copy)
@@ -252,6 +252,45 @@
return res;
}
+STDCALL int
+mono_test_marshal_bool_in_as_I1_U1 (char bTrue, char bFalse)
+{
+ if (!bTrue)
+return 1;
+ if (bFalse)
+return 2;
+return 0;
+}
+
+STDCALL int
+mono_test_marshal_bool_out_as_I1_U1 (char* bTrue, char* bFalse)
+{
+if (!bTrue || !bFalse)
+ return 3;
+
+ *bTrue = 1;
+ *bFalse = 0;
+
+ return 0;
+}
+
+STDCALL int
+mono_test_marshal_bool_ref_as_I1_U1 (char* bTrue, char* bFalse)
+{
+ if (!bTrue || !bFalse)
+return 4;
+
+ if (!(*bTrue))
+return 5;
+if (*bFalse)
+return 6;
+
+ *bFalse = 1;
+*bTrue = 0;
+
+ return 0;
+}
+
STDCALL int
mono_test_marshal_array (int *a1)
{
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Marshaling booleans as U1
I ran across some code in my app that marshaled boolean types as U1
and was receiving a g_warning from the mono runtime. marshalling
bool as native type %x is currently not supported
Changing my code to I1 is easy enough but I wonder if U1 should be
supported. This patch does that.
I had to look at two different sites on msdn to determine if it should
be supported, and it appears that it is.
http://msdn2.microsoft.com/en-us/library/system.runtime.interopservices.unmanagedtype.aspx
http://msdn2.microsoft.com/en-us/library/t2t3725f(VS.80).aspx
Collectively they state that...
I1 : A 1-byte signed integer. You can use this member to transform a
Boolean value into a 1-byte, C-style bool (true = 1, false = 0).
and
U1 : 1-byte integer value where the value 1 represents TRUE and 0
represents FALSE.
And for my own curiosity of how things work my question is; without
this patch a boolean marshaled as U1 will go to the default case and
marshal a 32 bit integer. Will this mess up the arguments passed to
the C function call because the size being pushed is bigger than the C
function expects?
thanks
-bill
Index: ChangeLog
===
--- ChangeLog (revision 87662)
+++ ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2007-10-17 William Holmes [EMAIL PROTECTED]
+
+*marshal.c: Adding a case to marshal booleans to U1
+
+Code is contributed under MIT/X11 license.
+
2007-10-16 Zoltan Varga [EMAIL PROTECTED]
* icall.c (ves_icall_System_Reflection_Assembly_InternalGetType): Throw an
Index: marshal.c
===
--- marshal.c (revision 87662)
+++ marshal.c (working copy)
@@ -8201,6 +8201,7 @@
} else {
switch (spec-native) {
case MONO_NATIVE_I1:
+ case MONO_NATIVE_U1:
local_type = mono_defaults.byte_class-byval_arg;
break;
case MONO_NATIVE_VARIANTBOOL:
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH]System.IO.File.Replace
goto removed
short write case fixed
function definition formatting fixed
thanks
-bill
Index: mono/mono/metadata/file-io.c
===
--- mono/mono/metadata/file-io.c (revision 84466)
+++ mono/mono/metadata/file-io.c (working copy)
@@ -10,6 +10,11 @@
*/
#include config.h
+
+#ifdef PLATFORM_WIN32
+#define _WIN32_WINNT 0x0500
+#endif
+
#include glib.h
#include string.h
#include errno.h
@@ -384,6 +389,36 @@
}
MonoBoolean
+ves_icall_System_IO_MonoIO_ReplaceFile (MonoString *sourceFileName, MonoString *destinationFileName,
+ MonoString *destinationBackupFileName, MonoBoolean ignoreMetadataErrors,
+ gint32 *error)
+{
+ gboolean ret;
+ gunichar2 *utf16_sourceFileName = NULL, *utf16_destinationFileName = NULL, *utf16_destinationBackupFileName = NULL;
+ guint32 replaceFlags = REPLACEFILE_WRITE_THROUGH;
+
+ MONO_ARCH_SAVE_REGS;
+
+ if (sourceFileName)
+ utf16_sourceFileName = mono_string_chars (sourceFileName);
+ if (destinationFileName)
+ utf16_destinationFileName = mono_string_chars (destinationFileName);
+ if (destinationBackupFileName)
+ utf16_destinationBackupFileName = mono_string_chars (destinationBackupFileName);
+
+ *error = ERROR_SUCCESS;
+ if (ignoreMetadataErrors)
+ replaceFlags |= REPLACEFILE_IGNORE_MERGE_ERRORS;
+
+ ret = ReplaceFile (utf16_destinationFileName, utf16_sourceFileName, utf16_destinationBackupFileName,
+ replaceFlags, NULL, NULL);
+ if (ret == FALSE)
+ *error = GetLastError ();
+
+ return ret;
+}
+
+MonoBoolean
ves_icall_System_IO_MonoIO_CopyFile (MonoString *path, MonoString *dest,
MonoBoolean overwrite, gint32 *error)
{
Index: mono/mono/metadata/file-io.h
===
--- mono/mono/metadata/file-io.h (revision 84466)
+++ mono/mono/metadata/file-io.h (working copy)
@@ -230,6 +230,11 @@
extern void ves_icall_System_IO_MonoIO_Unlock (HANDLE handle, gint64 position,
gint64 length, gint32 *error) MONO_INTERNAL;
+extern MonoBoolean
+ves_icall_System_IO_MonoIO_ReplaceFile (MonoString *sourceFileName, MonoString *destinationFileName,
+ MonoString *destinationBackupFileName, MonoBoolean ignoreMetadataErrors,
+ gint32 *error) MONO_INTERNAL;
+
G_END_DECLS
#endif /* _MONO_METADATA_FILEIO_H_ */
Index: mono/mono/metadata/icall-def.h
===
--- mono/mono/metadata/icall-def.h (revision 84466)
+++ mono/mono/metadata/icall-def.h (working copy)
@@ -271,6 +271,7 @@
ICALL(MONOIO_16, Open(string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare,System.IO.FileOptions,System.IO.MonoIOError), ves_icall_System_IO_MonoIO_Open)
ICALL(MONOIO_17, Read(intptr,byte[],int,int,System.IO.MonoIOError), ves_icall_System_IO_MonoIO_Read)
ICALL(MONOIO_18, RemoveDirectory(string,System.IO.MonoIOError), ves_icall_System_IO_MonoIO_RemoveDirectory)
+ICALL(MONOIO_18M, ReplaceFile(string,string,string,bool,System.IO.MonoIOError), ves_icall_System_IO_MonoIO_ReplaceFile)
ICALL(MONOIO_19, Seek(intptr,long,System.IO.SeekOrigin,System.IO.MonoIOError), ves_icall_System_IO_MonoIO_Seek)
ICALL(MONOIO_20, SetCurrentDirectory(string,System.IO.MonoIOError), ves_icall_System_IO_MonoIO_SetCurrentDirectory)
ICALL(MONOIO_21, SetFileAttributes(string,System.IO.FileAttributes,System.IO.MonoIOError), ves_icall_System_IO_MonoIO_SetFileAttributes)
Index: mono/mono/io-layer/io.c
===
--- mono/mono/io-layer/io.c (revision 84466)
+++ mono/mono/io-layer/io.c (working copy)
@@ -1835,6 +1835,56 @@
return(ret);
}
+gboolean
+write_file (int src_fd, int dest_fd, struct stat *st_src, gboolean report_errors)
+{
+ int remain, n;
+ char *buf, *wbuf;
+ int buf_size = st_src-st_blksize;
+
+ buf_size = buf_size 8192 ? 8192 : (buf_size 65536 ? 65536 : buf_size);
+ buf = (char *) malloc (buf_size);
+
+ for (;;) {
+ remain = read (src_fd, buf, buf_size);
+ if (remain 0) {
+ if (errno == EINTR !_wapi_thread_cur_apc_pending ())
+continue;
+
+ if (report_errors)
+_wapi_set_last_error_from_errno ();
+
+ free (buf);
+ return FALSE;
+ }
+ if (remain == 0) {
+ break;
+ }
+
+ wbuf = buf;
+ while (remain 0) {
+ if ((n = write (dest_fd, wbuf, remain)) 0) {
+if (errno == EINTR !_wapi_thread_cur_apc_pending ())
+ continue;
+
+if (report_errors)
+ _wapi_set_last_error_from_errno ();
+#ifdef DEBUG
+g_message (%s: write failed., __func__);
+#endif
+free (buf);
+return FALSE;
+ }
+
+ remain -= n;
+ wbuf += n;
+ }
+ }
+
+ free (buf);
+ return TRUE ;
+}
+
/**
* CopyFile:
* @name: a pointer to a NULL-terminated unicode string, that names
@@ -1852,10 +1902,8 @@
{
gchar *utf8_src, *utf8_dest;
int src_fd, dest_fd;
- int buf_size;
- char *buf;
- int remain, n;
struct stat st;
+ gboolean ret = TRUE;
if(name==NULL) {
#ifdef DEBUG
@@ -1945,63 +1993,107 @@
g_free (utf8_src);
g_free
Re: [Mono-dev] [PATCH]System.IO.File.Replace
All,
Here is an updated version of my patch. I apologize in advance if my
attachment is a binary blob again. I am not quite sure what that
meant or what I should do about it. This time I am sending the mail
from SUSE so maybe that will help.
I have applied the changes mentioned by Rodrigo and Paolo including
-removed alloca.
-adding gotos to avoid duplicate cleanup code.
-fixed numbering oversight in icall-def
-formatted the code to follow the coding guidelines. (including the
return statements)
-cleaned up my white space mess.
Round 2. What did I miss this time? ;)
Thanks so much for you comments.
-bill
Index: mono/mono/metadata/file-io.c
===
--- mono/mono/metadata/file-io.c (revision 84326)
+++ mono/mono/metadata/file-io.c (working copy)
@@ -10,6 +10,11 @@
*/
#include config.h
+
+#ifdef PLATFORM_WIN32
+#define _WIN32_WINNT 0x0500
+#endif
+
#include glib.h
#include string.h
#include errno.h
@@ -384,6 +389,36 @@
}
MonoBoolean
+ves_icall_System_IO_MonoIO_ReplaceFile (MonoString *sourceFileName, MonoString *destinationFileName,
+ MonoString *destinationBackupFileName, MonoBoolean ignoreMetadataErrors,
+ gint32 *error)
+{
+ gboolean ret;
+ gunichar2 *utf16_sourceFileName = NULL, *utf16_destinationFileName = NULL, *utf16_destinationBackupFileName = NULL;
+ guint32 replaceFlags = REPLACEFILE_WRITE_THROUGH;
+
+ MONO_ARCH_SAVE_REGS;
+
+ if (sourceFileName)
+ utf16_sourceFileName = mono_string_chars (sourceFileName);
+ if (destinationFileName)
+ utf16_destinationFileName = mono_string_chars (destinationFileName);
+ if (destinationBackupFileName)
+ utf16_destinationBackupFileName = mono_string_chars (destinationBackupFileName);
+
+ *error = ERROR_SUCCESS;
+ if (ignoreMetadataErrors)
+ replaceFlags |= REPLACEFILE_IGNORE_MERGE_ERRORS;
+
+ ret = ReplaceFile (utf16_destinationFileName, utf16_sourceFileName, utf16_destinationBackupFileName,
+ replaceFlags, NULL, NULL);
+ if (ret == FALSE)
+ *error = GetLastError ();
+
+ return ret;
+}
+
+MonoBoolean
ves_icall_System_IO_MonoIO_CopyFile (MonoString *path, MonoString *dest,
MonoBoolean overwrite, gint32 *error)
{
Index: mono/mono/metadata/file-io.h
===
--- mono/mono/metadata/file-io.h (revision 84326)
+++ mono/mono/metadata/file-io.h (working copy)
@@ -230,6 +230,11 @@
extern void ves_icall_System_IO_MonoIO_Unlock (HANDLE handle, gint64 position,
gint64 length, gint32 *error) MONO_INTERNAL;
+extern MonoBoolean
+ves_icall_System_IO_MonoIO_ReplaceFile (MonoString *sourceFileName, MonoString *destinationFileName,
+ MonoString *destinationBackupFileName, MonoBoolean ignoreMetadataErrors,
+ gint32 *error) MONO_INTERNAL;
+
G_END_DECLS
#endif /* _MONO_METADATA_FILEIO_H_ */
Index: mono/mono/metadata/icall-def.h
===
--- mono/mono/metadata/icall-def.h (revision 84326)
+++ mono/mono/metadata/icall-def.h (working copy)
@@ -270,6 +270,7 @@
ICALL(MONOIO_16, Open(string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare,System.IO.FileOptions,System.IO.MonoIOError), ves_icall_System_IO_MonoIO_Open)
ICALL(MONOIO_17, Read(intptr,byte[],int,int,System.IO.MonoIOError), ves_icall_System_IO_MonoIO_Read)
ICALL(MONOIO_18, RemoveDirectory(string,System.IO.MonoIOError), ves_icall_System_IO_MonoIO_RemoveDirectory)
+ICALL(MONOIO_18M, ReplaceFile(string,string,string,bool,System.IO.MonoIOError), ves_icall_System_IO_MonoIO_ReplaceFile)
ICALL(MONOIO_19, Seek(intptr,long,System.IO.SeekOrigin,System.IO.MonoIOError), ves_icall_System_IO_MonoIO_Seek)
ICALL(MONOIO_20, SetCurrentDirectory(string,System.IO.MonoIOError), ves_icall_System_IO_MonoIO_SetCurrentDirectory)
ICALL(MONOIO_21, SetFileAttributes(string,System.IO.FileAttributes,System.IO.MonoIOError), ves_icall_System_IO_MonoIO_SetFileAttributes)
Index: mono/mono/io-layer/io.c
===
--- mono/mono/io-layer/io.c (revision 84326)
+++ mono/mono/io-layer/io.c (working copy)
@@ -1835,6 +1835,55 @@
return(ret);
}
+gboolean write_file (int src_fd, int dest_fd, struct stat *st_src, gboolean report_errors)
+{
+ int remain, n;
+ char *buf;
+ int buf_size = st_src-st_blksize;
+ gboolean ret = FALSE;
+
+ buf_size = buf_size 8192 ? 8192 : (buf_size 65536 ? 65536 : buf_size);
+ buf = (char *) malloc (buf_size);
+
+ for (;;) {
+ remain = read (src_fd, buf, buf_size);
+ if (remain 0) {
+ if (errno == EINTR !_wapi_thread_cur_apc_pending ())
+continue;
+
+ if (report_errors)
+_wapi_set_last_error_from_errno ();
+
+ goto write_file_cleanup;
+ }
+ if (remain == 0) {
+ break;
+ }
+
+ while (remain 0) {
+ if ((n = write (dest_fd, buf, remain)) 0) {
+if (errno == EINTR !_wapi_thread_cur_apc_pending ())
+ continue;
+
+if (report_errors)
+ _wapi_set_last_error_from_errno ();
+#ifdef DEBUG
[Mono-dev] [PATCH]System.IO.File.Replace
Attached is a patch that implements the 2.0 method File.IO.File.Replace. http://msdn2.microsoft.com/en-us/library/9etk7xw2.aspx Some implementation details are as follows. -An internal call was added to perform this operation -Most argument validation is performed in managed code. -On windows we call ReplaceFile defined in Kernel32 -On !windows Replace file was implemented in io-layer/io.c *file-io.c: Added ves_icall_System_IO_MonoIO_ReplaceFile to call ReplaceFile Kernel32 on windows or in io-layer. *file-io.h: Added deceleration for ves_icall_System_IO_MonoIO_ReplaceFile *icall-def.h: Register ves_icall_System_IO_MonoIO_ReplaceFile as an internal call. *io.c: Added implementation for ReplaceFile. *io.h: Added deceleration for ReplaceFile method. *File.cs: Add implementation for IO.File.Replace methods. *MonoIO.cs: Declared an internal call for ReplaceFile *FileTest.cs: Added a test for IO.File.Replace. This may be less of a patch request and more of a Tell me what I did wrong. ;) -bill replaceFile.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
