DotNET 2005 libs


#1

Do you expect to support .NET 2005 at some time Jake ?


#2

It is supported when using the DLL. I believe it should also work just fine with the current libraries (built with Visual Studio .NET), though we have not tried it. Are you having difficulty?

Is 2005 out of beta yet?


#3

Yep, 2005 is out of beta:rolleyes:
Building my app with 2005 causes a
“Heap Corruption Error: CRT detected that the app wrote to memory after the end of heap buffer”

The errant function is in the GetDeviceCount() function, tracing through the disassembly shows that a call to okUsbDevice::GetDeviceList() asserts the runtime error noted above.
Ken.


#4

I’ll look into this and see if there is a memory leak there. Thanks for providing the error message.


#5

Hi Jake,

I Downloaded FrontPanel V1.3.1 today , still getting the runtime “Heap Corruption error” when compiling with VS 2005. do you require any further information ? , stack dump etc.
Thanks, Ken


#6

Jake,

Using the _CrtDumpMemoryLeaks() function, returns the following, maybe of some use to you :

Detected memory leaks!
Dumping objects ->
{215} normal block at 0x0093B3E0, 36 bytes long.
Data: < > 80 B3 93 00 80 B3 93 00 00 00 00 00 CD CD CD CD
{214} normal block at 0x0093B380, 36 bytes long.
Data: < > E0 B3 93 00 E0 B3 93 00 CD CD CD CD CD CD CD CD
{213} normal block at 0x0093C010, 36 bytes long.
Data: < > 20 B3 93 00 20 B3 93 00 00 00 00 00 CD CD CD CD
{175} normal block at 0x0093B320, 36 bytes long.
Data: < > 20 B3 93 00 20 B3 93 00 CD CD CD CD CD CD CD CD
{174} normal block at 0x0093B2C0, 36 bytes long.
Data: < > C0 B2 93 00 C0 B2 93 00 CD CD CD CD CD CD CD CD
{173} normal block at 0x0093B278, 8 bytes long.
Data: < > 00 00 00 00 01 CD CD CD
{172} normal block at 0x0093B1B8, 128 bytes long.
Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
{171} normal block at 0x0093B0F8, 128 bytes long.
Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
{170} normal block at 0x0093B038, 128 bytes long.
Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
{169} normal block at 0x00938988, 12 bytes long.
Data: < > 88 89 93 00 88 89 93 00 CD CD CD CD
{168} normal block at 0x0093AFC0, 60 bytes long.
Data: 78 B2 93 00 38 B0 93 00 F8 B0 93 00 B8 B1 93 00
Object dump complete.


#7

So you see this error when using the DLL?


#8

Tried using the DLL under 2005, Library loads OK and can create the xem & pll objects OK but calls to functions returns 0, so I cant open the device or do anything else, works fine under 2003 though. Looks like the new 2005toolchain has Issues:rolleyes: . I think I will ditch 2005 for the time being.

Cheers, Ken.


#9

Hi Ken-

We will eventually get 2005 going here. Unfortunately, there are still many users out there that are still on VS 6. I think when we move to 2005, we will be driving to support only the DLL version (with a compilable C++ wrapper so that it can look like the current library).

That way, we won’t need to support 3 versions of MS compilers.


#10

Hi Jake-

That certainly sounds like the best option. The only reason I tried 2005 is because I got given an MSDN universal subscription, so I got a copy of everything :smiley: . , personally I still much prefer assembler, oops, showing my age there…

By the way, great product, makes prototyping an absolute breeze :slight_smile:

Cheers, Ken.


#11

Hi Ken-

We work on the universal subscription, too. Much like drinking from a firehose. It was a surprise when we learned how many customers were using VS 6. I think it was a very popular version and many folks resisted change or did not want to pay to upgrade.

I can certainly understand. Once you have momentum, changing anything is a large undertaking.