Making my app LARGEADDRESSAWARE - Ramifications ?

Hi,
My app makes use of DLL's from Leadtool. ( version 14.5).
My app is currently 32bit but I am experiencing "SystemOutOfMemory" errors.

My problem might be solved ( on 64bit platforms ) by making my app LARGEADDRESSAWARE. This is easy enough to do.

Does anyone know if there would be any disadvantage from a LEADTOOL DLL point of view to doing this ?

Regards

This question is relevant because version 14.5 of LEADTOOLS did not have 64-bit DLLs. In later versions (currently 17), our 64-bit DLLs enable you to build 'real' 64-bit applications.

About the question itself, in theory, using this flag allows a 32-bit application to make use of more than 2 GB of RAM when the OS is capable of handling such a memory space (like x64 Windows). We haven't tried that with any of our 32-bit DLLs, but even if it works, there will still be some limitations because not all parameters in the old toolkit were created with extra huge images in mind. This means you might still run into problems with values overflowing, such as image width/height or some internal variable that nobody ever tested with huge images.

If your requirement is to handle multiple images, all of which are in the 'normal' range for v14.5, you will be less likely to run into problems.

i'm also looking for an official answer to this question.
can we have a listing of which leadtools version releases (starting from v10) are compatible with LargeAddressAware?

i feel that any version that isn't compatible actually is "faulty" and needs to be fixed.

also see the related topic at Stack Overflow: http://stackoverflow.com/questions/2288728/

Philippg,
Our moderator usually splits new questions into new threads, but in this case your question is general enough and not specific to a problem you're facing.
If you need to go into details about an actual problem at your side, please open a new thread or a new support ticket by emailing support@leadtools.com

Regarding the use of LARGEADDRESSAWARE , the above reply by Adam still applies, so does the following statement:
======================================
There is no official guarantee that older versions of LEADTOOLS such as v10 will work with this flag.
======================================

During our own testing of these versions in the past, I don't believe our engineers and QA used this flag in the test programs.

This means if you need to use this flag, you must perform your own testing and push the memory usage to its limits.

Also, even if you can consider the lack of official support for the flag a fault, I'm afraid you're raising this issue a little too late.

All versions of LEADTOOLS that lacked 64-bit support are rather old and they all went out of production long ago.

This means if you test v10 and find problems related to this flag or any other part of the toolkit, we can try to help you find a workaround, but we cannot ask our engineers to make any changes to obsolete code.

If you want to use one of the current versions of LEADTOOLS that are still in production, this flag is not needed because we have native 64-bit DLLs in these versions

thanks for your reply.

however, i need to object to your last statement "this flag is not needed because we have native 64-bit DLLs in these versions".

the reason is: we're bound to x86 / 32bit as we have dependencies to various 3rd party libraries that are available as 32-bit, only.
we're not in the position to migrate to 64-bit.

hence it's vital to us that LEADTOOLS 32-bit is compatible with x86 LARGEADDRESSAWARE.

In this case, download the free evaluation of the latest LEADTOOLS (currently v18) which has both 32-bit and 64-bit DLLs and run your tests with them. If you run into problems, open a support ticket through email or live chat and we will do our best to help you find a solution.

However, with older versions prior to v17.5, our engineers no longer make fixes or updates to these versions.