AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2004.09.16 17:04 "[Tiff] libtiff and .net", by Kabongo, Kalonji
2004.09.16 17:09 "Re: [Tiff] libtiff and .net", by Bob Friesenhahn
2004.09.16 17:23 "RE: [Tiff] libtiff and .net", by Kabongo, Kalonji
2004.09.16 17:35 "RE: [Tiff] libtiff and .net", by Bob Friesenhahn
2004.09.16 17:44 "RE: [Tiff] libtiff and .net", by Kabongo, Kalonji
2004.09.16 18:16 "RE: [Tiff] libtiff and .net", by Bob Friesenhahn
2004.09.16 17:59 "RE: [Tiff] libtiff and .net", by Bill Bither
2004.09.20 19:48 "RE: [Tiff] libtiff and .net", by Bob Friesenhahn
2004.09.22 03:52 "RE: [Tiff] libtiff and .net", by Bill Bither
2004.09.22 04:13 "RE: [Tiff] libtiff and .net", by Bob Friesenhahn

2004.09.20 19:48 "RE: [Tiff] libtiff and .net", by Bob Friesenhahn

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.

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?

Bob
======================================
Bob Friesenhahn
bfriesen@simple.dallas.tx.us
http://www.simplesystems.org/users/bfriesen