Re: [Mono-dev] What is the state of the Deveel.Pim
Hi miguel,I already talked with Antonello, he told me what i wanted to know. It seems that he was out of the mailing list so i will post the revelevant parts of his mail for others that might look for the same thing in the future. Deveel.Pim is a good, fast and stable library based on a CSharpCCgrammar (look at http://sourceforge.net/projects/csharpcc orhttp://www.deveel.com/projects/csharpcc): it can even parse vCards or iCal events from strings of files in standard or Outlook form (thediffer specially on vCard format...); it also creates compliant vCardand iCal formatted text that you can manage as you like.Deveel.Pim is a small project that I wrote in two days I was bored andreleased open-source (under MIT/X11 license) for Mono for make itusable from Hula project (since they still use C bindings for managevCard and iCal data). Thank you all.Ricardo Lopes.On 24/10/06, Miguel de Icaza [EMAIL PROTECTED] wrote: Hello, I saw a project named Deveel.Pim in the svn, it looks like a parser for vCards/iCals. Can anybody tell me what is the state of this project (does it work :-) ? ), what exactly does it do ? This is a project from Antonello to handle vcards and icals.-- Ricardo Lopes ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Managed DirectX
Hi, I am one of the programmers of the Wine Direct3D implementation, and I wondered if there are any plans to implement Managed DirectX in Mono, and if it is possible to share efforts between wine and mono? I googled around a bit, but couldn't find anything substancial, except that this was discussed for a SOC project, and that you have issues accessing COM objects from mono. This is basically what the wine direct3d code looks like: We have 3 libraries for the various dx versions, ddraw.dll, d3d8.dll and d3d9.dll. Plans are going on for a d3d10.dll. Those libraries offer a binary and source compatible interface to Microsoft's Direct3D user mode interface. We do not implement the kernel-side DDI or gdientry/ddentry interface and we do not plan to do that. ddraw.dll, d3d8.dll and d3d9.dll call our shared wined3d.dll library, which offers d3d9-like COM interfaces. We are considering dropping COM from wined3d because refcounting is a huge pita especially regarding ddraw.dll. WineD3D contains a basically feature-complete Direct3D9c implementation(but still way too buggy), and a software and opengl ddraw implementation(opengl ddraw is still buggy). The interface of this libarary is not stable, and may chance from wine to wine version, although this does not happen often. If you want to use wine for managed directx you can use d3d9.dll, or wined3d directly(which will need stabilization of the interface before though). The COM interface of Direct3D(and the other dx libs) is not terribly complex, and it does not support all the things that makes COM fun. As long as you can dereference a pointer and call a function pointer you should be fine :-) Cheers, Stefan Dösinger pgp98ppTKEBRT.pgp Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] FirebirdClient 2.0 and mono
Hello, Is there interest on having that sources on the mono svn ?? they work only with .net 2.0 and the equivalent mono version and there are heavy changes on namespaces and directory structure organization compared with the 1.7 sources ( that are the ones currently in mono svn ) I think there is some interest, but we need to think about how much of the code we want to keep inside Mono today. We have recently started to split things up, because having every library in the mono distribution has its share of logistic issues. Recently we moved a lot of the FX 3 stuff to a new module called Olive, and we have created our own stack of crypto stuff in a module called Crimson. I would like to have a new module for this kind of libraries, to keep the Mono core smaller. We would still ship it though. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Our tool running WinForms on Mono 1.1.18
Hello, There are still some minor issues, but I would like to really congratulate you all for the great work you are doing. Could you file bug reports for those issues? it might help if you give a copy of your tool to the Winforms team ([EMAIL PROTECTED]) We have just made an small video (flash) making a tour through some of the tool's features on Linux. 3D graphics (TaoGL) included! :-P You can have a look at our blogsite: http://codicesoftware.blogspot.com/2006/10/plastic-scm-trial-run-on-mono-1118.html Hope you like it! pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Miguel de Icaza [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Managed DirectX
Stefan Dösinger wrote: I am one of the programmers of the Wine Direct3D implementation, and I wondered if there are any plans to implement Managed DirectX in Mono, and if it is possible to share efforts between wine and mono? Hello. I started on an open implementation of the XNA libraries. Mostly because I was cheesed at the lack of good error messages. I know that isn't Managed DirectX, but Microsoft never really seemed interested in supporting that. The good news is that they're not terribly different from each other. The only catch is that it's implemented in C++/CLI, which at present is really the best way to do it. I wouldn't attempt it in C#, unless you could figure out a better way to do all the calli instructions. I thought at one point about doing a simple wrapper around the COM implementation and doing the rest in C#, but even that's not all that great, and you still have the C++/CLI dependency. Here, I'll give you a good example: -- _device-CreateTexture( width, height, levels, (DWORD) usage, (D3DFORMAT) format, (D3DPOOL) pool, tex, NULL ) -- ...becomes: -- IL_0006: ldarg.0 IL_0007: ldfld valuetype IDirect3DDevice9* Fluggo.Graphics.Direct3D.GraphicsDevice::_device IL_000c: ldarg.1 IL_000d: ldarg.2 IL_000e: ldarg.3 IL_000f: ldarg.susage IL_0011: ldarg.sformat IL_0013: ldarg.spool IL_0015: ldloca.s tex IL_0017: ldc.i4.0 IL_0018: ldarg.0 IL_0019: ldfld valuetype IDirect3DDevice9* Fluggo.Graphics.Direct3D.GraphicsDevice::_device IL_001e: ldind.i4 IL_001f: ldc.i4.s 92 IL_0021: add IL_0022: ldind.i4 IL_0023: calli unmanaged stdcall int32 modopt([mscorlib]System.Runtime.CompilerServices.IsLong) modopt([mscorlib]System.Runtime.CompilerServices.CallConvStdcall)(native int,uint32,uint32,uint32,uint32 modopt([mscorlib]System.Runtime.CompilerServices.IsLong),valuetype _D3DFORMAT,valuetype _D3DPOOL,valuetype IDirect3DTexture9**,void**) -- Here, you can see C++ calculating the address of the pointer to the function, loading it, then issuing a calli. I don't know of a way to do that in C#, at least, not one that will give you any kind of good performance. --Brian ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Managed DirectX
I am working on COM Interop support in mono. Alot of functionality is currently available for calling unmanaged COM objects from managed code (Runtime Callable Wrappers) in mono. I am working on COM Callable Wrappers right now and should have something in svn in the near future. Some details may need to be worked out (for example, I am using the cdecl calling convention on Linux right now instead of stdcall to be compatible with XPCOM). There is also a bug filed on the c# compiler (the issue is actually by design) which prevents mono from building the interop assemblies. If you want to try anything out on mono, you will need to build you interop assemblies with .Net (either by hand or via tlbimp). If you need any other help let me know. Thanks,JonathanOn 10/25/06, Brian Crowell [EMAIL PROTECTED] wrote: Stefan Dösinger wrote: I am one of the programmers of the Wine Direct3D implementation, and I wondered if there are any plans to implement Managed DirectX in Mono, and if it is possible to share efforts between wine and mono? Hello.I started on an open implementation of the XNA libraries. Mostly because I was cheesed at the lack of good error messages. I know that isn't Managed DirectX, but Microsoft never really seemed interested in supporting that. The good news is that they're not terribly different from each other. The only catch is that it's implemented in C++/CLI, which at present is really the best way to do it. I wouldn't attempt it in C#, unless you could figure out a better way to do all the calli instructions. I thought at one point about doing a simple wrapper around the COM implementation and doing the rest in C#, but even that's not all that great, and you still have the C++/CLI dependency. Here, I'll give you a good example:--_device-CreateTexture( width, height, levels, (DWORD) usage, (D3DFORMAT) format, (D3DPOOL) pool, tex, NULL )--...becomes: --IL_0006:ldarg.0IL_0007:ldfldvaluetype IDirect3DDevice9* Fluggo.Graphics.Direct3D.GraphicsDevice::_deviceIL_000c:ldarg.1IL_000d:ldarg.2IL_000e:ldarg.3IL_000f: ldarg.susageIL_0011:ldarg.sformatIL_0013:ldarg.spoolIL_0015:ldloca.s texIL_0017:ldc.i4.0IL_0018:ldarg.0IL_0019:ldfldvaluetype IDirect3DDevice9* Fluggo.Graphics.Direct3D.GraphicsDevice::_device IL_001e:ldind.i4IL_001f:ldc.i4.s 92IL_0021:addIL_0022:ldind.i4IL_0023:calliunmanaged stdcall int32 modopt([mscorlib]System.Runtime.CompilerServices.IsLong) modopt([mscorlib]System.Runtime.CompilerServices.CallConvStdcall)(native int,uint32,uint32,uint32,uint32 modopt([mscorlib]System.Runtime.CompilerServices.IsLong),valuetype _D3DFORMAT,valuetype _D3DPOOL,valuetype IDirect3DTexture9**,void**) --Here, you can see C++ calculating the address of the pointer to the function, loading it, then issuing a calli. I don't know of a way to do that in C#, at least, not one that will give you any kind of good performance. --Brian___Mono-devel-list mailing listMono-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] Managed DirectX
It's worth mentioning that Microsoft's Managed DirectX doesn't use COM interop. They have a library with a simpler C interface that talks to the kernel portion of DirectX that the drivers plug into and the MDX library uses that - it's almost completely seperate from the DirectX that C++ developers use. Richard ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Managed DirectX
Richard Matthias wrote: It's worth mentioning that Microsoft's Managed DirectX doesn't use COM interop. They have a library with a simpler C interface that talks to the kernel portion of DirectX that the drivers plug into and the MDX library uses that - it's almost completely seperate from the DirectX that C++ developers use. Er... no. I have Managed DirectX installed, and I can find, through ILDASM, pretty much the exact same IL sequence I posted earlier, pointer arithmetic and all. They use hand-written marshaling to the COM interfaces, not to the kernel. In fact, here's the document where they say they did it: http://members.microsoft.com/customerevidence/Common/FileOpen.aspx?FileName=12419_MicrosoftDirectX_CS.doc --Brian ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Managed DirectX
Brian Crowell wrote: Richard Matthias wrote: It's worth mentioning that Microsoft's Managed DirectX doesn't use COM interop. They have a library with a simpler C interface that talks to the kernel portion of DirectX that the drivers plug into and the MDX library uses that - it's almost completely seperate from the DirectX that C++ developers use. Er... no. I have Managed DirectX installed, and I can find, through ILDASM, pretty much the exact same IL sequence I posted earlier, pointer arithmetic and all. They use hand-written marshaling to the COM interfaces, not to the kernel. Careful what you do with ILDASM Brian, at least if you plan on contributing code to the mono project: Do not use the ildasm or equivalent tools program to disassemble proprietary code when you are planning to reimplement a class for Mono. If you have done this, we will not be able to use your code. From the bottom of: http://www.mono-project.com/Contributing -- Michael Schurter ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Managed DirectX
Michael Schurter wrote: Careful what you do with ILDASM Brian, at least if you plan on contributing code to the mono project: Yes, I know. I mostly just wanted to figure out how they made calls; everything else in my own managed implementation is written from scratch using documentation. Better yet, I throw more useful exceptions. Anyhow, does anyone know of a good way to step around the hand-coded interop problem without using Managed C++ or C++/CLI? --Brian ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Managed DirectX
Am Mittwoch 25 Oktober 2006 19:02 schrieben Sie: A practical example of building a wrapper by hand would be most helpful. Late binding is not an option, and I haven't ever found interface definition files for DirectX9. As far as I know idl files for dx9 do not exist, only the d3d9.h, d3d9types.h and d3d9caps.h(simmilar for other dx parts), but with dx10 ms started using idl files. So from the other replies it sounds like you can use wine for dx, but mono needs some preparation work first. If you need any help just contact me or the wine-devel list :-) Stefan pgpSvOORFEmkq.pgp Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Managed DirectX
Stefan Dösinger wrote: So from the other replies it sounds like you can use wine for dx, but mono needs some preparation work first. If you need any help just contact me or the wine-devel list :-) Well, one option is to use a library written in C++/CLI, compile it with Microsoft's C++ compiler, and then use the resulting library with Mono. That should work. There's just no equivalent all-Mono method. Tell you what. Sometime this week I'll look to release what I have done regarding XNA. It won't be exactly what you want-- in particular, my library depends on a common primitives library-- but it could be a good starting point for a Managed DirectX 9 implementation. --Brian ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Optimize Encoding.GetByteCount
Hey guys,
On the 2.0 profile, Encoding uses the char*/byte* version of encoding
methods to avoid allocating memory. One code path missed this
optimization, I've attached a fix.
This code path ends up being used in Banshee quite a bit on their tree
view (basically, every time the model is queried, this method gets called
in passing String objects to char*).
A few things to think about:
- It might pay to do something on the 1.0 profile as well.
- Paolo, can you comment on how this kind of change works with the moving gc?
-bIndex: Encoding.cs
===
--- Encoding.cs (revision 66966)
+++ Encoding.cs (working copy)
@@ -211,12 +211,18 @@
// Convenience wrappers for GetByteCount.
public virtual int GetByteCount (String s)
{
- if (s != null) {
- char[] chars = s.ToCharArray ();
- return GetByteCount (chars, 0, chars.Length);
- } else {
+ if (s == null)
throw new ArgumentNullException (s);
+#if NET_2_0
+ unsafe {
+ fixed (char* cptr = s) {
+return GetByteCount (cptr, s.Length);
+ }
}
+#else
+ char[] chars = s.ToCharArray ();
+ return GetByteCount (chars, 0, chars.Length);
+#endif
}
public virtual int GetByteCount (char[] chars)
{___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Optimize Encoding.GetByteCount
Thanks Ben! --Aaron On Wed, 2006-10-25 at 16:51 -0400, Ben Maurer wrote: Hey guys, On the 2.0 profile, Encoding uses the char*/byte* version of encoding methods to avoid allocating memory. One code path missed this optimization, I've attached a fix. This code path ends up being used in Banshee quite a bit on their tree view (basically, every time the model is queried, this method gets called in passing String objects to char*). A few things to think about: - It might pay to do something on the 1.0 profile as well. - Paolo, can you comment on how this kind of change works with the moving gc? -b ___ 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] Optimize Encoding.GetByteCount
To my understanding, fixed pointers do not participate GC target. And- locally-allocated array anyways lives until its conversion finishes (and probably immediately disposed depending on the JIT optimization)- Usually this conversion do not take long timeSo I guess fixed pointer would work better than possibly being movedfrom nursery area. It's better to not allocate a new array if it can be avoided. From my own code i found that in one of my intensively used methods i allocated a 100byte array each time the method was called. By moving that variable outside the method and just reinitialising it each time i used it (with appropriate locking) memory usage reduced by a large %. Don't rely on the GC to tidy up your mess if you can avoid creating it in the first place :p ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Optimize Encoding.GetByteCount
Hi, Well, the point of the Ben's question is, compacting GC is likely to store array in nursery area (likely, since it could be regarded too big to store in nursery area), so nursery allocation and releasing might become faster than fixing string pointer which might slowdown GC. (That's why BenM asked Paolo, as only he would know the best answer ;-) Atsushi Eno Alan McGovern wrote: To my understanding, fixed pointers do not participate GC target. And - locally-allocated array anyways lives until its conversion finishes (and probably immediately disposed depending on the JIT optimization) - Usually this conversion do not take long time So I guess fixed pointer would work better than possibly being moved from nursery area. It's better to not allocate a new array if it can be avoided. From my own code i found that in one of my intensively used methods i allocated a 100byte array each time the method was called. By moving that variable outside the method and just reinitialising it each time i used it (with appropriate locking) memory usage reduced by a large %. Don't rely on the GC to tidy up your mess if you can avoid creating it in the first place :p ___ 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] OS X MACHINE_THREAD_STATE patch for newer 10.4u SDK
This patch fixes problems with building mono for i386 using the new 10.4u SDK that ships with Xcode 2.4. Current SVN builds for i386 under the new SDK, but does not run properly due to changes in MACHINE_THREAD_STATE. It looks like the breakage in source compatibility is intentional on Apple's part and future headers will be similarly broken. I will be submitting the same patch to libgc upstream. -Allan -- Allan Hsu allan at counterpop dot net 1E64 E20F 34D9 CBA7 1300 1457 AC37 CBBB 0E92 C779 Index: libgc/darwin_stop_world.c === --- libgc/darwin_stop_world.c (revision 66738) +++ libgc/darwin_stop_world.c (working copy) @@ -75,12 +75,14 @@ ptr_t lo, hi; #if defined(POWERPC) ppc_thread_state_t state; + mach_msg_type_number_t thread_state_count = PPC_THREAD_STATE_COUNT; #elif defined(I386) i386_thread_state_t state; + mach_msg_type_number_t thread_state_count = i386_THREAD_STATE_COUNT; #else # error FIXME for non-x86 || ppc architectures + mach_msg_type_number_t thread_state_count = MACHINE_THREAD_STATE_COUNT; #endif - mach_msg_type_number_t thread_state_count = MACHINE_THREAD_STATE_COUNT; me = pthread_self(); if (!GC_thr_initialized) GC_thr_init(); @@ -94,7 +96,7 @@ /* Get the thread state (registers, etc) */ r = thread_get_state( p-stop_info.mach_thread, -MACHINE_THREAD_STATE, +GC_MACH_THREAD_STATE_FLAVOR, (natural_t*)state, thread_state_count); if(r != KERN_SUCCESS) ABORT(thread_get_state failed); @@ -193,7 +195,7 @@ ppc_thread_state64_t info; # endif mach_msg_type_number_t outCount = THREAD_STATE_MAX; - r = thread_get_state(thread, MACHINE_THREAD_STATE, + r = thread_get_state(thread, GC_MACH_THREAD_STATE_FLAVOR, (natural_t *)info, outCount); if(r != KERN_SUCCESS) continue; @@ -236,7 +238,7 @@ WARN(This is completely untested and likely will not work\n, 0); i386_thread_state_t info; mach_msg_type_number_t outCount = THREAD_STATE_MAX; - r = thread_get_state(thread, MACHINE_THREAD_STATE, + r = thread_get_state(thread, GC_MACH_THREAD_STATE_FLAVOR, (natural_t *)info, outCount); if(r != KERN_SUCCESS) continue; Index: libgc/include/private/gc_priv.h === --- libgc/include/private/gc_priv.h (revision 66738) +++ libgc/include/private/gc_priv.h (working copy) @@ -366,6 +366,16 @@ # define BZERO(x,n) bzero((char *)(x),(int)(n)) # endif +#if defined(DARWIN) +# if defined(POWERPC) +# define GC_MACH_THREAD_STATE_FLAVOR PPC_THREAD_STATE +# elif defined(I386) +# define GC_MACH_THREAD_STATE_FLAVOR i386_THREAD_STATE +# else +# define GC_MACH_THREAD_STATE_FLAVOR MACHINE_THREAD_STATE +# endif +#endif + /* Delay any interrupts or signals that may abort this thread. Data */ /* structures are in a consistent state outside this pair of calls.*/ /* ANSI C allows both to be empty (though the standard isn't very */ Index: libgc/os_dep.c === --- libgc/os_dep.c (revision 66738) +++ libgc/os_dep.c (working copy) @@ -3702,7 +3702,7 @@ mask, GC_ports.exception, EXCEPTION_DEFAULT, -MACHINE_THREAD_STATE +GC_MACH_THREAD_STATE_FLAVOR ); if(r != KERN_SUCCESS) ABORT(task_set_exception_ports failed); ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] XScale?, Mono-devel-list Digest, Vol 18, Issue 62
Hello all,I know mono will run on OMAPs (nokia 770), and I managed to get the same binary to run a Cirrus Logic EP9302.What is required to get mono to run on XScale. I have an application in mind that uses a PXA255, and I would love to use C#... Thanks! J.Cody -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, October 26, 2006 12:11 AM To: mono-devel-list@lists.ximian.com Subject: Mono-devel-list Digest, Vol 18, Issue 62 Send Mono-devel-list mailing list submissions to mono-devel-list@lists.ximian.com To subscribe or unsubscribe via the World Wide Web, visit http://lists.ximian.com/mailman/listinfo/mono-devel-list or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of Mono-devel-list digest..." Today's Topics: 1. Re: Managed DirectX (Brian Crowell) 2. Re: Managed DirectX (Stefan D?singer) 3. Re: Managed DirectX (Brian Crowell) 4. [PATCH] Optimize Encoding.GetByteCount (Ben Maurer) 5. Re: [PATCH] Optimize Encoding.GetByteCount (Atsushi Eno) 6. Re: [PATCH] Optimize Encoding.GetByteCount (Aaron Bockover) 7. Re: [PATCH] Optimize Encoding.GetByteCount (Alan McGovern) 8. Re: [PATCH] Optimize Encoding.GetByteCount (Atsushi Eno) 9. Re: Managed DirectX (Miguel de Icaza) 10. [PATCH] OS X MACHINE_THREAD_STATE patch for newer 10.4u SDK (Allan Hsu) -- Message: 1 Date: Wed, 25 Oct 2006 13:31:07 -0500 From: Brian Crowell [EMAIL PROTECTED] Subject: Re: [Mono-dev] Managed DirectX To: Michael Schurter [EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Michael Schurter wrote: Careful what you do with ILDASM Brian, at least if you plan on contributing code to the mono project: Yes, I know. I mostly just wanted to figure out how they made calls; everything else in my own managed implementation is written from scratch using documentation. Better yet, I throw more useful exceptions. Anyhow, does anyone know of a good way to step around the hand-coded interop problem without using Managed C++ or C++/CLI? --Brian -- Message: 2 Date: Wed, 25 Oct 2006 20:49:29 +0200 From: Stefan D?singer [EMAIL PROTECTED] Subject: Re: [Mono-dev] Managed DirectX To: Brian Crowell [EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset="iso-8859-1" Am Mittwoch 25 Oktober 2006 19:02 schrieben Sie: A practical example of building a wrapper by hand would be most helpful. Late binding is not an option, and I haven't ever found interface definition files for DirectX9. As far as I know idl files for dx9 do not exist, only the d3d9.h, d3d9types.h and d3d9caps.h(simmilar for other dx parts), but with dx10 ms started using idl files. So from the other replies it sounds like you can use wine for dx, but mono needs some preparation work first. If you need any help just contact me or the wine-devel list :-) Stefan -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20061025/f9253082/attachment-0001.bin -- Message: 3 Date: Wed, 25 Oct 2006 14:08:14 -0500 From: Brian Crowell [EMAIL PROTECTED] Subject: Re: [Mono-dev] Managed DirectX To: Stefan D?singer [EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Stefan D?singer wrote: So from the other replies it sounds like you can use wine for dx, but mono needs some preparation work first. If you need any help just contact me or the wine-devel list :-) Well, one option is to use a library written in C++/CLI, compile it with Microsoft's C++ compiler, and then use the resulting library with Mono. That should work. There's just no equivalent all-Mono method. Tell you what. Sometime this week I'll look to release what I have done regarding XNA. It won't be exactly what you want-- in particular, my library depends on a common primitives library-- but it could be a good starting point for a Managed DirectX 9 implementation. --Brian -- Message: 4 Date: Wed, 25 Oct 2006 16:51:57 -0400 (EDT) From: "Ben Maurer" [EMAIL PROTECTED] Subject: [Mono-dev] [PATCH] Optimize Encoding.GetByteCount To: mono-devel-list@lists.ximian.com Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset="iso-8859-1" Hey guys, On the 2.0 profile, Encoding uses the char*/byte* version of encoding methods to avoid
