Hi,
I was thinking about the feasibility of having an interpreter on iOS but
making JIT functional would have a higher impact without significantly
increasing future maintenance requirements.
First I found https://gist.github.com/855607 that has two relatively
recent comments at the bottom
On 7/23/2012 9:53 AM, Marek Safar wrote:
Expanding the initialization is the easiest option how to workaround
this .net bug. Because the scope of the bug is quite limited and easy to
workaround I don't think it's work adding special handling for it.
Microsoft already fixed the issue but I am not
Hi,
Vincent Povirk wrote:
>> My preferred way would be to call exports that Windows calls:
>> - _CorValidateImage on image load
>> - _CorImageUnloading on image unload
>> - _CorExeMain instead of exe entry point
>> - _CorDllMain instaad of dll entry
>
> Is there a reason for us to add this to the
are not specific to mixed-mode assembly support.
Those could be some of them a controversial features as are not portable
across little/big endian like the fixed RVA thing.
Kornél
Kornél Pál wrote:
> Hi,
>
> I have some unsubmitted modifications to mixed-mode support I made about
> a
Hi,
I have some unsubmitted modifications to mixed-mode support I made about
a year ago. I should revise them and those may improve mixed-mode support.
I haven't had time to sort out the verifier conflict but that should be
possible and hopefully easy to resolve.
My preferred way would be to c
Hi,
They most likely run Dotfuscator on Windows and deploy binaries to Mac.
On the other hand it's important to note that control flow obfuscation
is worth nothing, since it's just an unoptimizing code transformation,
that can be reversed.
Only renaming is that makes understanding the decompil
Hi,
Please see Bug 643763:
https://bugzilla.novell.com/show_bug.cgi?id=643763
I have no write access so please feel free to commit it if you like it.
Thank you.
Kornel
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximi
Nicholas Salerno wrote:
> With respect to compatibility with Microsoft's behavior, I have found two
> bugs in Mono's implementation of installutil:
Mono aims to be compatible with MS.NET so you are welcome to fix
compatibility issues. Note that if you also provide unit tests that
prove that you
Hi,
Try looking at Environment.Version in the prod environment. If you get
1.1.x rather than 2.0.x you know what your problem is.
Note that only app.config is able to require a specific runtime version,
and there is no such thing as a 3.5 runtime (it's 2.0 with extra
assemblies versioned to 3.
to understand where
> implementations should fall into place.
>
> Nicholas
>
> -Original Message-
> From: Kornél Pál [mailto:kornel...@gmail.com]
> Sent: Saturday, September 18, 2010 5:04 AM
> To: Nicholas Salerno
> Cc: mono-devel-list@lists.ximian.com
> Subject:
Hi,
See
http://msdn.microsoft.com/en-us/library/system.configuration.install.managedinstallerclass.installhelper.aspx
That page documents exactly what it does.
installutil.exe should be implemented as sometihng like the following
(I've tried it and it works on MS.NET):
class Program
{
This is very strange since no more than a single mscorlib.dll should be
loaded no matter how many AppDomians you have.
Could you please send me more details about multiple mscolib.dlls:
- are they loaded as DLLs or just file handles?
- do they have exactly (string comparison, not considering ..,
I'm just trying to implement /nostdlib:
http://msdn.microsoft.com/en-us/library/fa13yay7.aspx
And I belive that having API for setting assembly aliases would be a
good solution.
Of course LoadMscorlib is not a bug, it's just redundant. The current
AssemblyResolve is able to do that just fine. I
Hi,
If I look at it form an API design point of view netiher LoadMscorlib
nor SetMscorlib are good.
LoadMscorlib was designed to meet your very specific needs of being able
to load mscorlib.dll from a specified file.
SetMscorlib would remove the restriction of loading from the file and
als
Please see the attached patch.
I belive that this is actually an easier and cleaner solution than the
current one.
You can use Load, LoadFile, DefineDynamicAssembly, etc. to load
mscorlib.dll.
Kornél
Jeroen Frijters write:
I would recommend SetMscorlib over LoadMscorlib because that would
Hi,
There simply is no special case for building mscorlib.dll.
There is a /nostdlib option however that enables features required for
building mscorlib.dll.
I would recommend SetMscorlib over LoadMscorlib because that would not
restrict how you can create or load mscorlib.dll.
Kornél
Jeroen
scorlib so that it accepts an Assembly rather than a
path. It should allow the case when assembliesByName and assemblies only
contain the specified assembly.
Kornél
Jeroen Frijters wrote:
> Hi Kornél,
>
> Thanks. Fixed all three issues.
>
> Regards,
> Jeroen
>
>> ----
AssemblyHashAlgorithm.SHA1 (rather than only
when calling Save).
Kornél
Jeroen Frijters wrote:
> Hi Kornél,
>
> This has now been fixed.
>
> Thanks,
> Jeroen
>
>> -Original Message-
>> From: Kornél Pál [mailto:kornel...@gmail.com]
>> Sent: Friday, May 07, 201
Hi,
Thank you for applying/enhacing the patches. I'll check it out.
This code will work on both of Mono and MS.NET, but will fail without
the WriteGenericSignature patch:
AssemblyBuilder ab = AppDomain.CurrentDomain.DefineDynamicAssembly(new
AssemblyName("myassembly"), AssemblyBuilderAccess.Sa
Hi Marek,
Thank you for your reply.
I'm trying to keep differences minimal, and I have no intention to drop
System.Reflection support:
#if IKVM_REF_EMIT
using IKVM.Reflection;
using IKVM.Reflection.Emit;
using Type = IKVM.Reflection.Type;
#else
using System.Reflection;
using System.Reflection.E
solution.
Thank you.
Kornél
Kornél Pál wrote:
> Hi,
>
> Inspired by http://tirania.org/blog/archive/2010/Apr-27.html I gave a
> try to port mcs to IKVM.Reflection.
>
> I addition to being able to have a single binary, mcs could run on
> MS.NET and we would not have to break MS
Hi,
Jeroen Frijters wrote:
> Kornél Pál wrote:
>> mcs creates an assembly, then creates types, and only after that is
>> processing the custom attributes. This is how attributes and even
>> assembly name (not the name part) can change after definition. Although
>>
;
>> Jeroen Frijters wrote:
>>> Hi,
>>>
>>> Thanks for the IKVM.Reflection patches. I have a few questions about
>>> some of the changes.
>>>
>>> - Why are the various _SetAttributes methods and the
>>> AssemblyBuilder.__SetName
intentionally don't suppor that (and also include the attributes as
> regular attributes) to be compatible with .NET
> - Why are all the stack height asserts commented out in ILGenerator, do you
> think they are wrong?
>
> Thanks,
> Jeroen
>
>> -Original M
Hi,
native int, unsigned native int, unmanaged pointers, and function
pointers are all unmanaged; thus are not affected by a moving GC.
Please review the patch.
Thanks.
Kornél
Index: mono/mono/mini/method-to-ir.c
===
--- mono/mo
Hi,
Fixed in SVN HEAD r155039 and mono-2-6 r155040.
Kornél
Miguel de Icaza wrote:
> Hello,
>
> Would you mind backporting this to the 2-6 branch as well?
>
> 2010/4/7 Kornél Pál :
>> Hi,
>>
>> Currently CompareExchange for I8 is never inlined because
Hi,
Currently CompareExchange for I8 is never inlined because of a typo.
Note that other Interlocked methods use SIZEOF_REGISTER while this use
the size of pointer and I don't know which one of these is the right one
since both registers and pointers are involved.
Please review the patch.
K
You can use the OnDeserializedAttribute and NonSerializedAttribute
attributes.
Adrian Willenbücher wrote:
> Kornél Pál wrote:
>> Also note that this patch seems to break serialization compatibility
>> that might be a problem for some applications.
>
> That is indeed a
Also note that this patch seems to break serialization compatibility
that might be a problem for some applications.
Kornél
Andreas Nahr wrote:
> I won't comment on the algorithm itself (keep in mind that the existing one
> already was replaced once with a "better" one which failed miserably in r
Hi,
I wouldn't say that this is pseudo-code. This is more like using a code
generator like using System.Reflection.Emit.ILGenerator for managed code.
Most of these instruction emitters are just preprocessor macros located
in mono/arch/x86/x86-codegen.h.
I believe that the names are quite intui
Thank you.
Marek Safar wrote:
> Patch applied
>
> Thanks
>>
>> ChangeLog:
>> Don't make compiler generated classes sealed by default.
>> Emit and close top level compiler generated classes as well.
>>
>> ReferenceEquality comparer: Use RuntimeHelpers.GetHashCode that is the
>> default GetHashCod
Hi Marek,
>> Although currently only a single compiler generated class benefits
>> from both of these modifications I don't see any drawbacks and in my
>> opinion the changes result in a more properly designed compiler
>> generated class infrastructure.
> I am not sure what does "more properly
Attached the same patch with coding style fixed.
Kornél Pál wrote:
Hi Marek,
Emit and close top level compiler generated classes as well.
They are already closed.
Most of the compiler generated classes are nested types and those are
closed.
On the other hand
Hi Marek,
>> Emit and close top level compiler generated classes as well.
> They are already closed.
Most of the compiler generated classes are nested types and those are
closed.
On the other hand DynamicExpressionStatement.StaticDataClass in
dynamic.cs is a top level compiler generated class.
Hi,
ChangeLog:
Don't make compiler generated classes sealed by default.
Emit and close top level compiler generated classes as well.
ReferenceEquality comparer: Use RuntimeHelpers.GetHashCode that is the
default GetHashCode implementation based. (Also note that some SRE
classes haven no suppor
Hi,
This actually means 1 == m_buffer.Length that effectively means no
buffering. As such there is no use to optimize (special case) for 1 ==
m_buffer.Length.
The code will continue to function properly in this special case and
will be faster in more likely (truly buffered) use cases by simply
Hi,
BufferedStream should buffer the data in both directions that is
actually implemented for Read and Write methods but not for ReadByte and
WriteByte methods.
The most efficient implementation would be to directly use the same
buffer as Read and Write uses and move the common buffer
filli
Marek Habersack wrote:
>> HttpNotImplementedHandler is not used in Web.config and is most likely
>> known by much less people but I found it in the prevously referenced
>> book so I just implemented that as well to make the internal simple
>> handler collection complete.
> I don't think we shoul
Miguel de Icaza wrote:
> I am not sure why we would include in Mono two classes that are
> flagged as internal. How would a user even use this?
Handlers are mostly used in Web.config and the ASP.NET runtime uses
reflection that makes it able to instantiate non-public types. This way
user
correctly.
Kornél
Kornél Pál wrote:
Please see the attached patch that is a separated and improved version
of the prevously submitted patch.
ChangeLog draft:
mono_image_fixup_vtable is now called only when the image is loaded and
creates trampolines rather than pointers to wrapper functions.
A
Please see the attached patch that is a separated and improved version
of the prevously submitted patch.
ChangeLog draft:
mono_image_fixup_vtable is now called only when the image is loaded and
creates trampolines rather than pointers to wrapper functions.
A new trampoline type MONO_TRAMPOLINE_V
Please see the attached patch that enables dolt on cygwin. I have tested
this and found no problems.
Please review and if you like it, approve the patch.
Thanks.
Kornél
Index: mono/acinclude.m4
===
--- mono/acinclude.m4 (revisi
Please see the attached patch that fixes cygwin build by adding mswsock lib.
Please review and if you like it, approve the patch.
Thanks.
Kornél
Index: mono/configure.in
===
--- mono/configure.in (revision 145149)
+++ mono/c
I've received no comments or approval please review and if you like it,
approve the patch.
Thanks.
Kornél
Kornél Pál wrote:
Hi,
These two internal types are present in all .NET Framework versions.
HttpNotFoundHandler is exposed by default Web.config in .NET Framewor
Hi,
Zoltan Varga wrote:
> The runtime tries to abort all threads and waits for them to
> terminate, so if a thread refuses
> to die for some reason, the runtime will hang. Its possible that the
This hang has occurred or different reasons and was reported several times.
Is there a specific re
--enable-net-4-0 --disable-net-4-0 --enable-net-1-1 --disable-net-1-1
etc. would make more sense I think because most likely there will be
more versions and there is no use to call any specific version preview
or legacy.
Jonathan Pobst wrote:
> Recently we added the .Net 4.0 profile to the Mono
Hi,
I don't know how Silverlight works on Windows but it should be checked
first.
There are two possible solutions:
1) Load assemblies as byte arrays rather than mapping them using
LoadLibrary when core clr is enabled.
2) Modify the verifier or other code that assumes on-disk layout to be
ab
s/System.Web/System.Web/HttpNotFoundHandler.cs
===
--- mcs/class/System.Web/System.Web/HttpNotFoundHandler.cs (revision 0)
+++ mcs/class/System.Web/System.Web/HttpNotFoundHandler.cs (revision 0)
@@ -0,0 +1,46 @@
+//
+// System.Web.HttpNotFoundHan
Attached a fixed version.
Kornél Pál wrote:
Hi,
This patch properly implements PATH_INFO conversion to file path and
path info. This behavior is consistent with the behavior of Apache and PHP.
Another goal is to make it faster.
Please review the patch.
Kornél
Index: src
Hi,
This patch properly implements PATH_INFO conversion to file path and
path info. This behavior is consistent with the behavior of Apache and PHP.
Another goal is to make it faster.
Please review the patch.
Kornél
Index: src/Mono.WebServer.FastCgi/Request.cs
===
Hi,
What about searching prefix/lib as well automatically that would
eliminate the need for LD_LIBRARY_PATH when using prefix not searched
by ld?
Kornél
2009/6/1 Bill Holmes :
> Hi,
>
> The attached patch was discussed on IRC last week. We found that
> MS.Net uses the directory of the declaring
to my experience).
If I set CR/LF on cygwin I wouldn't be able to compile Mono so I prefer
to use LF for shell scripts. Tools other than bash have no problem with
either line break styles.
Kornél
Robert Jordan wrote:
> Andreas Färber wrote:
>> Am 02.06.2009 um 02:14
Hi,
ChangeLog:
autogen.sh, configure.in: Set eol style to Unix to fix cygwin build.
Responder.cs (Process): Properly set status code when no application is
found.
Request.cs (ParseParameterData): Use a simple reverse scan of path
components until the first existing file and allow non-existent
Hi,
I was very happy when I realized that Mono has support for FastCGI
because that means that CGI can easily be supported as well.
I actually managed to use ASP.NET pages using a shared hosting plan.
I've created a new article in the hope that others find it useful and
that Mono will be avail
Hi,
You either can use MIT/X11 license that grants everyone equal rights or
contact Miguel de Icaza directly if you wish to grant extensive rights
to Novell only.
And you should submit your patches to the list for review if you want it
to be accepted.
Kornél
Rayson Ho wrote:
> Loongson-based
I've tested it on 32-bit Windows 2000, XP and Vista and on 64-bit
Windows XP and the values were accurate on all of them.
Kornél
Rodrigo Kumpera 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
Hi,
Nice patch.
You should use DWORD_PTR instad of DWORD and DWORD64 that would unifiy
32-bit and 64-bit parts.
I also believe that you mean "widely known" instead of "wildly know" in
the ChangeLog.
Kornél
Rodrigo Kumpera wrote:
> And, of course, I forgot to attach the patch.
>
> On Wed, Ma
Hi,
This is a quite small patch removing the wait form mono_gc_init by
modifying mono_thread_create_internal to return the MonoThread object.
Getting rid of the wait is required for support loading the runtime from
DLL initialization code on Windows because DLL load and initialization
is pro
requires less reviewing as your're
> the author of it and it doesn't affect other targets.
>
> Thanks,
> Rodrigo
>
>
> 2009/5/5 Kornél Pál mailto:kornel...@gmail.com>>
>
> Hi,
>
> The attached patch implements using trampolines f
Hi,
The attached patch implements using trampolines for vtable fixups that
delay assembly loading. I believe that this is the correct solution.
This patch also modifies:
1) EXE image is only fixed up when using driver.c; embedded mono.dll
will not improperly tamper the image used for version
mscorlib.dll is tightly integrated with the runtime so mixing the
runtime and mscorlib.dll is guaranteed not to work. Verify the same
mscorlib.dll that you want to use using peverify.exe from MS.NET for
example or on another box with Mono.
Also ensure that the file isn't corrupted by non-binary
Hi,
I don't really use profile 1.0. On MS.NET you can expect not to have 2.0
installed but since Mono has support for 1.0 and 2.0 at once there is no
need to stick to 1.0.
Over the time resisting generics is more and more difficult.:)
The only reason I've implemented that piece of code was tha
dvantage. It should be done with dynamic methods, if at all.
>
>
>
> 2009/4/3 Kornél Pál mailto:kornel...@gmail.com>>
>
> Hi,
>
> The runtime has support for generic types in profile 1.0 as well,
> OnDeserializedAttribute could also be used, just like n
will replacing the generic
stuff.
2009/4/2 Kornél Pál mailto:kornel...@gmail.com>>
Hi,
Because of the restrictions of 1.x I modified visibility so I also would
like to set skipVisibility = false in DynamicMethod constructor (not
included in the patch) to avoid 1.x only bugs b
Hi,
Because of the restrictions of 1.x I modified visibility so I also would
like to set skipVisibility = false in DynamicMethod constructor (not
included in the patch) to avoid 1.x only bugs because of this.
Kornél
Kornél Pál wrote:
> Hi,
>
> I've implement support for co
Hi,
I've implement support for compiled regular expressions in profile 1.x
using dynamic assemblies.
I also have cleaned up the code by removing GetEvalMethod and
CreateEvalMethod methods and moving their functionality to
GetMachineFactory.
I also modified the signature of EmitEvalMethodBo
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 CreateT
Hi,
You will get a very limited functionality because ntdll isn't the only
user mode module enabling you to access kernel mode services.
Also note that large parts of CreateProcess are implemented outside of
ntdll.
Anyway I would suggest you to port the io-layer to native NT API. You
may need
Hi,
When compiling profile 2.0 assemblies using trunk most mcs mono
processes either remain alive after finishing executing that prevents
make from proceeding
- or -
return to make prior to exiting and printig some messages after that
while make cannot stat the resulting .dll file that causes
Hi,
Could you please track this as well:
https://bugzilla.novell.com/show_bug.cgi?id=467201
Kornél
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Russell,
The CLI has first class support for IntPtr but C# unfortunately needs to
call IntPtr methods instead of using opcodes directly. But I believe
that these methods should be inlined by the runtime. (If not this should
be tracked in bugzilla.)
And as Rodrigo said you should use unsafe cod
Eberhard Beilharz wrote:
> 3) the build process hang when building mono/docs, so I looked in the
> Makefile of that directory and did a touch on the files it tried to
> create (some *.tree and *.zip files). I figured since it's only
> documentation it doesn't matter if I have those files or not.
Hi,
This patch fixes the test cases in
https://bugzilla.novell.com/show_bug.cgi?id=467201
I've found the following bugs:
1. Return value of functions don't has to be rounded and is not rounded
by MS.NET either.
2. conv.r4 has to change precision (required by ECMA specs)
3. conv.r8 also ha
Hi,
Microsoft .NET Framework 2.0 Service Pack 2 finally was released as a
standalone update:
http://www.microsoft.com/downloads/details.aspx?FamilyID=5B2C0358-915B-4EB5-9B1D-10E506DA9D0F&displaylang=en
As a result the following version should be used for comparison:
1.1 SP1
2.0 SP2
3.5 SP1
Upda
Hi,
This bug https://bugzilla.novell.com/show_bug.cgi?id=467201 seems to
be that conv.r4 not implemented on x86. Unfortunately I don't know
using what instructions should conv.r4 be implemented on x86.
Could someone please look at this?
Thanks.
Kornél
___
Hi,
Thomas Wiest wrote:
> Please report any bugs that you may find using our Bugs page, AND reply
> to this thread with the bug numbers so we can track them:
> http://www.mono-project.com/Bugs
This is a very annoying bug and I would be happy if this could be fixed
in Mono 2.2:
https://bugzilla.
Hi,
I don't know how ProcessModule.BaseAddress is implemented on Linux but
you shouldn't use this.
If you want to look at the IL code open the file using FileStream or use
Cecil.
Note that even if you modify IL code that would not affect code that is
already compiled to native code.
Also not
Hi,
Please implement initialization in unmanaged native code for
GetIUnknownForObject and QueryInterface rather than exposing a private
method that has to be called. COM interop should be compatible with
MS.NET and this is a bug that should be fixed rather than worked around
by exposing and ex
Hi,
This simple test case shows that background threads are killed even if
they are executing managed code. The easiest way to kill the threads is
to kill the process itself so I think that this is what MS.NET does but
killing the threads one by one results in the same behavior.
Programs tha
is just a play with QueueUserAPC to
study the runtime and Accept, not really necessary.
Kornél
Kornél Pál wrote:
Hi,
If you need a quick fix you patch will do it. But it is just a workaround.
What I suggested is that the bug is general, not related to Socket.Accept.
You wrote in your original mess
Hi,
If you need a quick fix you patch will do it. But it is just a workaround.
What I suggested is that the bug is general, not related to Socket.Accept.
You wrote in your original message:
The problem is that the APC call does not cause the accept call to break.
My test case shows that the AP
Hi,
I've modified the test case to call QueueUserAPC.
And both MS.NET and Mono (without your patch) seems to process the APC.
This still makes me think that the difference is in killing threads
rather than in Socket implementation.
When I uncommented thread.Abort(), both runtimes terminated t
Hi,
You did a great job at implementing support for this functionality but
I'm afraid that this very functionality is not supported by MS.NET either.
The difference seems to be in terminating the background threads on exit
rather that in socket handling.
Please see the attached test case th
> The point of conv.r4 or conv.r8 on a F value is to be precision consistent.
>
>
> 2008/12/15 Kornél Pál mailto:kornel...@gmail.com>>
>
> Hi,
>
> I have read the ECMA specs regarding conv.r.un and I found that
> conv.r.un converts an unsigned integ
Hi,
I have read the ECMA specs regarding conv.r.un and I found that
conv.r.un converts an unsigned integer either to float32 or to float64.
The stack only has an F type and the range of F >= than the range of
float64.
Summarizing the above I believe that the standard specifies that
conv.r.un
Hi,
Please review and approve the patch.
Thanks.
Kornél
Index: mono/mono/utils/mono-time.c
===
--- mono/mono/utils/mono-time.c (revision 120853)
+++ mono/mono/utils/mono-time.c (working copy)
@@ -42,12 +42,13 @@
gint64
mono_100ns
Hi,
Fixed in SVN r120268. Thank for reporting this breaking change in Vista SDK.
Kornél
Miha Vrhovnik wrote:
> Hi *,
>
> As I said in one of previous messages mono on windows doesn't compile using
> VS 2005 if you have Vista SDK installed. Would be nice to have this in mono
> 2.2 code...
>
>
Hi,
Please review the attched patch. Note that I've added svn:eol-style
native to all the files I've modified and source and project files thus
would be included entirely in the diff file so I excluded them but the
only addition would be adding StringsTest.vb.
Kornél
Index: mono-basic/vbrunt
Andreas Färber wrote:
>
> Am 15.11.2008 um 12:32 schrieb Kornél Pál:
>
>> Index: mcs/class/corlib/System/Convert.cs
>> ===
>> --- mcs/class/corlib/System/Convert.cs(revision 118898)
>> +++ m
Hi,
Please review and approve the patch. Thanks.
Kornél
Index: mcs/class/corlib/System/Convert.cs
===
--- mcs/class/corlib/System/Convert.cs (revision 118898)
+++ mcs/class/corlib/System/Convert.cs (working copy)
@@ -681,10 +681,6
zehua wrote:
> I need to use c++ for Mono. When I write c++ in windows, I can use "#using
> can not recognize the #usnig. I need to use some class comes from namespace
> system, like DateTime, Hashtable and so on. Is there a way to do that?
I think that you are doing something like compiling C++
Hi,
I get:
$ make
make all-recursive
make[1]: Entering directory `/mono/mono'
Making all in po
make[2]: Entering directory `/mono/mono/po'
Making all in mcs
make[3]: Entering directory `/mono/mono/po/mcs'
test ! -f ./mcs.pot || \
test -z "es.gmo ja.gmo de.gmo" || make es.gmo ja.gmo de.
Hi,
Currently mono_image_fixup_vtable actually compiles methods that causes
type loads as well and requires the assembly to be loaded.
Please help with letting me know how could I avoiding this by using JIT
trampolines. I have no idea how to create them and late fixup their address.
Thanks.
K
Hi,
You only have to build the runtime (C code). You can copy the class
library (C# code) form an other system because CIL is platform independent.
This may help if you can build a working runtime but have no working C#
compiler.
Kornél
[EMAIL PROTECTED] wrote:
> Certin,
>
> If I manage to b
Jacob Gladish wrote:
> This is exactly my problem. I do not have source. What I'm left to do is
> attempt to find all the fd's in question (in my code) and use
> Mono.Unix.Native.Syscall.fcntl() to set close-on-exec. This obviously doesn't
> work well since someone else may add new streams to th
Hi,
MS .NET creates new processes with handle inheritance enabled but on
Windows only handles maked as inheriable are inherited to the new process.
When using System.Diagnostics.Process.Start() mono closes file
descriptors in the forked process.
But if you call fork() it is your responsibility
Hi,
> This should be discussed on the mailing list and once the reason is
tracked
> down, this bug reopened
The installer does the following things that require adminsitrative
privileges:
Copy files to "Program Files": other path can be chosen
Write to some registry keys in HKEY_LOCAL_MACHI
Hi,
This patch should not cause any problems, but could you please show me
some assemblies not loading with LoadLibrary?
Kornél
Bill Holmes wrote:
> Hello All,
>
> I have found a problem loading ms generated COM interop assemblies.
> This patch fixes the problem.
>
> -bill
___
Hi,
Rodrigo Kumpera wrote:
> Well, OpenWrt runs mostly or arm based devises, so mono should work.
>
> The issue will be building a small enough runtime to fit the flash card.
Sorry not mentioning the architecture. The devices I'm interested in use
the MIPS32 architecture. I've found few docum
Hi,
There are a lot of Broadcom CPU based routers out there and I would like
to know if Mono is supported on any of them.
Thanks.
Kornél
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-de
1 - 100 of 696 matches
Mail list logo
