TurboActivate 4.0 is massively overdue [Out now]

Another month has gone by and still no updates on version 4.0. For any other developers that read this forum, you probably already know that version 4 has been touted for almost a year now as the solution to many known bugs. It has been promised to solve the terrible network adapter fingerprinting, constantly having to reactivate, bugs with the linux implementations, virtual machine issues, and many other things that are listed on this forum. If you read through the latest 20 posts on this forum, you'll see it's pretty much given as the solution to every problem - "we will fix this in TA 4.0" or "this will get better once we release version 4.0".

That's fine and good, but the problem is that this version was originally promised almost a year ago and seems to be insanely behind schedule. Here's a brief history of the communication:

December 4th, 2015nickdademo wrote:> What is the ETA of v4?Sam wrote:> A few weeks away.

December 9th, 2015Sam wrote:> Sorry guys, the 4.0 final release is coming before Christmas. If we take> time out to make & test another pre-release that date could slip.

December 23rd, 2016Sam wrote:> No, it's coming in the first 2-weeks of January. We need to do more> testing, and update the documentation.

March 27th, 2016Wyatt wrote:> We're working hard to get it out by the end of March. We're almost there.> This is a big, atypical release (because of all the things we needed to> do). Future releases won't take as long.

April 3rd, 2016Wyatt wrote:> Sorry, I should communicate *potential* release dates better. When I say> "TurboActivate 4.0 is coming at the end of March." I mean> "TurboActivate 4.0 is coming at the end of March *barring no> unforeseen complications in the rollout*".> > We had an unforeseen complication that set us a week behind schedule.

April 19th, 2016Wyatt wrote:> Yes, there's a high chance it will be released this week *barring no> unforeseen problems*.

May 13th, 2016Wyatt wrote:> We're wrapping up documentation writing and final testing.

June 8th, 2016Wyatt wrote:> It's coming soon. We're doing tests, fixing last minute bugs, writing> documentation.

July 4th, 2016Wyatt wrote:> All that remains is a couple of bug fixes and finishing the documentation.

I'm sure all the developers out there understand that things can easily slip behind schedule, but 12 months behind schedule is absolutely ridiculous! It's absurd for any software company to not release an update for almost a year. On top of that, it is seriously concerning to have all of the estimates be so far off. That either means the product had 6 months worth of bugs that needed fixing (not encouraging) or things are just so chaotic that this the team had zero clarity on when the product would actually reach the market. Your customers are seriously concerned, and I think it's important to show why.

And yes, I'm sure promises can be made about how thing will be better in the future, but it's pretty clear from above that promises don't necessarily mean much. So please finish the version that was already promised almost a year ago so that we can finally be done with all of the known bugs in the current version. It's incredibly frustrating to continue upsetting our own customers due to issues with a product that was promised to be fixed almost a year ago.

I hear you and your frustration is completely understandable.

Without a doubt several things need to improve:

1. Our communication needs to improve. This includes our ability to accurately estimate time, and when things slip, determine why they slipped, whether it was preventable, and determine a new more accurate time.

2. Our roll-out of fixes needs to improve. Several large fixes were rolled up with several large features. And that "bundling" delayed the release of fixes. We won't do this "bundling" in the future. It was a mistake.

3. We need to hire more developers. Right now our developers are spread thin (including answering support requests).

All of these things will be rectified after 4.0 is released. I'm truly sorry for the delays.

TurboActivate 4.0 is now out: https://wyday.com/limelm/api/

I'll be posting a blog post shortly.

C O N G R A T U L A T I O N S.

I hope all goes as well as you hope it does.

Thanks, Ewen!

Congratulations Wyatt!

I have downloaded and make a quick attempt to integrate.

First impressions:

1. You have some missing "Native" qualifiers for ACTIVATE_OPTIONS within the Native64 class. No big deal but it does break the build with TA_BOTH disabled.

2. I can't activate on my development machine due to - apparently - disabled network adapters on my system. As far as I can tell, I do not have any disabled network adapters, and am unable to proceed beyond this point for now.

I do have 2 x wireless adapters, only one of which is in use (other is not disabled, however). Various other adapters also not in use but nothing shown as disabled in device manager.

Just in terms of upgrading from v3 - is there anything major we need to be looking out for? What is the best practice as regards the, now non-static, TurboActivate class? Create a new instance as required or store a single one somewhere?

thanks,Matt

>> "Congratulations Wyatt!"

Thanks, Matt!

>> "1. You have some missing "Native" qualifiers for ACTIVATE_OPTIONS within the Native64 class. No big deal but it does break the build with TA_BOTH disabled."

You're right, we've fixed this and it will be in a bug fix release (probably within the next 2 weeks). The fix in the meantime is to just change "ACTIVATE_OPTIONS" to "Native.ACTIVATE_OPTIONS" in the Native64 class.

>> "2. I can't activate on my development machine due to - apparently - disabled network adapters on my system. As far as I can tell, I do not have any disabled network adapters, and am unable to proceed beyond this point for now."

Go into the "Network devices" control panel. Do you see any "greyed-out" devices? Those would be the network devices that are disabled. You can either re-enable them there, or run your app as admin and TurboActivate will temporarily re-enable them to read their device info.

Also note: TurboActivate will cache this data for a while so customers can continue disabling network adapters.

>> "Just in terms of upgrading from v3 - is there anything major we need to be looking out for? What is the best practice as regards the, now non-static, TurboActivate class? Create a new instance as required or store a single one somewhere?"

We have an article about this planned, but we wanted to get TA 4.0 out the door. But yes, all languages now use "instances" of some sort, rather than static methods. This is part of the new thread-safe design.

We show how to do this in all of the examples, but yes, just create a class instance, save it to a variable, and then pass that variable around your app. Or, if it's more convenient not to pass that variable around you can create new class instances in different parts of your app (it will just use more memory).

There aren't any big "gotchas". We worked incredibly hard to make sure customers could seamlessly upgrade their fingerprints to the new more accurate algorithm, and TurboActivate seamlessly handles that behind the scenes.

Let me know if you have any other questions.

>>Go into the "Network devices" control panel. Do you see any "greyed-out" devices? Those would be the network devices that are disabled. You can either re-enable them there, or run your app as admin and TurboActivate will temporarily re-enable them to read their device info.

The problem is, I don't. I also tried running TA.exe as administrator, and I get the same error. So my concern is - whatever is going on on my computer - that this error may be rather common (given a one-from-one attempt so far).

I am using CSharp, and the missing qualifiers are in TurboActivate.cs. Not a big drama for me, but maybe off putting to new customers when it won't build "out of the box". And I meant to say TA_BOTH *enabled*, not disabled, in my earlier post.

thanks,Matt

>> "The problem is, I don't. I also tried running TA.exe as administrator, and I get the same error. So my concern is - whatever is going on on my computer - that this error may be rather common (given a one-from-one attempt so far)."

We haven't been able to reproduce this with any of our testers on any of our computers (internally, or our customers who beta-tested). So this is some pretty bad luck. But we want to get this fixed ASAP.

Can we schedule a time to do a remote debug of this issue? Are you free this coming Tuesday (September 6th)? What the remote debug will consist of is me calling you, getting access to the computer you're running using one of the screen-sharing services, and then working through the problem to see what's up.

>> "I am using CSharp, and the missing qualifiers are in TurboActivate.cs. Not a big drama for me, but maybe off putting to new customers when it won't build "out of the box". And I meant to say TA_BOTH *enabled*, not disabled, in my earlier post."

You're right, we've updated the archive with the fixed classes.

Tuesday won't work, but later in the week might.

OK - some slightly weirder extra information. Two of my adapters offer me the option to "enable" them in the right-click menu of the device manager, even though they don't show as disabled. Furthermore, I know full well that at least one of these is enabled because I am connecting to the internet through it right now - a TP Link Wireless USB adapter. Choosing "enable" from the right-click menu switches that menu option to "disable" (i.e. it suggests that something changed), but closing and reopening the device manager once again reverts both of these adapters to having "enable" as an available option in the menu. That sounds to me like some weird Windows stuff going on (8.1, FWIW), but again - how common are these issues going to be? I have a *very* unsophisticated user base.. something like this will simply floor them.

>> "Furthermore, I know full well that at least one of these is enabled because I am connecting to the internet through it right now - a TP Link Wireless USB adapter."

Hmmm... that's very odd. My first instinct is that this is a bug in your network drivers, but if it was a bug like that it likely wouldn't effect 2 separate network adapters.

But the first thing you should do is google those network adapters and get the latest drivers. I doubt this is the solution, but it's worth a shot.

Do you have any sort of "internet managers" or 3rd party network managers of any sort? My guess is that if you do, they might be pulling some shenanigans of some sort.

>> "That sounds to me like some weird Windows stuff going on (8.1, FWIW), "

Well, my guess is this is not Windows at all. It sounds like some 3rd party software or driver is messing with things. I would bet that if you re-installed Windows everything would just work. But I also realize that's not a feasible solution. So I want to get to the bottom of this (whether that means modifying TurboActivate to disable 3rd party software that pulls these shenanigans, or by writing a FAQ describing how to deal with it).

>> "but again - how common are these issues going to be? I have a *very* unsophisticated user base.. something like this will simply floor them."

None of our testers internally, or any of our beta-tester customers experienced anything like this. So I would say these issues won't be common at all. But I need more information about this issue.

>> "Tuesday won't work, but later in the week might."

OK, I'll work around your schedule. Whatever day/time works for you.

Hi Wyatt,Bad news I'm afraid - the problem has gone away, after I played with my network adapters a bit (disabled and re-enabled them, as opposed to just trying to enable them). I would have preferred to have helped you to understand what was going wrong here, as I worry it will happen in the field - but I'm afraid I couldn't help meddling.. Now, FWIW, the activation works always - even if I deliberately disable a few network adapters.Matt

I'm having similar problems with v4.0.2...

Running TurboActivate.exe reports that there are some network adapters disabled - even though none are. Activation fails.

@Wyatt: What additional info do you need to debug this? OS is Windows 7 - using x64 build of TA. Three physical adapters present: USB RNDIS, LAN (Intel I218-V), WLAN (Intel 7260)

We're going to try to reproduce this, but are you free tomorrow or sometime this week for a remote debug?

Wyatt wrote:> We're going to try to reproduce this, but are you free tomorrow or sometime> this week for a remote debug?

The problem solved itself after disabling and enabling the LAN adapter... Strange.I suspect it was in some sort of strange state because I couldn't access the Advanced properties of the adapter through Windows either. I read somewhere that TA does some enabling/disabling of adapters behind-the-scenes - in what circumstances does this occur?

TurboActivate re-enables the adapters when it reads them as being disabled. It also only does it when run as admin.

So, if you ran TurboActivate as an admin and it didn't re-enable the adapters, then something was in a bad state. We're going to try to reproduce this on our end, but please let me know if you can reproduce this bad state.

Wyatt wrote:> TurboActivate re-enables the adapters when it reads them as being disabled.> It also only does it when run as admin.> > So, if you ran TurboActivate as an admin and it didn't re-enable the> adapters, then something was in a bad state. We're going to try to> reproduce this on our end, but please let me know if you can reproduce this> bad state.

OK - this is what I just performed:1) All network adapters are in an enabled state.2) Run TA as admin. TA reports product is activated, but leaves WLAN and LAN adapters in disabled state.3) Adapters must be re-enabled manually in Windows. Afterwards, product is still activated.

So not a huge issue as I won't be running TA as admin, but the above seems like unexpected behaviour (TA should re-enable the adapters).

What TurboActivate does is:

1. Reads the current state of the adapters (enabled or disabled).2. If it needs to read the adapter info from a disabled adapter, then it attempts to re-enable that adapter temporarily.3. After it successfully reads that adapter, it then puts it back in the disabled state (ONLY if it was in that state in step 1). The reason we do this is to "leave the computer like we found it".

In other words, something on your computer is putting your adapters in bad states (both enabled and disabled at the same time). Are you free later this week to do a remote debug on this issue? I'm 99% sure this is a bug in something on your computer (my guess is some "helper" networking utility). But it will be useful to get to the bottom of this so we can either (a) write a FAQ about this for any potential customer running into this issue or (b) workaround this 3rd party bug directly in TurboActivate.

Sure.

So it seems that TA is reading the wrong state of both adapters then (erroneously seeing them as disabled when they are not).

I can give you access via TeamViewer this week - but of course, TA will kick you out once it disables the adapters (when running as admin).

When suits you? I'll PM you my details.

Thursday (the 8th) works best for me, and we'll have some time to try to reproduce this here, and make some tools that will make getting to the bottom of this easier.

Eastern time in the U.S. works best for me as well.

You can email me at wyatt@wyday.com and tell me what date/time works best for you.

TurboFloat static finally! I'll upgrade immediately.Thanks Wyatt (and your team too): your product is still the best.

I'm glad you like our work, it really means a lot. 🙂

>> "So it seems that TA is reading the wrong state of both adapters then (erroneously seeing them as disabled when they are not)."

Thanks, Nick, and thanks for letting me remotely debug this on one of your machines. We've released TA 4.0.3 that fixes this bug and the bug Matt was seeing: https://wyday.com/limelm/api/

Good stuff Wyatt!

Greetings,

Congrats on the 4.0 release!

I'm having an issue with 4.0.4 and network adapters. I've tested my code on my dev machine and am able to call TA_UseTrial. However, on one of my test VMs (Windows 10 Pro running in a HyperV VM with Windows 8.1 host) I get the 28 error code when calling TA_UseTrial. I checked that the network adapter (which is idenftified as "Microsoft Hyper-V Network Adapter) was Enabled, tried Disable and Re-enable, and even rebooted the VM but still get the 28 error code. This Windows 10 VM has all the latest updates from Microsoft. I'm not sure how specific this is to my setup and I'm hesitant to start rolling out to customers until I better understand what is happening.

Was Windows 10 Pro under HyperV evaluated during development? Anything else I should be checking?

Many thanks,

erik

Hey Erik,

We have 4.0.5 coming out later today that fixes this bug (and a handful of other bugs). Sorry about that.

Thanks Wyatt, glad to hear there's a fix at hand, looking forward to it

Wyatt wrote:> Hey Erik,> > We have 4.0.5 coming out later today that fixes this bug (and a handful of> other bugs). Sorry about that.

TA 4.0.5 is now out and fixes this bug.

Looks good, thanks!

Wyatt wrote:> TA 4.0.5 is now out and fixes this bug.