LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
September 2004
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2004.09.22 03:52 "Re: libtiff and .net", by Bill Bither
> > I don't think it really makes sense to port LibTIFF to 100% managed > > .NET code. The better approach would be to use PInvoke from .NET > > to call the compiled LibTIFF library functions and create your own > > objects based on that, or use an existing 3rd party .NET component > > that's based on LibTIFF (check my signature for more info there). > > This approach does not work for architecture-independent applications > which are downloaded via HTTP. There is likely value in TIFF support > code which is architecture-independent. Since libtiff is portable, it > should be feasable to port the portable parts so they work natively in > .net. I agree that there would be some value to this, but there is likely to be quite a performance impact with the managed code version. Would a port to .NET be "truly" managed using the managed heap for the image data, requiring the GC to free the image data when it feels like it, or would it store the image data on the unmanaged heap, where the developer can explicitly dispose the data, much like GDI+ in .NET does? Other than architecture-independence, the only other advantage I see for a true managed LibTIFF would be the ability to run the code in a partial trust environment. > > Also, MS Visual Studio 2005, currently in beta, allows for compiling > > unmanaged code into managed assemblies using C++. This would be the > > ultimate solution as it takes advantage of both managed usability and > > the .NET Framework with unmanaged performance and memory management. > > I am not sure what you mean by this. The first release of .net > supported compiling unmanaged C++ code into a managed assembly. > Presumably the 2005 version does something more special? Maybe it > solves the "dual-heap" problem? Managed Extensions for .NET really didn't make too much sense to me, and is difficult to use. The *new* VC++ is actually quite impressive from the Microsoft demonstrations I have seen. You can compile both unmanaged and managed code into the same assembly and into MSIL. With some syntax additions, you tell the compiler in code to allocate on the managed or unmanaged heap. There has also been more concentration on performance and optimizations using managed/unmanaged C++ versus C#. The biggest drawback to us is that it's only available in VS 2005 and requires the .NET 2.0 framework. I'm by far no expert in this, but in theory, you could take LibTIFF and compile it entirely into MSIL as an unsafe "managed" assembly. Best Regards, Bill Bither Atalasoft www.atalasoft.com