Re: [Mono-devel-list] Can I use Microsoft's DLL's on the Win32 platform?
Hey, On Tue, 2005-04-26 at 06:14 -0400, Pete Gonzalez wrote: Anyway, my point is that Mono can successfully execute quite a lot of Microsoft code before crashing. :-) Out of curiosity, I have just one concern about the legal side. Does the license of Microsoft .NET Framework allow users to run their implementations on non-Microsoft environments? Thanks, -- .O. ..O Enver ALTIN | http://skyblue.gen.tr/ OOO Software developer @ Parkyeri | http://www.parkyeri.com/ signature.asc Description: This is a digitally signed message part
Re: [Mono-devel-list] Can I use Microsoft's DLL's on the Win32 platform?
Rafael Teixeira wrote: Their more recent EULAs forbid to run outside Windows/WindowsCE. But I don't think it states anything about using anothr (Mono) runtime in Windows to run them. Is this referring to .NET's code (dlls and exe's) or .exe and .dll generated by Visual Studio from your own source code? Either way I can't see this standing in court and therefore not enforcible: EULAs state many things, but it does not mean they all legit. Alex ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Can I use Microsoft's DLL's on the Win32 platform?
Alex Chudnovsky wrote: Is this referring to .NET's code (dlls and exe's) or .exe and .dll generated by Visual Studio from your own source code? Either way I can't see this standing in court and therefore not enforcible: EULAs state many things, but it does not mean they all legit. Intuitively, I would think usage of a 3rd party JIT constitutes fair use of Microsoft's DLL's. A more interesting question is whether a 3rd party tool can compile and statically link Microsoft's DLL's, which is a feature advertised by many obfuscators such as these: http://thinstall.com/help/index.html?linking_netframework.htm http://www.xenocode.com/Product-Comparison.aspx http://dotnetprotector.pvlog.com/Fonctions.aspx http://www.remotesoft.com/linker/index.html I asked the RemoteSoft guy about this, and he said: About whether linker tool violates EULA, I asked MS, they didn't give a firm anwser, but saying not unlikely to go after us and our customers. (I'm assuming the not unlikely [sic] is the emphatic double-negative, not the logical double-negative. :-) ) Cheers, -Pete ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Can I use Microsoft's DLL's on the Win32 platform?
Hello, Hmm... I didn't see COM interop listed anywhere on your roadmap page. Is this a priority? It seems that the ability to execute Microsoft DLL's It is listed somewhere as a feature that we are not likely going to support. It is just not useful at all in Unix, so either someone authors this support and convinces us that it is worth checking it into the repository or that wont ever get done. would be a prerequisite for running Visual Studio projects, and in particular the huge number of third party Win32-only assemblies require for a desktop application. (Interoperability is everything, and I would argue that Java's failure on the desktop is largely due to Sun's obssession with platform independence, to the point of discouraging usage of native API's, even when they are vastly superior to the JDK stuff.) Apps that use COM or ActiveX controls will never run on Mono. Even if COM was there, the existing code that depends on the control would require the control to be ported to some form of COM on Unix (which to begin with is not available in a reusable form) and binaries for each platform to be created. For what it's worth, I was able to reconfigure Mono.exe to load Microsoft's DLL's (except for mscorlib.dll). The first problem I encountered was missing implementations for Marshal.ReadByte() and Marshal.ReadInt16(). I hacked these as calls to mscoree.dll (which seems to work!), and now the application runs until the CreateWindowEx() call, at which point it crashes with a basic Win32 API error. With some more hacking, I could probably get further to some other error. You can probably get further, but it is still a waste of time. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Can I use Microsoft's DLL's on the Win32 platform?
Miguel de Icaza wrote: Apps that use COM or ActiveX controls will never run on Mono. Even if COM was there, the existing code that depends on the control would require the control to be ported to some form of COM on Unix (which to begin with is not available in a reusable form) and binaries for each platform to be created. Heh, so in other words, run on Mono means run on Unix? That's cool, but you know not everybody cares about creating a single .exe that runs on multiple platforms, especially if it means giving up valuable libraries and API's. For example, the Mac versions of big apps like Adobe Photoshop or MS Word have huge differences from Win32 in order to integrate properly with the OS. And for many companies, the only platform they have to worry about is the one with ActiveX. :-D Cheers, -Pete ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Can I use Microsoft's DLL's on the Win32 platform?
On Die, 2005-04-26 at 14:39 -0400, Pete Gonzalez wrote: Miguel de Icaza wrote: Apps that use COM or ActiveX controls will never run on Mono. Even if COM was there, the existing code that depends on the control would require the control to be ported to some form of COM on Unix (which to begin with is not available in a reusable form) and binaries for each platform to be created. Heh, so in other words, run on Mono means run on Unix? That's cool, but you know not everybody cares about creating a single .exe that runs on multiple platforms, especially if it means giving up valuable libraries and API's. For example, the Mac versions of big apps like Adobe Photoshop or MS Word have huge differences from Win32 in order to integrate properly with the OS. And for many companies, the only platform they have to worry about is the one with ActiveX. :-D The whole point of Mono is to develop a cross-platform environment, so it doesn't really make sense to implement non-cross-platform components, does it? Excerpt from Mono FAQ[1]: What is Mono exactly? The Mono Project is an open development initiative sponsored by Novell that is working to develop an open source, UNIX version of the Microsoft .NET development platform. Its objective is to enable UNIX developers to build and deploy cross-platform .NET Applications. [1] http://www.mono-project.com/FAQ:_General Regards, Jrg -- Jrg Billeter [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Can I use Microsoft's DLL's on the Win32 platform?
Hello, Apps that use COM or ActiveX controls will never run on Mono. Even if COM was there, the existing code that depends on the control would require the control to be ported to some form of COM on Unix (which to begin with is not available in a reusable form) and binaries for each platform to be created. Heh, so in other words, run on Mono means run on Unix? That's cool, I did not say that. You are trying to use libraries from Microsoft that are fairly tied to the Windows platforms. We are implementing equivalents that cover most of them in a cross platform fashion, but in your attempts to get ahead of the game, you have chosen to pursue a hackish path that will not work. No amount of complaining will make that change. If you want to take advantage of COM and ActiveX on Windows with the CLI, use the Microsoft provided runtime, and purchase one of those tools that will do the equivalent of mkbundle. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Can I use Microsoft's DLL's on the Win32 platform?
Hello, I am just getting started with Mono on Windows XP. I built a very simple HelloWorld.exe using Visual Studio, then I clicked on the Mono-1.1.6 Command Prompt and typed mono HelloWorld. When my form appeared, the GUI did not look quite right, which is a little surprising since it's just an empty dialog box with a button. :-) The Mono Windows.Forms implementation obviously is still under construction, but since my target platform is Windows XP, I can just use the real Microsoft libraries. So I tracked down all the referenced Microsoft DLL's and copied them to the same folder as HelloWorld.exe, so that Mono will load them instead of its custom versions. However, now my application crashes with an exception: Unhandled Exception: System.NotImplementedException: The requested feature is not implemented. in 0x00021 Microsoft.Win32.SystemEvents:add_UserPreferenceChanging (Microsoft.Win32.UserPreferenceChangingEventHandler value) in 0x0004e System.Drawing.KnownColorTable:InitColorTable () in 0x00010 System.Drawing.KnownColorTable:EnsureColorTable () in 0x7 System.Drawing.KnownColorTable:KnownColorToArgb (KnownColor color) in 0x0003c System.Drawing.Color:get_Value () I read the FAQ's, but apparently using Microsoft DLL's has never occurred to anyone? It seems to me that, as long Mono's MSIL virtual machine and pinvoke support are there, mono.exe should work as a drop-in replacement for Microsoft's virtual machine (regardless of how incomplete Mono's .NET Framework is). Moreover, it seems that this would be a quite simple challenge compared to implementing a full C# compiler or Windows.Forms replacement. So -- has anyone asked about this? Does it work? My hope is to use kick-ass Mono features (such as the SSA optimizations, --aot, mkbundle, etc.) with standard Visual Studio projects, which you'd think would be very attractive. More importantly, Win32 offers a vast array of libraries that may be unsupported by Mono for a long time, so in a sense, this is a mandatory requirement for Win32 developers who aren't hindered by portability concerns. Cheers, -Pete ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Can I use Microsoft's DLL's on the Win32 platform?
El dl 25 de 04 del 2005 a les 15:17 -0400, en/na Pete Gonzalez va escriure: Hello, I am just getting started with Mono on Windows XP. I built a very simple HelloWorld.exe using Visual Studio, then I clicked on the Mono-1.1.6 Command Prompt and typed mono HelloWorld. When my form appeared, the GUI did not look quite right, which is a little surprising since it's just an empty dialog box with a button. :-) The Mono Windows.Forms implementation obviously is still under construction, but since my target platform is Windows XP, I can just use the real Microsoft libraries. So I tracked down all the referenced Microsoft DLL's and copied them to the same folder as HelloWorld.exe, so that Mono will load them instead of its custom versions. However, now my application crashes with an exception: Hi Pete! Can you please log a bug in http://bugzilla.ximian.com including a copy of the source code of the small example that you try to run? We will look after the error. There is also a specific Windows Forms mailing list if you want to talk specifically of that namespace. Thanks, -- Jordi Mas i Hernàndez - Mono development team - http://www.mono-project.com Homepage and LiveJournal at http://www.softcatala.org/~jmas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Can I use Microsoft's DLL's on the Win32 platform?
Miguel de Icaza wrote: You wont be able to assemblies that come from the .NET framework with Mono. Many of these assemblies use internal calls to the virtual machine, and are hence non-portable or use COM which is not supported by Mono. Third party libraries will work, but you need to look at its dependencies on a case-by-case basis. Is it reasonable to assume that cases of internal calls and using COM are always accompanied by the text string MethodImplOptions.InternalCall in the MSIL? If so, then I did a quick search for InternalCall in my application's DLL's, and other than a couple COM interfaces in Accessibility.dll, the non-portable stuff seems to be entirely confined to mscorlib.dll. How good is Mono's emulation of mscorlib.dll? If it's reasonably complete, then maybe this isn't such a Herculean task. :-) Also, the NotImplementedException error must be coming from a Mono library, not a Microsoft one, right? How do I see where mono.exe is loading its DLL's from, and how do I redirect it to use the Microsoft ones? Thanks, -Pete __ Accessibility.dll: Accessibility.IAccessible Accessibility.dll: Accessibility.IAccessibleHandler mscorlib.dll: Microsoft.Win32.OAVariantLib mscorlib.dll: System.AppDomain mscorlib.dll: System.AppDomainSetup mscorlib.dll: System.ArgIterator mscorlib.dll: System.Array mscorlib.dll: System.BCLDebug mscorlib.dll: System.BitConverter mscorlib.dll: System.Buffer mscorlib.dll: System.Char mscorlib.dll: System.ConfigServer mscorlib.dll: System.Console mscorlib.dll: System.Convert mscorlib.dll: System.Currency mscorlib.dll: System.CurrentSystemTimeZone mscorlib.dll: System.DateTime mscorlib.dll: System.Decimal mscorlib.dll: System.DefaultBinder mscorlib.dll: System.Delegate mscorlib.dll: System.Double mscorlib.dll: System.Enum mscorlib.dll: System.Environment mscorlib.dll: System.Exception mscorlib.dll: System.GC mscorlib.dll: System.Guid mscorlib.dll: System.MarshalByRefObject mscorlib.dll: System.Math mscorlib.dll: System.MissingFieldException mscorlib.dll: System.MissingMemberException mscorlib.dll: System.MissingMethodException mscorlib.dll: System.Number mscorlib.dll: System.Object mscorlib.dll: System.ParseNumbers mscorlib.dll: System.RuntimeMethodHandle mscorlib.dll: System.RuntimeType mscorlib.dll: System.Single mscorlib.dll: System.String mscorlib.dll: System.Type mscorlib.dll: System.TypedReference mscorlib.dll: System.TypeLoadException mscorlib.dll: System.ValueType mscorlib.dll: System.Variant mscorlib.dll: System.Diagnostics.Assert mscorlib.dll: System.Diagnostics.Debugger mscorlib.dll: System.Diagnostics.Log mscorlib.dll: System.Diagnostics.StackTrace mscorlib.dll: System.Globalization.Calendar mscorlib.dll: System.Globalization.CalendarTable mscorlib.dll: System.Globalization.CharacterInfo mscorlib.dll: System.Globalization.CompareInfo mscorlib.dll: System.Globalization.CultureInfo mscorlib.dll: System.Globalization.CultureTable mscorlib.dll: System.Globalization.EncodingTable mscorlib.dll: System.Globalization.GlobalizationAssembly mscorlib.dll: System.Globalization.RegionTable mscorlib.dll: System.Globalization.SortKey mscorlib.dll: System.Globalization.TextInfo mscorlib.dll: System.IO.FileLoadException mscorlib.dll: System.IO.FileStream mscorlib.dll: System.IO.Path mscorlib.dll: System.IO.IsolatedStorage.IsolatedStorage mscorlib.dll: System.IO.IsolatedStorage.IsolatedStorageFile mscorlib.dll: System.Reflection.Assembly mscorlib.dll: System.Reflection.AssemblyName mscorlib.dll: System.Reflection.CustomAttribute mscorlib.dll: System.Reflection.Module mscorlib.dll: System.Reflection.RuntimeConstructorInfo mscorlib.dll: System.Reflection.RuntimeEventInfo mscorlib.dll: System.Reflection.RuntimeFieldInfo mscorlib.dll: System.Reflection.RuntimeMethodInfo mscorlib.dll: System.Reflection.RuntimePropertyInfo mscorlib.dll: System.Reflection.StrongNameKeyPair mscorlib.dll: System.Reflection.Emit.MethodRental mscorlib.dll: System.Reflection.Emit.SignatureHelper mscorlib.dll: System.Reflection.Emit.TypeBuilder mscorlib.dll: System.Runtime.CompilerServices.RuntimeHelpers mscorlib.dll: System.Runtime.InteropServices.ArrayWithOffset mscorlib.dll: System.Runtime.InteropServices.ExtensibleClassFactory mscorlib.dll: System.Runtime.InteropServices.GCHandle mscorlib.dll: System.Runtime.InteropServices.Marshal mscorlib.dll: System.Runtime.InteropServices.RegistrationServices mscorlib.dll: System.Runtime.InteropServices.RuntimeEnvironment mscorlib.dll: System.Runtime.InteropServices.TypeLibConverter mscorlib.dll: System.Runtime.Remoting.RemotingServices mscorlib.dll: System.Runtime.Remoting.Channels.ChannelServices mscorlib.dll: System.Runtime.Remoting.Contexts.Context mscorlib.dll: System.Runtime.Remoting.Messaging.Message mscorlib.dll: System.Runtime.Remoting.Messaging.StackBuilderSink mscorlib.dll: System.Runtime.Remoting.Proxies.RealProxy mscorlib.dll: System.Runtime.Serialization.FormatterServices mscorlib.dll: System.Security.CodeAccessSecurityEngine mscorlib.dll:
Re: [Mono-devel-list] Can I use Microsoft's DLL's on the Win32 platform?
Hello, Is it reasonable to assume that cases of internal calls and using COM are always accompanied by the text string MethodImplOptions.InternalCall in the MSIL? If so, then I did a quick search for InternalCall in my application's DLL's, and other than a couple COM interfaces in Accessibility.dll, the non-portable stuff seems to be entirely confined to mscorlib.dll. My list was not exhaustive, you should also look for P/Invoke and IJW stubs. But even if you did not look into that, Windows.Forms exposes and consumes COM extensively so it will not work on Mono (in our implementation we just throw). Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
