Jump to content
The simFlight Network Forums

auto-registration of add-on problem


Recommended Posts

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.