reserve offsets possible ?

[PhilippeV8]

I see that Project Magenta has an area reserved for, what I think, passing their variables in & out of FS via widefs.

My question now is: is it possible to reserve a small zone to use ?

Espens panel doesn't use the default "ap altitude" value simply because as soon as you edit that one, the plane wil start going up/down which is not done in real.

Other than that it would be great to be able to get a list of bits to read so that it would be possible to know the status of leds.

Now if I press a (real) push-button in the sim the led will go on but if for some reason the signal doesn't make it to FS, the option (e.g. HDG hold) is still of. Same way for starting situation. Maybe a led is off in my sim and not in FS and when I push the button to turn the option on, actually I turn it off.

Maybe there is already a way to make use of the PM zone ? Since I don't use PM stuff those values are never used ?

[Pete Dowson]

I see that Project Magenta has an area reserved for, what I think, passing their variables in & out of FS via widefs.

Yes. There are actually two areas. And they are not used just for PM talking to itself, they are used for external control and information too. This is why Pm publish the details on their documentation page. FSUIPC makes use of these areas to provide tne special "PM" controls in its Keys and Buttons programming pages.

My question now is: is it possible to reserve a small zone to use ?

Possibly. For what project? .... what talking to what?

Espens panel doesn't use the default "ap altitude" value simply because as soon as you edit that one, the plane wil start going up/down which is not done in real.

Other than that it would be great to be able to get a list of bits to read so that it would be possible to know the status of leds.

Now if I press a (real) push-button in the sim the led will go on but if for some reason the signal doesn't make it to FS, the option (e.g. HDG hold) is still of. Same way for starting situation. Maybe a led is off in my sim and not in FS and when I push the button to turn the option on, actually I turn it off.

But to get details from a third party panel into FSUIPC offsets and vice versa will need programming in that panel. Pr are you the panel maker?

Maybe there is already a way to make use of the PM zone ? Since I don't use PM stuff those values are never used ?

Pm uses them for their documentated purposes. How would you propose to use them?

If you are a programmer and need to get stuff from your programmed panel to somewhere else, or vice versa, there are a number of ways you could probably do it. The 767PIC implementation, for instance, did it by having an interface DLL. I think PMDG are contemplating something similar. The advantage of using FSUIPC offsets is that you can network things via WideFS then, and program Buttons and Keys using FSUIPC instead of having to support both in you panel.

Regards,

Pete

[Pete Dowson]

I see that Project Magenta has an area reserved for, what I think, passing their variables in & out of FS via widefs.

Yes. There are actually two areas. And they are not used just for PM talking to itself, they are used for external control and information too. This is why PM publish the details on their documentation page. FSUIPC makes use of these areas to provide the special "PM" controls in its Keys and Buttons programming pages.

My question now is: is it possible to reserve a small zone to use ?

Possibly. For what project? .... what talking to what?

Espens panel doesn't use the default "ap altitude" value simply because as soon as you edit that one, the plane wil start going up/down which is not done in real.

Other than that it would be great to be able to get a list of bits to read so that it would be possible to know the status of leds.

Now if I press a (real) push-button in the sim the led will go on but if for some reason the signal doesn't make it to FS, the option (e.g. HDG hold) is still of. Same way for starting situation. Maybe a led is off in my sim and not in FS and when I push the button to turn the option on, actually I turn it off.

But to get details from a third party panel into FSUIPC offsets and vice versa will need programming in that panel. So, are you the panel maker?

Maybe there is already a way to make use of the PM zone ? Since I don't use PM stuff those values are never used ?

PM uses them for their documentated purposes. How would you propose to use them?

If you are a programmer and need to get stuff from your programmed panel to somewhere else, or vice versa, there are a number of ways you could probably do it. The 767PIC implementation, for instance, did it by having an interface DLL. I think PMDG are contemplating something similar. The advantage of using FSUIPC offsets is that you can network things via WideFS then, and program Buttons and Keys using FSUIPC instead of having to support both in your panel.

Regards,

Pete

[PhilippeV8]

Tnx for the info.

The software is my self written Photon interface software (for now still 100% personal use ((I am currently the only Fokker50 sim builder))). http://www.iflightsystems.com sells a hardware interface to enable you to interface switches / buttons / leds / 7-seg. led displays. That's what I got and although the software is also available I chose to make my own. This way I have maximum control over what is going on + his version of software is more focused on Boeing & Airbus.

No I am not the panel programmer though Espen Oijordsbakken is and evern since I started building or even planning my home simulator he has been 100% co-operative towards it.

As said the idea is to get the AutoPilot ("target") altitude value out of FS, trough fsuipc into my software (so that i can project it onto the segment displays in the sim). So that's is a 3 bit value. ( altitude goos 5 integers though last 2, as you know are 0 always).

Other than that it would be great to be able to read a string of bits indicating which led is on, which one is off.

Mostly that is for the push switches of the glare panel and some of the overhead.

I have no idea how the offset zone for PM is managed or what it does, however I will check their site to see if maybe it could be usefull. If so, there is no need for you to create an extra zone. Maybe you can tell me already before I finish the PM info if it could be used for passing those kind of data out of FS. (no write, just read!)

[PhilippeV8]

4E4 MCP/FCU Altitude (Read Only) (100 of feet, i.e. 3000 ft = 30, 31000 ft = 310)

Awesome. That's 1 down, couple more to go :D

If Espen manages to put his AP alt value into that offset I can read it no problem :wink:

[PhilippeV8]

Ok, if I get this right, Pete, this "zone" can be seen like a string of bits, which PM has devided into their sub-divisions (variables of various length) so that when their software writes something in a sub-zone of this "zone" it can be read and known exactly where it can be read inside the zone or if something is read it can be told exactly what it is.

So all people using fsuipc and no PM have this zone filled with 0's ?

This would mean that all we need to do is for Espen to figure out how he can write a value to any bits or bytes from the zone and make his own sub-divisions, let me know what is where and then I can read them ?

Hope I don't get it all wrong.

[Pete Dowson]

As said the idea is to get the AutoPilot ("target") altitude value out of FS, trough fsuipc into my software (so that i can project it onto the segment displays in the sim).

The FS autopilot altitude value is already readable in FSUIPC.

If you are talking about a different value, from the panel, who is going to change the panel programming to put the value some place you can read it? This is really the question.

So that's is a 3 bit value. ( altitude goos 5 integers though last 2, as you know are 0 always).

There are some terminology problems here. 3 bits can only accommodate values from 0 to 7. You mean three decimal digits, 000-999. You could accommodate those in two bytes using BCD (Binary Coded Decimal), but little works in decimal insternally -- it would more likely be a binary value in a 16 bit word.

Other than that it would be great to be able to read a string of bits indicating which led is on, which one is off.

And, I ask, who is going to set these for you to read?

I have no idea how the offset zone for PM is managed or what it does, however I will check their site to see if maybe it could be usefull. If so, there is no need for you to create an extra zone. Maybe you can tell me already before I finish the PM info if it could be used for passing those kind of data out of FS. (no write, just read!)

There is absolutely no use in having a location which is "read only" with nothing being written to it! Please think this through a bit further. Just what is writing these values to whatever locations we agree upon so you can read them?

This was the main thrust of my last message, where I was asking what is talking to what -- you've now said what is reading the stuff, but not what is writing it!

Regards,

Pete

[PhilippeV8]

Hèhè Pete,

I told you already.

First sorry 'bout the confusion I had. Indeed you need more than a 0 or a 1 to show a single integer (2 to 9). For the led status however a bit would do.

Then to tell you some more 'bout who is going to write: Espen is.

Espen Oijordsbakken ( http://www.fokker50.com ) made a fokker50 panel for FS95 I think which has been updated and evolved troughout all FS versions till today.

I keep close contact with him because my home sim is based upon his panel. E.g. if his panel is not interfacable via the keyboard, then it is not possible to build a home sim around it. I can not tell a button press to use the mouse and click on a panel that is not on my screen. So I asked him if he would change his panel code so that that would be possible for me. He accepted and by now almost all the functions of his panel are controlable via keyboard commands and combo's.

Same way I would ask him to change the code of his panel so that it would do a little bit more than what it is doing now. Meaning writing all data which I would like to read trough widefs into my software to the PM zone (if possible).

If I understand it correct then the PM zone is wide open and free to use as long as one doesn't have the PM software or doesn't use the PM lines from the FSUIPC gui (wouldn't be interesting to use the PM variables in the FSUIPC gui if one has no PM software anyway :lol: )

So it comes down to this: Espen should try to figure out how he can write some of his variables into that zone and let me know exactly what is where and then all I have to do is read them.

Is there anywhere info on how he should do this ? I remember passing over a section in the developers guide telling about how internal (FS) gauges can acces fsuipc variables. Is that the part I should forward to him ?

[PhilippeV8]

Ow and as to why not use the default FS autopilot altitude variable .. simple.

If you change that one,e.g. I am flying on autopilot at FL100. I turn the knob to increase the value to FL120. If you use the default variable, FS will edit the virtical speed variable straigt away to climb (in this case).

This is not realistic at all and is not at all the case in ANY airplane that we know off. Speically not the airliner type. That is also why PM uses this zone for passing their own ap-altitude value and chose not to use the default.

If MS would change their code and not make FS do this, then we could all use this default variable as you say we should. But as long as those 2 things are linked .. there is no use of it for us cockpit builders.

[Pete Dowson]

Then to tell you some more 'bout who is going to write: Espen is.

Espen Oijordsbakken ( http://www.fokker50.com ) made a fokker50 panel for FS95 I think which has been updated and evolved troughout all FS versions till today.

Ha, so "Espens" is a person, not an aircraft? Sorry, I didn't read it so.

Okay, so Espen need to work out exactly how he is going to supply this information and therefore how many bytes in total he needs. Then he can write to me and I will find the offsets for him to write to. He will of course need to interface to FSUIPC and therefore he will need the FSUIPC SDK.

If I understand it correct then the PM zone is wide open and free to use as long as one doesn't have the PM software or doesn't use the PM lines

No, that really is not a good idea, unless Espen's aircraft is ONLY ever used by you and will never be released to anybody else.

So it comes down to this: Espen should try to figure out how he can write some of his variables into that zone and let me know exactly what is where and then all I have to do is read them.

It seems to me that the programmer should contact me directly, or are you his translator?

Is there anywhere info on how he should do this ? I remember passing over a section in the developers guide telling about how internal (FS) gauges can acces fsuipc variables. Is that the part I should forward to him ?

He needs the complete FSUIPC SDK. In particular he must use the Module User's interface, for which a library is provided.

Pete

[PhilippeV8]

No, that really is not a good idea, unless Espen's aircraft is ONLY ever used by you and will never be released to anybody else

Well as far as I know for now I am the only person building a F50 sim and if there ever will be more, for sure it will never be more than a handfull. People using Espens panel get an other version of the gau file so I got one custom made for me. If any other person would ever build F50 he would get it too probably but it is not to be distributed as a panel for normal FS users.

Secondly F50 sim builders (or builder as long as I am alone) will not use PM software simply because they don't have (yet) no F50 type gauges available. This way there is no chance of any conflict between my program and PM because I simply don't have it.

It seems to me that the programmer should contact me directly, or are you his translator?

Hèhè, no no I am not translator. He is from norway but he sure understands english well enough :) I am just the one to contact you first because I am the one who wants this made possible. Once I figure out as much as I can about how to do it, then I forward all this info to him and kindly ask him if he would edit the gauge file for my needs. Then it is up to him to contact you if he needs more info. I just want to know first if it is possible and it is indeed so I read from your answers. So I will let him know this via e-mail and will direct him to the manual which you point out and then I can only keep my fingers crossed that he will manage to make this happen :wink:

So far I am happy to know that it could be done.

One last thing from me. Now that you know that PM and my gauge files will never meet on anyones platform .. is it OK then to use the PM zone ? Then also there is no need for any change to the FSUIPC dll (don't know if that WOULD require a change if we were not to use the PM zone) .. you tell me :)

[Pete Dowson]

Well as far as I know for now I am the only person building a F50 sim

that wasn't the question. Are you the ONLY user of Espen's panel? He is writing this panel especially for you, and no one else?

People using Espens panel get an other version of the gau file so I got one custom made for me.

Ah, just one gauge, not a whole panel? Okay.

Even so, it seems to me to be a shame to re-use already allocated areas and therefore possibly cause conflicts in future. If the number of bytes required is kept small I don't mind allocating them especially.

Now that you know that PM and my gauge files will never meet on anyones platform .. is it OK then to use the PM zone ? Then also there is no need for any change to the FSUIPC dll (don't know if that WOULD require a change if we were not to use the PM zone) .. you tell me :)

There is no change to FSUIPC needed for me to allocate an area and reserve it for a specific purpose. Do not worry about that.

Regards,

Pete

[PhilippeV8]

Ah, just one gauge, not a whole panel? Okay

Don't think it is 1 gauge. It just is 1 file. As far as I can see at least. I know little about gauges and how they are made. Thats 1 of the areas of FS that I have never really looked into before.

I am not as such the only user of Espens panel, but I am the only user of this version or mod of the panel yes. It is for home sim builders only so as I said, maybe in the future if there ever would be someone building another Fokker50 home sim he would be interested in using the same mod. However most home sim builders chose Boeing or Airbus or regional jets or cessnas, so chance seems small.

Concerning conflict .. I think that if I am the only person to use this mod (or maybe 2 or 3 others in the future, who knows) than that conflict would be with PM software. But no one could tell if PM would ever make any software which would be usable from a F50 type cockpit. And even if it would .. PM specialises in software which make it such that you do not need a panel in MSFS ! :) So even if PM would ever make F50 software, that would replace Espens panel and thus create no conflict at all.

I understand your concurn. I can immagine that you and the PM folks keep good contact and if this idea I have could in any way create a conflict that could maybe harm your relationship with them. That zone is reserved for their use either way so if you OK for me to use it, they could perhaps not be OK with that. So I understand it fully.

However as said .. no chance that normal FS users will download from Espens website the same version of the panel as I got and a conflict is most unlikely to ever occur. But if you prefer to reserve some space for my project that would be ok for me too. Makes no difference really. If you want that, let me know and I'll try to figure out how many bits I would need. ( 12 for the AP altitude + 1 per led , right ? Not sure yet though how many leds that would be but I'd guess somewhat around 30 or 50. 60 would be max I think )

[Pete Dowson]

I'll try to figure out how many bits I would need. ( 12 for the AP altitude + 1 per led , right ? Not sure yet though how many leds that would be but I'd guess somewhat around 30 or 50. 60 would be max I think )

I think it is better for the programmer to design the program and derive the data needs from that. You specify the sort of information your need, he designs the code and therefore knows that data space requirements.

Besides I don't deal in bits. The altitude will be 2 bytes -- a 16 bit word. As for 60 indicators -- what have you got there? Some sort of decorative cockpit illuminations? :) .

Even so, that's only 10 bytes altogether. But it's your programmer who needs to determine this.

BTW, if this panel is not using the FS A/P to climb or descend to a selected altitude, why not have the altitude written to the normal place for the FS AP Altitude? It will only be used if the FS ALT Hold flag is set and the FS A/P is on.

Regards,

Pete

[PhilippeV8]

As for 60 indicators -- what have you got there? Some sort of decorative cockpit illuminations?

Hèhè, that's the comon mistake people make. I had this too at first. I looked at the overhead and though ow yeah like 40 push buttons and about 20 leds I want to work I ended up with more than 70 of those push buttons in total and quite a few switches and other stuff. Most of the push buttons have a led so you'd get to 40 quite fast.

If you count gear status leds (4) and glarepanel (+/- 16) then main panel has 4, pedestall has none, overhead has about 40 to 50 I don't know if I will want all of those to work right away (from the overhead I mean) but it would be preferable to leave space to go that far if I would chose to do so. I'm sure you would agree that it would be silly paying 1.50 euro per "push button with led" and have 80 of those and then not use the led Other than that you should agree that annunciators and leds bring your sim to life. And they are vital to the sim as they are in the real cockpit. F50 uses dark cockpit system so the leds should be out ideally but if something is wrong a led will go on and I want that in my sim too. Sometimes if I shift from FS to other programs for a while and then go back to flying my fuel pumps are offI want to see that from the cockpit and not only hear a warning beep beep beep .. cuz the beep could have multiple causes but if those leds are illuminated I know at once what is causing it.

BTW, if this panel is not using the FS A/P to climb or descend to a selected altitude, why not have the altitude written to the normal place for the FS AP Altitude? It will only be used if the FS ALT Hold flag is set and the FS A/P is on.

My A/P IS on and it is the one from FS. The FS attitude is used and quite a few other AP functions as well. Only not the altitude.

If we would use the altitude we wouldn't be able to use any of the rest like attitude or v/s .. so what's the use. You can not use at least 1 of the FS variables to end up realistic in any way. I never made gauges so I am not sure from own experiance, though I know very sure now that PM does it the same way (not using the altitude) and many other advanced panels do exactly the same.

I appreciate you trying to find more handy sollutions but trust me on this one. The AP alt is what we need separate from the FS defaults. There's just no other way around it. As long as FS doesn't drop this sillyness. Dito for the rudder. In FS the tail rudder is linked to the front weel. Not realistic at all. But as long as they don't make it loose from eachother we can't build a working tiller and pedal control separated from eachother.

[Pete Dowson]

My A/P IS on and it is the one from FS. The FS attitude is used and quite a few other AP functions as well. Only not the altitude.

In that case you aren't using the altitude hold option and therefore the FS AP won't use the altitude value you've entered.

I've implemented several hardware-operated versions of FLCH and ALT HOLD and both use the FS A/P exlusively. I've never found any need to invent a different altitude location for anything.

If we would use the altitude we wouldn't be able to use any of the rest like attitude or v/s

Not sure about FS's attitude hold, but the V/S hold is not connected inside FS at all. The control simply does nothing. I have implemented pitch and bank holds in FSUIPC (documented in the latest FSUIPC SDK). There's also a speed and mach hold, but those still need some tuning.

I know very sure now that PM does it the same way (not using the altitude) and many other advanced panels do exactly the same.

They implement a complete A/P, not just make a separate copy of the Altitude value. It is only this odd thing which I don't understand. Sorry.

Dito for the rudder. In FS the tail rudder is linked to the front weel. Not realistic at all. But as long as they don't make it loose from eachother we can't build a working tiller and pedal control separated from eachother.

There again, from inside the cockpit you cannot see either rudder or nose wheel in any case. The only difference between tiller and rudder is the effective steering angle. So, for the PFC Jet Cockpit, which does have a tiller, I simply implemented a more "forceful" rudder input at low speeds on the ground. As speed increases the tiller becomes less effective and the rudder becomes more effective. You can get quite good results that way.

I am not trying to discourage you from doing whatever you think is best, I just think that maybe you've not considered all the options, yet.

Regards,

Pete

[espenoi]

Hi Pete,

I have been working with Philippe for some time now modifying and adding new features to my Fokker 50 panel for him to use in his home cockpit building project.

My Fokker 50 panel is a freeware project (http://www.fokker50.com) which I have been working on since FS98.

Now, what Philippe and I would like to do is pass the altitude variable in my panel/gauge (local variable) to his external program which deals with all the switches and LEDs in his home cockpit.

The reason I have a second separate variable for the altitude is this: If you are in altitude hold mode and you change the FS altitude variable, the aircraft will immediately start climbing/descending. This is not desirable. I want the aircraft to stay on the initial altitude until I have selected a vertical mode (VS or IAS hold). Then the aircraft should start climbing/descending. And if/when I select Altitude Pre-/Select, the aircraft should level off at the new selected altitude.

I have never done any coding with FSUIPC before, so I can't really comment on whether this is the best way to do this or not.

Best regards,

Espen Øijordsbakken

[Pete Dowson]

The reason I have a second separate variable for the altitude is this: If you are in altitude hold mode and you change the FS altitude variable, the aircraft will immediately start climbing/descending. This is not desirable. I want the aircraft to stay on the initial altitude until I have selected a vertical mode (VS or IAS hold).

Yes, I think this is why many implementations don't set the altitude hold until the climb or descent is to begin.

Are you only wanting 2 bytes then? A 16-bit word for the altitude? Should I allow also for the 90 indicators you might be providing? I would be inclined just to allocate you 16 bytes and let you use them as you wish. Okay?

Regards,

Pete

[espenoi]

Two bytes should be enough for the altitude.

I'm not sure what the 90 indicators are. Maybe Philippe could elaborate on this.

Regards,

Espen

[PhilippeV8]

Espen >> the indicators are the button statuses (e.g. btnExtPower = 1 or 0, btnGlareASEL = 1 or 0etc etc.) Shortly said: every button that has a led. This way I could read those statusses from your panel code and adjust led on/off state in my sim. This way I will be 100% sure if a led in the sim is on, that that function IS on in your panel as well! Normal users can see it on your panel but I won't see your panel (or at least not all parts exept left MIP gauges and engine gauges). And I do not feel like show/hide the overhead or main panel each time i press a button to make 100% sure the signal got trough to FS and your panel.

Pete >> if "people don't set the altitude hold until the climb or descent is to begin"how then is the aircraft to maintain altitude ?

e.g. I come from FL080 to intercept the ILS. I set 3000 ft on the glare and chose descend mode. at 3000 the plane will level off, waiting to intercept the glidepath. Then before intercepting the GP, I will set e.g. 4000 ft on the glare which is the "go around altitude" for that airport. But even I change to 4000 I do not want my plane to climb or even descent! I want it to stick to 3000 so I want to maintain altitude function on untill the intercepting of the glidepath.

how do these people solve that then ?? without using a separate variable for the ap-alt as we plan to do ?

[Pete Dowson]

e.g. I come from FL080 to intercept the ILS. I set 3000 ft on the glare and chose descend mode. at 3000 the plane will level off, waiting to intercept the glidepath. Then before intercepting the GP, I will set e.g. 4000 ft on the glare which is the "go around altitude" for that airport. But even I change to 4000 I do not want my plane to climb or even descent! I want it to stick to 3000 so I want to maintain altitude function on untill the intercepting of the glidepath.

how do these people solve that then ?? without using a separate variable for the ap-alt as we plan to do ?

Well, as I said, most completely separate A/Ps are completely separate. Not just the altitude, but most everything else too.

However, in this specific case I thought that most implementations would climb if you change the altitude before the glideslope is captured. I always set up the GA after both GS and LOC are captured -- I thought such changes requested before that were to be obeyed in any case? If you suddenly realised that you were going below MDA before intercept (i.e. the 3000 was an error) would you disengage everything to climb?

But it doesn't matter. I can allocate the space when confirmed.

Regards,

Pete

[PhilippeV8]

Ok. So Espen should confirm here ?

Ow Espen e-mailed me and he expressed concurns about him having to have licence or not. Could you clear it out for us ?

Or should it just work from inside FS to write via fsuipc ?

[Pete Dowson]

Ok. So Espen should confirm here ?

Yes, that would be best. After all, it will be he who defines what he will write there.

Ow Espen e-mailed me and he expressed concurns about him having to have licence or not. Could you clear it out for us ?

Or should it just work from inside FS to write via fsuipc ?

Of course he will need an access key unless this will only be done on systems owned by folks who have paid for a full user FSUIPC registration. He should also use the Module User's interface (the one using FSUIPC_Open2 not FSUIPC_Open).

All the details he needs are in the FSUIPC SDK. If he wants to stay independent of FSUIPC for the majority of users he will need to make two versions or have some method of installing which can tell him the choice.

Regards,

Pete

[PhilippeV8]

Ok, that's clear.

After all, it will be he who defines what he will write there

Hèhè .. but it will be me telling him where to write what :P Because it is me who will be using this afterwards, not him (unless offcours he choses to build a home sim himself)

I would ask what the difference is between Open2 and Open but .. never mind :) That's info for Espen and he will probably read 'bout it in the SDK.

I do have a key for fsuipc so that should be OK then. I'd suggest him to request a key since his software is freeware (think that's possible to get a free key then, right ?) but that's no use either because I got a key and I am the only user :P No use getting a freeware key for me alone :wink:

Ok then! I think I know enough. It's all up to Espen now. I'm outa here 8)

Pete, thnx a lot ! If this thing is going to work, my sim is going to rule big time :)

Cheers,

Pv8

[Pete Dowson]

Hèhè .. but it will be me telling him where to write what :P Because it is me who will be using this afterwards, not him (unless offcours he choses to build a home sim himself)

But he is the programmer. If you ask for the altitude in character format taking 5 gitis he might say, as the programmer, that is daft and he will instead provide is as an integer in 16 bits. I don't think anyone should dictate to him exactly what format to use for anything. Yes, you may list the information you need to access, but the format and therefore the space needed is surely part of the program design.

I would ask what the difference is between Open2 and Open but .. never mind :) That's info for Espen and he will probably read 'bout it in the SDK.

Exactly. He should. But some folks seem to make the mistake nevertheless.

I do have a key for fsuipc so that should be OK then. I'd suggest him to request a key since his software is freeware (think that's possible to get a free key then, right ?)

Yes, if it is freeware then it can have a free key. That way he only need build one version. He can build the key into the program.

Regards,

Pete