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.22 04:13 "RE: [Tiff] libtiff and .net", by Bob Friesenhahn

On Tue, 21 Sep 2004, Bill Bither wrote:

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?

The port would allocate its data on the traditional unmanaged heap. To do anything else would be a re-write rather than a port.

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

The first release of Visual Studio .net supported compiling both unmanaged and managed code into the same assembly and into MSIL. This has been released for several years.

I have used Managed C++ for .NET. It worked fine. However, the use of the term "C++" is a misnomer since all managed object interfaces must obey Managed C++ rules, which disables many useful C++ features and substitutes something else in their place.

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 "syntax additions" were already part of the first release of Managed C++. However, only managed code was allowed to access managed memory in order to assure the safety of the run-time. Has that changed?

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.

That is just a compiler option. However, any interfaces other than to .net types will result in calls from .net into traditional C libraries so using them makes the assembly non-portable.

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