What does TurboActivate.dat do?

Could you please explain the purpose of TurboActivate.dat. I don't quite see why you need both that and the product GUID.

The product version GUID is just used to confirm the correct TurboActivate.dat file is used. The TurboActivate.dat file contains all the information needed to actually license your app.

so it would be nice if this could be embedded in the exe, and then loaded by e.g. "PDetsFromBuf(char * buf, int buf_size)".

We've considered that. We might allow something like that, it just hasn't been a high priority.

>We might allow something like that, it just hasn't been a high priority.OK, maybe you could bump it up a bit. While you're at it perhaps you would consider a combined TurboActivate/TurboFloat DLL too. I can't use the static libraries as I am working with C++ Builder, so currently I have three extra files to deploy.Regards,Robin

Hi!

Consider this post a "me too": We'd also be very interested in a unified DLL for both TurboFloat and TurboActivate as well as the ability to embed the license file into my binaries, thus reducing the number of redistributables to just one DLL.

Cheers,

Oliver

I would really like to see PDetsFromBuf(), I offer a single-file SDK DLL , and asking users to manage a Turboactivate.dat file is a big negative. I know I package it as a resource, and unpack it, and PDetsFromPath(), but it just means astute devs will wonder why I am writing files to the filesystem, and it means more of a hassle.

Please include this function in an upcoming release. [PDetsFromBuf()]

While you're at it perhaps you would consider a combined TurboActivate/TurboFloat DLL too. I can't use the static libraries as I am working with C++ Builder, so currently I have three extra files to deploy.

Just use MSVC, and the static TA/TF libraries to make your own library. There's no advantage for us to combine the files.

Please include this function in an upcoming release. [PDetsFromBuf()]

We might include something like that in the future. It's not coming in TA 4.0.

I have to add myself to the "me too" list. In my own case a large reason is that I don't want to give hackers any information when I don't have to. IMHO having "TurboActivate.dll" and "TurboActivate.dat" files in the folder I might as well have a big sign up saying "start hacking here!".

p.s. I've looked at the static library options, unfortunately I'm still using VS2008. I'm going to try renaming the DLL and accessing it using GetProcAddress().

For the .dat: embedding it in my exe as a resource would be ideal.

Sorry, I didn't realize that the forum would show me as "Guest" in that last message (I was already logged onto wyday.com). Have now registered and posting a marker to ensure I'll see new messages here.

You can rename the file anything you want and load it using PDetsFromPath().

Ah, ok thanks - I'll do that! 🙂