libcommon DLL or static link?

[ejaquay]

A VCC libcommon library has been created and important shared VCC functionality has been moved to it, including a new pak interface.

I would like to open a discussion on which is better, keeping libcommon as a .dll and having VCC and Pak hardware modules link dynamically to the library, or to make libcommon a static library and do static links.

There has been discussion about this in the "Issues" area but this is not really an issue about how VCC function and more about how we develop and manage the code that comprises VCC so I think it best we discuss it here. I have copied Craig's and my comments from Issues to here and closed the issue.

[ejaquay]

My initial thoughts:

• Putting VCC's libcommon in a DLL may save memory I don't see that as a signicant advantage.
• Advantage I see for a DLL is it makes development easier.
• Avantage for static linking is removes user confusion about libcommon.dll is and prevents a user from trying to run a new VCC version against an older libcommon version.
  In summary, I don't have hard feelings about. I see dynamic linking as advantage for developers and static linking as advantage for users.

[ejaquay]

Follows is one of Craig's comments copied from "Issues"

The new libcommon being a dll makes all carts dependent on this dll, whilst this saves some shared code, it isn't exactly great. It goes against the original idea for cart dlls as previously all 'cart' dlls were independent, they didn't need to carry around this extra dll. If a 3rd party wants to distribute their own cart dll they must now include this extra dll and this may conflict with the one provided if changes are made between versions, leading to a failed LoadLibrary call and Vcc won't know the reason.

An alternative idea could be that these shared functions be built into vcc with no extra dll. The cart dll could instead obtain an interface to Vcc during its 'start' function. This interface could be versioned in case new features are added, meaning that Vcc maintains control providing a compatible interface so that 3rd party dlls can still be loaded. If a version really becomes unsupported the query can fail and the cart can fail its 'start' notifying Vcc which can then tell the user this cart needs updating from the 3rd party.

[ejaquay]

Follows is Craig's reply

Saving memory isn't advantage, completely agree with that. Changing its contents without rebuilding not much advantage as only will happen for minor fixes, soon as you need change function prototype or add new one you're still rebuilding the whole thing and doing so invalidates older versions and forces any 3rd party to rebuild/republish as well upon releasing it.

What I'm suggesting though is decoupling it so dlls aren't required to be rebuilt when changing the interface, since the old interface could still be present thus not breaking the old carts, but updates to new carts may use the new interface with no side dll to conflict with. It also means updates to those shared functions only rebuilds vcc.

"Unfortuanaly it also breaks carts built for the old interface." - right, and in the future it will happen again and again.

[ChetSimpson]

Generating and linking to a static library instead of a shared one is most certainly a violation of the ODR for object definitions which cross DLL boundaries. Some of the code such as that in DialogOps, FileOps, etc. can be placed in a separate static utility library without any problem. Those classes and a handful of free functions will be getting replaced (dialogs) or eliminated (fileops) anyway but managing those changes are fairly easy by deprecating the old and/or using function overloads where appropriate.

As a general rule the interface should not change, at least not between major release versions. While I'm not discounting that we may need to finesse the new interface over a couple of minor version iterations I do not see that as being a prolonged exercise. There's still a big of decoupling that needs to occur regarding UI vs device functionality in the cartridges that needs to be worked out but I would expect that'll be complete by the next release. If there's a belief that the interface will having breaking changes again and again in the future I would like to know what flaws are being identified so they can be resolved.

The recent changes to the C API used for cartridges needed to be done regardless of any other enhancements that were added. The original interface was absolute garbage, many of the names were complete nonsense, was (and in many ways still is) inadequate, and the overall way it was managed encouraged leaking details everywhere. This is a significant factor that should be taken into account before viewing it as any type of indication of repeated breakage in the future.

AFAIK there are no third party VCC cartridges available so I'm not going to be concerned about them until I know they actually exist.

[ejaquay]

Agree objects have to obey ODR. But wouldn't the definitions be in VCC.exe if not in libcommon.dll? Perhaps there is a bit I don't understand.

[callsop]

As a general rule the interface should not change, at least not between major release versions.

Sure, however we don't know what other future features will be added that may necessitate another rearrangement that will cause a change to the interface. That, is the flaw. However ..

AFAIK there are no third party VCC cartridges available so I'm not going to be concerned about them until I know they actually exist.

.. if third parties are not a consideration and thus its all in-house then I suppose its not really an issue to keep changing the interface.

[ejaquay]

Changing the interface is an issue even in house because the cart dll's need to be developed independantly. Different developers are potentially working on them. We should get to a stable pak interface and not change it often or at all.

[ejaquay]

I was somewhat agnostic about the common library being either a DLL or a static library because there seemed to be valid points for each. Lately I have been feeling that a static library might be a better approach. That and because other members have expressed fairly strong reservations about the DLL caused me to look closer. I now have a static linked version of VCC working on my dev system. It seems to work just as well (and poorly in the case of loading rom cartridges) as the dynamic version. I believe the only outward difference to users is that the libcommon.dll is not needed. Changes to actual code to acomplish static building is mimimal (no DLLmain and error string resources moved back to VCC) and are effected by use of precompiler conditionals. No changes were required for any of the pak dll's. The branch 'static' on my fork contains the changes to build VCC either using a dynamic libcommon.dll or a libcommon static library. Control is by setting the env variable "USE_STATIC_LIB" Defaults to dynamic if the variable is not set to "true".