One application, multiple instances of WideFS?

[timcrews]

Hello:

Would it be possible to run multiple instances of WideFS client on one PC, connected to instances of WideFS server on multiple computers? A single application would then display merged data from multiple instances of Flight Simulator.

I know that a single instance of WideFS server can connect to multiple WideFS clients. But from the client-side API it is not obvious that a single client could support multiple servers, or that multiple clients could co-exist on one computer. Since the SDK works by attaching to a window based on its title, and all of the WideFS client windows would have the same title by default, it would appear, at the very least, that the SDK code would have to be modified.

Thanks for any advice,

Tim Crews

GECO, Inc.

[Pete Dowson]

Since the SDK works by attaching to a window based on its title, and all of the WideFS client windows would have the same title by default, it would appear, at the very least, that the SDK code would have to be modified.

Well, you've identified the reason why it won't work -- though it isn't the SDK which works like this, it is the IPC interface mechanism designed by Adam Szofran about 8 years ago and which has been continued in FSUIPC ever since. The reason it is continued and maintained is for compatibility. If any application was changed to do it some other way then it wouldn't interface to FSUIPC. All WideFS does is extend the FSUIPC interface to other PCs, and WideClient "pretends" to be FS so that applications written to interface to FS think they are doing so.

If you are writing your own applications and you don't want to interface to FS itself you can of course do it a different way. It would be possible, for instance, to have a parameter for WideClient.ini which set the "FS Window Class" name to something other than FS98MAIN and the special FSUIPC class name to something other than UIPCMAIN. Then you'd do the same in the application program, and so be able to run more than one WideClient.

Each client could connect to a different server simply by naming a different Server and/or Port. The Port is definable in the Server too.

Regards,

Pete

[timcrews]

Pete:

I can see that you are concerned for maintaining a standard interface, as of course you must be, since a large 3rd party market relies on this.

I am not sure about this, but it seems that there might be a way to accomplish this objective without breaking existing interfaces.

Would it be technically feasible to create multiple instances of WideServer (on different PCs) with multiple instances of WideClient (all on one PC) using different port numbers? I see in the WideFS documentation under the heading "WidevieW compatibility":

WideServers with different port numbers can link to WideClients with matching port numbers, but there can only be one WideClient on one PC, as this provides the interface expected by applications and there's no way to differentiate between two or more.

But if you made the change that you proposed in your previous response, where WideClient.ini allowed specification of the FS Window Class name, then I could have multiple instances of WideClient on one machine, because the multiple instances would be differentiated by their port numbers (on the network side) and their window class names (on the programming interface side). Then I would have to change the FSUIPC SDK API to support identification of and access to these multiple instances. The resulting API would not conform to the current SDK interface. But I don't think it would prevent execution of applications that do conform to that interface, as long as they continue to use the default window class names.

I understand that you might not be terribly interested in spending time making modifications to FSUIPC just so some one-off user can create his own application that your other users will never see.

So, what if I further proposed the existence of a helper application that would change the window name of the WideClient window, after it is launched? I would prefer to propose changing the window class (so that SDK code wouldn't have to change), but I don't think that is possible after the window is created. If I used this helper application to rename each instance of WideClient to a unique window name, I would be almost where I needed to be.

I could then modify the following code in a local copy of the C SDK:

// Connect via FSUIPC, which is known to be FSUIPC's own

// and isn't subject to user modificiation

m_hWnd = FindWindowEx(NULL, NULL, "UIPCMAIN", NULL);

if (!m_hWnd)

{ // If there's no UIPCMAIN, we may be using WideClient

// which only simulates FS98

m_hWnd = FindWindowEx(NULL, NULL, "FS98MAIN", NULL);

fWideFS = TRUE;

if (!m_hWnd)

{

*pdwResult = FSUIPC_ERR_NOFS;

return FALSE;

}

}

to pass a non-null argument for the fourth parameter to FindWindowEx. This non-null argument would be the desired window name, i.e. something that uniquely identifies each instance of WideClient.

This would not require any change to the FSUIPC shared-memory file mapping interface, nor to the message protocol between WideServer and WideClient. It is purely localized to the SDK code. The C SDK code could be further modified to be a true C++ class implementation (as it seems to have once been, anyway), to support multiple instances of the interface.

I don't think even this change affects existing applications, because those applications would still use the same window class name, and the NULL window name, which would match any existing instance of that window class, even one whose window title had been changed from the default as described above.

It seems to me that there actually might be some demand for the capabilities that this multi-client support would provide. There could be plenty of interesting applications that worked with merged data from multiple FS simulations, in addition to the capabilities that are already present with multi-player.

I would of course be willing to contribute any modifications back to the user community.

Tim Crews

GECO, Inc.

[Pete Dowson]

I am not sure about this, but it seems that there might be a way to accomplish this objective without breaking existing interfaces.

No, your applications would have to be changed to find a separate Window (by a different Class name), they depend on finding the window to Send the messages to.

Would it be technically feasible to create multiple instances of WideServer (on different PCs) with multiple instances of WideClient (all on one PC) using different port numbers?

Yes to the Servers (I said that already), no to the Clients on one PC -- you can have several servers on different PCs and several clients on separate PCs, this would be used in a Multiplyer or WidevieW linked multi-cockpit set up, for instance, and has always been possible. Because of the way the Window class name is used to allow applications to find and link into the system there can only be one of each (Server or Client) on each PC.

But if you made the change that you proposed in your previous response, where WideClient.ini allowed specification of the FS Window Class name, then I could have multiple instances of WideClient on one machine

Yes, I said that in my original reply.

Then I would have to change the FSUIPC SDK API to support identification of and access to these multiple instances. The resulting API would not conform to the current SDK interface.

Yes, but this would be your own private SDK version. I'd rather you made your own, with a different name, else it could get dangerously confusing. The source is provided in any case.

But I don't think it would prevent execution of applications that do conform to that interface, as long as they continue to use the default window class names.

You'd have to change/recompile your applications. It wouldn't be any good for existing applications that you don't have the source to, unless you patched the different classnames into the binaries.

I understand that you might not be terribly interested in spending time making modifications to FSUIPC just so some one-off user can create his own application that your other users will never see.

It isn't a change to FSUIPC. It is nothing to do with FSUIPC. It is only allowing the class names (FS98MAIN and UIPCMAIN) to be changed by parameter in WideClient only. Nothing else of mine is affected.

So, what if I further proposed the existence of a helper application that would change the window name of the WideClient window, after it is launched? I would prefer to propose changing the window class (so that SDK code wouldn't have to change), but I don't think that is possible after the window is created. If I used this helper application to rename each instance of WideClient to a unique window name, I would be almost where I needed to be.

You mean the Window Title text? Yes, you could do that. But at present WideClient won't load twice. It checks that there's not already any top-level window of "FS98MAIN" class already running. It does this to (a) stop trying to compete with FS itself for applcations to interface to it, and (b) to prevent having two copies of WideClient running with random applications attaching to each.

This would not require any change to the FSUIPC shared-memory file mapping interface, nor to the message protocol between WideServer and WideClient.

It wouldn't, any way you did it. It would only ever be WideClient and the applications concerned.

It is purely localized to the SDK code.

Not my SDK. It would be your local code, or not an SDK any more.

I don't think even this change affects existing applications, because those applications would still use the same window class name, and the NULL window name, which would match any existing instance of that window class, even one whose window title had been changed from the default as described above.

Yes, but in that case how do you get the applications to talk to the server you want them to? You have to do something to the applications.

I would of course be willing to contribute any modifications back to the user community.

Hmmm. It would need to be very carefully labelled, renamed, distinguished. I wouldn't want to cause the sort of confusion and problems that could arise should it be used unwittingly!

Regards,

Pete

[timcrews]

Pete:

No, your applications would have to be changed to find a separate Window (by a different Class name), they depend on finding the window to Send the messages to.

In my previous message I did propose modifying the call to FindWindowEx in the SDK FSUIPC_Open function, so that it would find the specific desired instances of WideClient. These instances would be distinguished by their window title (not window class). I thought this would be a clever approach, because currently NULL is specified as the window title, and this acts as a wild card. This opens up the possibility of making a backwards-compatible change that allows more specific behavior without affecting the previous "wild-card" behavior.

As for the changes to my (as yet non-existent) applications, it would be a simple matter to add the desired window title to the argument list for FSUIPC_Open. If this were C++ code, I could even go so far as to provide a NULL default value for the desired window title argument, which would result in the "old" behavior of matching the window only by its window class name, without any changes to existing application code. But if the caller of FSUIPC_Open provided a window title argument, then this title could be used to differentiate between multiple WideClient instances.

Yes to the Servers (I said that already), no to the Clients on one PC

I do not intend to waste your time by repeating questions. In this case, my "would it be technically feasible" question was meant as a polite introduction to a more detailed technical proposal. I'm sorry I appeared to not be paying attention.

Yes, I said that in my original reply.

You did say it would be possible to add an option to WideClient.ini to specify the desired window class. But you began that paragraph with "If you are writing your own applications and you don't want to interface to FS itself." I certainly _do_ want to interface to FS. The approach I am proposing involves your described change to WideClient.ini (actually, a slight modification to your described change), _and_ my application interfacing to FS itself.

Yes, but this would be your own private SDK version. I'd rather you made your own, with a different name, else it could get dangerously confusing.

I could create my own private SDK version, and I am willing to do so if necessary, but I was starting to feel hopeful that there was a way to accomplish the desired functionality by an enhancement to the existing SDK, without breaking the interface that current applications use, as more specifically described at the top of this message (but a better approach is proposed below).

I agree that two incompatible versions of the same interface would be problematic.

You'd have to change/recompile your applications. It wouldn't be any good for existing applications that you don't have the source to, unless you patched the different classnames into the binaries.

I haven't written any applications yet, so whatever I do write can conform to any crazy SDK interface I come up with. Since these applications are private, I could have private applications interfacing to a private SDK version, and this would be workable and should not cause any harm to the outside world.

But if we use window title instead of window class to differentiate between multiple instances, then I still think there is a possibility of preserving the existing interface, so that it would not be necessary to recompile existing applications or patch binaries.

I see that this does preclude my proposed approach of an extra argument to FSUIPC_Open, with a default value. So I suppose I would have to create a new function, FSUIPC_WindowTitle or something like that. If nobody every calls FSUIPIC_WindowTitle, the window title used by the FindWindowEx call in FSUIPC_Open will be NULL (wild card). But if someone calls FSUIPC_WindowTitle with a specific title, that specific title will be used in the FindWindowEx call.

It isn't a change to FSUIPC. It is nothing to do with FSUIPC.

Yes, you're right. That one slipped out. I meant to say WideClient.

But at present WideClient won't load twice. It checks that there's not already any top-level window of "FS98MAIN" class already running.

AHHHH! Now _that_ makes this whole discussion a moot point. That's a show-stopper, that is. If the rest of this message ends up being sufficiently persuasive, what are the prospects for a configurable option to turn off this behavior?

It would only ever be WideClient and the applications concerned

Minus the previous show-stopper issue, I think what I am proposing only affects the SDK and applications, not WideClient, if I use a helper application to change the WideClient window title. And I think there is hope that it could affect only the SDK, and not applications.

But I guess the previous show-stopper issue definitely implies a change to WideClient. And it would probably be easier and more user-friendly to provide a WindowTitle argument to WideClient.ini than it would be to write an application that changes the window title. I'm not even totally sure it is possible to change window titles after the fact. I'm about 80% sure. :?

The window-title-changing application was a grasp at a straw, trying to come up with a proposal that would allow me to accomplish what I needed without requiring you to make any WideClient changes at all. But if we can come up with a backward-compatible approach, I hope you will consider making the small changes we have discussed, hopefully with some benefit to the user community, see immediately below.

Not my SDK. It would be your local code, or not an SDK any more.

If there is a way to get this to work without breaking the existing SDK interface, do you see any advantage to making this functionality available in the public version? This would not be a competing/incompatible SDK, but an SDK that is backward compatible with the current interface, but also allows for multiple WideClient instances.

Again, it does seem to me that there might be a general audience for this capability, beyond my specific application.

Yes, but in that case how do you get the applications to talk to the server you want them to? You have to do something to the applications.

Do my previous explanations in this response answer this question now? Applications that want to talk to multiple specific instances would use a new function, e.g. FSUIPC_WindowTitle or whatever we want to call it, to specificy non-NULL window titles to connect to. So yes, applications that want to talk to multiple instances of WideClient will need to be slightly modified and re-built, as you have noted. But other applications could continue to operate as they currently do.

Hmmm. It would need to be very carefully labelled, renamed, distinguished. I wouldn't want to cause the sort of confusion and problems that could arise should it be used unwittingly!

I would not consider releasing the new SDK into the same domain as the old SDK unless the new SDK was backwards compatible. If there is no backward compatibility, then the danger and confusion would be more than it was worth.

Pete, I really do appreciate the time you are spending considering my hairbrain proposal. I hope that my persistence is not annoying you. It's my job. I have to accomplish this goal one way or another. Seriously, I would probably be directed to implement an alternative to WideFS if this discussion falls apart. That's why I'm being so tenacious.

Thank you,

Tim Crews

GECO, Inc.

[Pete Dowson]

In my previous message I did propose modifying the call to FindWindowEx in the SDK FSUIPC_Open function, so that it would find the specific desired instances of WideClient.

Yes, I read that. And I replied. Sorry, I do all my replies whilst reading the message, so the answers are in the same sequence as your questions. It is quicker that way. I do have lots of other things to do. Sorry.

You did say it would be possible to add an option to WideClient.ini to specify the desired window class. But you began that paragraph with "If you are writing your own applications and you don't want to interface to FS itself." I certainly _do_ want to interface to FS. The approach I am proposing involves your described change to WideClient.ini (actually, a slight modification to your described change), _and_ my application interfacing to FS itself.

But your application won't interface to FSUIPC + FS if it does not use the standard method to find the Window, nor made configurable to use either, that was my point. You appear to be arguing with me. Why? If you know all the answers already, why are we discussing this?

I could create my own private SDK version, and I am willing to do so if necessary, but I was starting to feel hopeful that there was a way to accomplish the desired functionality by an enhancement to the existing SDK, without breaking the interface that current applications use

No, I don't think so.

I haven't written any applications yet, so whatever I do write can conform to any crazy SDK interface I come up with. Since these applications are private, I could have private applications interfacing to a private SDK version, and this would be workable and should not cause any harm to the outside world.

Of course. The source code is all provided. You can do what you like with it.

But if we use window title instead of window class to differentiate between multiple instances, then I still think there is a possibility of preserving the existing interface

Window titles are used by both WideClient and WideServer to display other information, admittedly optionally. Window titles for different FS versions are different, and moreover they are different for different language versions. Whilst what you propose is feasible, it is not as simple as you make out to make it general and it is bound to involve users in additional configuation settings. I do not mind at all whatever you do internally for yourself, and I do not mind if you publish what you do for others, I just want it to be very clear that it is an alternative for specific purposes.

In all the seven years since WideFS was first published there's never been another request/proposal even slightly resembling this one, so I don't feel there's a demand.

AHHHH! Now _that_ makes this whole discussion a moot point. That's a show-stopper, that is. If the rest of this message ends up being sufficiently persuasive, what are the prospects for a configurable option to turn off this behavior?

If you had wanted my original proposal, of using different class names, then that show-stopper wouldn't arise. I still feel that is the only sensible way to do it. I can very easily provide parameters in WideClient.ini to set alternatives to FS98MAIN (for multiple loads) and to UIPCMAIN (for connections). It is just as easy as providing a parameter to set different titles. but more sensible IMHO. I could just do it by adding an Instance Number to both (FS98MAINnn and UIPCMAINnn) according to a simple paramter in the INI. After all the INI has to be changed for each instance in any case, in order to specify a different Server and/or Port.

Incidentally, of historical interest, back in FS98 days there were some applications which did use the Window title to identify the correct Window - as well as the class name. In fact the WideServer additions to the FS title mucked them up, so an option was added to the WideServer INI to stop it changing the title at all. That is still there.

I'm not even totally sure it is possible to change window titles after the fact.

Yes it is. But I think it is better to use the Class, see above.

Regards,

Pete

[timcrews]

Pete:

Thank you for your response.

I would like to "officially" request a WideClient.ini option to specify the window class names, as you originally suggested. You have persuaded me that this capability will not be useful to the general public, so I would use the different class names in my own private SDK modifications to support multiple instances of WideClient on on machine.

Would the changed window class names have any negative effects on other interfaces/applications, as you alluded to with the changed window title proposal? Would your startup check against multiple WideClient instances be defeated, without causing additional problems in that code block?

Thanks again,

Tim Crews

GECO, Inc.

[Pete Dowson]

I would like to "officially" request a WideClient.ini option to specify the window class names, as you originally suggested.

Okay, it is easy enough. I'll send a Beta WideClient when I get a chance to put it in. Please write to me on petedowson@btconnect.com with the request so I can be reminded and return the result as an attachment.

Would the changed window class names have any negative effects on other interfaces/applications

Only that existing applications couldn't connect to a WideClient with modified class names. But obviously you can have one copy of WideClient with standard names as well as the others which can only be accessed by your modified interface applications.

Would your startup check against multiple WideClient instances be defeated, without causing additional problems in that code block?

Yes, it is only checking against a conflict with the class names.

Regards,

Pete