Proper procedure for programmatic application registration

[noodnik2]

3. OR you can write the Key into FSUIPC’s address space using offset 0x8001. Write it as a simple 12 character string, optionally terminated by a zero. Note that the characters are single byte ASCII only.

Is there anything more to do for application registration beyond writing the 12 byte (or 13 byte, including terminating zero) ASCII keycode string to offset 0x8001? Also, should a log entry be created acknowledging this write's success (or failure)?

I'm using the C# library which I've modified to write (and "Process") my registration key (13 bytes total - the 12 byte registration key and a single binary 0) to 0x8001 just after linking to the library, and here's what I get.

249569 Client Application: "fsrwintool" (Id=2136)
   249569 C:\Marty\Play\FSR\Rev2\GpsVideo\fsrwintool\bin\Debug\fsrwintool.exe
   249589    Product="fsrwintool"
   249589    Company="Marty Ross"
   295335     Illegal write attempt: offset 330A, size 4
   295335Program not accredited for use with this unregistered FSUIPC

The "Illegal write attempt" could be normal, since the library attempts to write its version number to the read-only offset 0x330A (however, this is expected behavior for the library, according to "FSUIPC For Programmers.doc").

But I've stepped through the code with a debugger and verified that my 13-byte registration information is being written (and processed) without any complaints from the module (as in no error code is returned and no log entry is made) before the failing write to 330A (and before any other writes). Note that it's during the "process" of this failing write that the FSUIPC dialog pops up complaining about the unregistered status of FSUIPC.

Any ideas? If I can't get this to work soon, I'll probably just opt for the first documented method for registering my application:

1. You can simply publish the Key with the program documentation, or in its “README”, and instruct the user to enter the details into FSUIPC’s Program Registration dialogue (or edit the FSUIPC.KEY file), as described in section 2 above.

[Pete Dowson]

Is there anything more to do for application registration beyond writing the 12 byte (or 13 byte, including terminating zero) ASCII keycode string to offset 0x8001? Also, should a log entry be created acknowledging this write's success (or failure)?

No, and it depends, respectively.

I'm using the C# library which I've modified to write (and "Process") my registration key (13 bytes total - the 12 byte registration key and a single binary 0) to 0x8001 just after linking to the library, and here's what I get.

First, please make sure you are using FSUIPC 3.22. Second, please turn on IPC read and write logging, then try again. Either show the log snippet here, or Zip the Log file up and send it to me at petedowson@btconnect.com.

There's not enough information here or me to help further, yet. Sorry.

If I can't get this to work soon

"Soon"?? This is the first question I've received from you about this, and when I get some information I will see what it is you have wrong. I do my best to respond quickly, but please forgive a few hours delay now and then. There are other aspects to life I have to see to on occasion! :wink:

Regards,

Pete

[noodnik2]

Thanks, Pete - that did the trick! The extra debug output in your new module helped me to find the problem and fix it (I could see that FSUIPC was getting all zeroes from my app).

For the benefit of the users of the C# library, I'll post the fix here (BTW - maybe this was already fixed in an updated version of the C# library somewhere that I didn't see??)

The overload of the "FSUIPC_Write" method accepting a "ref byte[] param" (byte array) was broken (as you will quickly see); here is the faulty code that was at the end of the method:

			int idx;
			for ( idx = (Token + 4) ; i < (Token + dwSize + 3); i++) 
			{
				IPC[idx] = param[idx];       //xfer byte array to IPC managed FifO buffer
			}

... and here's the replacement code that caused everything to start working:

			for (i= 0; i< dwSize; i++) {
				IPC[Token + 4 + i]= param[i] ;       //xfer byte array to IPC managed FifO buffer
			}

[Pete Dowson]

Thanks, Pete - that did the trick! The extra debug output in your new module helped me to find the problem and fix it (I could see that FSUIPC was getting all zeroes from my app).

Okay. Glad you got it resolved. But the IPC read/write logging should have helped you in any version, that's been there for years. It was how I developed FSUIPC for FS2000 in the first place -- running FSUIPC on FS98 to compare results.

For the benefit of the users of the C# library, I'll post the fix here (BTW - maybe this was already fixed in an updated version of the C# library somewhere that I didn't see??)

They aren't my files, but I'll just have a look to see if I can understand what you mean. (Why is C# so unlike C? :( ).

[LATER]:

Your quote from the original:

			int idx;
			for ( idx = (Token + 4) ; i < (Token + dwSize + 3); i++) 
			{
				IPC[idx] = param[idx];       //xfer byte array to IPC managed FifO buffer
			}

seems in error, for sure, as "idx" and "i" are mixed up in the 'for' statement. But the currently released version (a file called "fsuipc.cs" in the inner Zip "UIPC_SDK_CSHARP Revision 1.11") has these lines:

			for ( idx = (Token + 4) ; idx < (Token + dwSize + 3); idx++) 
			{
				IPC[idx] = param[idx - Token - 4];  //xfer byte array to IPC managed FifO buffer
			}

This looks to have almost the same effect as your replacement, EXCEPT that it seems to copy one byte less (to "Token+dwSize+3" instead of +4). Your code is certainly clearer though, and I don't understand why a new loop variable (idx) was introduced when there's a perfectly good "i" already available.

I'll take the liberty of inserting your code in place of the one there, ready for a revision 1.12. Thanks.

Why is C# so horribly long-winded and complicated compared to straight C? Is this all to do with it being "managed"? Why would anyone want it?

Regards,

Pete

[noodnik2]

I'll take the liberty of inserting your code in place of the one there, ready for a revision 1.12. Thanks.

Your welcome; glad to contribute! :D

Why is C# so horribly long-winded and complicated compared to straight C? Is this all to do with it being "managed"? Why would anyone want it?

In my experience, any language looks "long winded and complicated" until you learn it. :wink:

How is it "long-winded" and "complicated", anyways? :?

Since I learned C# (about a year ago), I enjoy coding in it over C, C++ and Java. The .NET API is very comprehensive, and is easy to learn and use in the provided IDE - it's really been a pleasure. The .NET API is responsible for much of the pleasure - gone are the unwieldy window handles and legacy apis (they're hidden); just a nice OO interface with logical names. 8)

I characterize C# as taking the best features from C++ and Java. Of course, just as there are still valid reasons to code in assembly language (depending on the requirements), I consider C, C++ or Java to be superior to C# in certain contexts. I was blown away by the performance of C#, given its extra level of interpretation (it reminds me of my surprise at the speed of Turbo-Pascal, so many years ago). :P

[Pete Dowson]

The .NET API is responsible for much of the pleasure - gone are the unwieldy window handles and legacy apis (they're hidden); just a nice OO interface with logical names. 8)

Possibly this is part of why I have problems with it. I've never liked higher level languages at all in any case. C is about as far away from the machine as I ever want to be -- C++ is too far! :)

I grew up from the machine code (hardware & bits) end of things and have always programmed bottom-up, not top-down. I hate not knowing what my programs are really doing with the machine. Windows is enough of a barrier for me without adding more artificial ones.

It all depends on your viewpoint, I guess. :wink:

I was blown away by the performance of C#, given its extra level of interpretation (it reminds me of my surprise at the speed of Turbo-Pascal, so many years ago). :P

I'll have to take your word for that :D :D

Regards,

Pete