auto-registration of add-on problem

[zip]

Hello!

A couple of people who have downloaded my freeware gauge on AVSIM had problems with my automatic registration via offset 0x8001. Both users were using FSUIPC unregistered, version 3.22, running on XP.

A manual registration worked for them.

The automatic registration was tested on several machines without the registered copy of FSUIPC, and was found to work correctly. The problem doesn't appear to be widespread (less than 1%).

Is it a good idea to go ahead and automatically modify the fsuipc.key file instead?

Thanks for any suggestions.

[Pete Dowson]

A couple of people who have downloaded my freeware gauge on AVSIM had problems with my automatic registration via offset 0x8001. Both users were using FSUIPC unregistered, version 3.22, running on XP.

A manual registration worked for them.

The automatic registration was tested on several machines without the registered copy of FSUIPC, and was found to work correctly. The problem doesn't appear to be widespread (less than 1%).

This is undoubtedly due to the fact that you've probably missed out the final terminating zero byte on the string you send to offset 8001.

The result of this error is indeterminate -- it depends whether anything else has written to that area before your gauge -- it a Gauge or DLL with a longer name wrote its registration there first, then the apparent name of your gauge will be wrong, it will be longer because of your missing zero!

This would have also been the case before 3.22, but due to this improvement in FSUIPC 3.22:

A general tidy-up of the logging of registration problems with gauges and modules has been included in this version. It should be a lot clearer to see exactly what is wrong when using an unregistered copy of FSUIPC.

as listed in the History document, all such cases are now detected and reported.

Because so many gauge programmers seem to have made this same error, despite the specification being quite clear on the point, I have actually made changes in FSUIPC version 3.30 to hunt down the ".gau" or ".dll" in the name and insert a zero myself, but this really should not have been necessary.

Regards,

Pete

[zip]

Ok, I will force a 0 there (the compiler should normally place one there but it may not be written).

Thanks.

[Pete Dowson]

Ok, I will force a 0 there (the compiler should normally place one there but it may not be written).

In C and C++ there is always a zero at the end of a string. You are not using "strlen()" are you? If so, just add 1 -- as you will see, if you check, strlen() counts the characters up to but not including the zero terminator.

It is more efficient in any case to declare the string as a character constant (i.e. char xxx[] = "...";) and use "sizeof" to place the length in the FSUIPC_Write. The sizeof will include the zero and will be more efficient because it isn't counting bytes at run time.

Regards,

Pete

[zip]

Yes, of course. And no, I didn't use strlen (in my quest to save CPU cycles). I used a hard coded value, and I always preach never to use hard coded values, and got bitten by it once more, to prove my theory: expect the unexpected. So, I have a HUGE comment to this effect.

I did add a double zero (\0) at the end for good measure and making sure it's a single byte string as well.

It's a classic bug caused by classic inattention.