2025 VCC Fall release.

[ejaquay]

It is time do a release. To accomplish that we need to focus on testing what we have now and fixing known issues rather than doing enhancements. We should be able to do the release this month or early in December. In the meantime I will not be pulling any more enhancements.

[ejaquay]

I went through the issues list and set type to "feature" for all enancements/feature requests. The remaining issues are considered bugs. PR fixes for any of these (listed below) or for any bugs found and entered as issues while testing will be acceped for the fall VCC 2.1.9.3 release.
After the release VCC version will be advanced to VCC 2.1.10.0 and enhancements will again be accepted.

#447 ejaquay Orchestra90 can't read SDC drive 0
#442 ejaquay quickload of rom pak modifies init file
#426 ejaquay Commit b77093c broke RoboCop cartridge
#412 ejaquay Vertical scroll register ($FF9C) is not implemented.
#411 ejaquay Joust not working
#384 ejaquay Black Caldron arrow keys and audio not working
#352 callsop Moon Patrol demo / Timing issues
#347 ejaquay Screen flicker when splitting from text to graphics.
#345 ctchewy Reset and resulting clock speed
#174 Pontiac76 Wildcatting keyboard input issue
#52 BGPierce Acept *.pak enhancement
#48 BGPierce 32KB cartridge images - format?
#36 BGPierce Prevent key repeat when video throttle is off

[ejaquay]

The VCC 2.1.9.3 (and future releases) will come with a dynamic libcommon that contains functions shared between vcc.exe and the hardware cart dll's. I will change build configs to set the name and extension of the libcommon DLL to "libcommon.vcc" so that there will be no confusion as to what it is and so the cartridge menu will not offer is as one of the hardware carts which have the ".dll" extension.

[BGPierce]

The Orch90 disk is slightly different from a normal disk. They're formatted the same, but there's something different in the file system. Also, Orch90 uses it's own direct file read/write system and not RSDOS. I'll look at my Orch90 notes and let you know.

[ejaquay]

orch90 and several games i know of use their own floppy interface. I had to add a simulation of a floppy controller to SDC so they could work. But there is, as Bill mentioned, something about the orch90 floppy that is different. i plan to do some comparison logging with fd502 to see if I can discover it's secrets.

[BGPierce]

I still don't quite understand this change. I do understand having a "common" DLL with things common to VCC, but Carts (FD502, Orch90, MutliPak, etc.) are separate entities and would have their own "common" DLL for each piece of hardware and only included in memory when that piece of hardware is in use. It's not about memory use or saving space, it's about emulating each piece of hardware on it own. Industry standard? I think it would be more industry standard for each piece to be it's own entity.

[ejaquay]

libcommon has been a subject of some debate. It is a container of compiled functions used by vcc and the pak dlls but there is contention about what functions belong in there and if it would be better to statically link the functions.

Static linking would eliminate the libcommon.vcc file. I believe it would be a small of work to covert to static linking. Logic tells me dynamic linking the library is okay but my gut is not totally comfortable with it.

My stand on content is only functionality that is common to more than one pak .dll or vcc.exe belongs. I intend to hold the line on that unless I can be convinced otherwise.

[ChetSimpson]

I have submitted multiple PR's which convert the Becker Port, GMC, Orchestra-90, and RAM Disk cartridges and the MPI cartridge to use and support only a procedural/C based API. Once those have been merged in a subsequent PR will be submitted that removes the C++ based context (the fluent interface is still intact), changes libcommon to a static library, and removes the exports detail, and will change the base build settings to build for multi-threaded static instead of multi-threaded dll. This will remove any possibility of other problems associated with C++ and DLL boundaries.

[ejaquay]

What do we loose by doing this?

…

On Fri, Nov 14, 2025, 1:08 PM Chet Simpson ***@***.***> wrote: I have submitted multiple PR's which convert the Becker Port, GMC, Orchestra-90, and RAM Disk cartridges and the MPI cartridge to use and support only a procedural/C based API. Once those have been merged in a subsequent PR will be submitted that removes the C++ based context (the fluent interface is still intact), changes libcommon to a static library, and removes the exports detail, and will change the base build settings to build for multi-threaded static instead of multi-threaded dll. This will remove any possibility of other problems associated with C++ and DLL boundaries. — Reply to this email directly, view it on GitHub <#498 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFIUKNAQB64MVUKPIPRQXTD34YLDTAVCNFSM6AAAAACL73WBGCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIOJXGIYTQMY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[ChetSimpson]

What do we loose by doing this?

Until I finish my list of changes on the cartridge side, the ability to shoot yourself in the face with it. I figure I'll be hitting the last 2 or 3 items around the time you get the release out.

[ejaquay]

Unless we want to fix unnecessary bugs the release may have to go out with the interface as it is because those five PR's seem to break things pretty seriously.

I decided to ask CoPilot about C vrs C++ interface to get what the AI gleamed from it's sources:

Q: I have a project that loads multiple DLL's at runtime that use a standard C interface so they are plug and play modules. We are considering changing the interface to C++ so we can overload parts of the interface for more flexibility. Are there disadvantages to doing this?

A:

Disadvantages of Switching to a C++ Interface

1. ABI Compatibility and Name Mangling

• C++ name mangling means function names are encoded with type information, making them compiler- and version-specific.
• This breaks the binary compatibility that C interfaces provide, making it harder to load DLLs dynamically unless you use extern "C" wrappers.

2. Compiler and Toolchain Coupling

• C++ ABIs are not standardized across compilers or even compiler versions (e.g., MSVC 2015 vs 2022).
• This can cause runtime crashes or undefined behavior if a plugin is compiled with a different toolchain than the host.

3. Exception Handling Across DLL Boundaries

• Throwing C++ exceptions across DLL boundaries is undefined behavior unless both sides use the same runtime and compiler settings.

4. VTable Layout Instability

• Virtual function tables (vtables) are not guaranteed to be layout-compatible across compilers or even optimization levels.
• This makes it risky to pass polymorphic objects across DLL boundaries.

5. Increased Coupling

• C++ interfaces can introduce tight coupling between host and plugin, reducing the flexibility and long-term maintainability of the plugin system.

🧩 Hybrid Strategy (Recommended)

A hybrid approach might be ideal:

// C-compatible entry point
extern "C" __declspec(dllexport) IPlugin* CreatePlugin();

// C++ abstract interface
struct IPlugin {
    virtual void Initialize() = 0;
    virtual void Execute() = 0;
    virtual void Shutdown() = 0;
    virtual ~IPlugin() {}
};

This gives you:

• C ABI stability for loading
• C++ flexibility internally
• Safe polymorphism if you control both sides

---

[ChetSimpson]

Unless we want to fix unnecessary bugs the release may have to go out with the interface as it is because those five PR's seem to break things pretty seriously.

I decided to ask CoPilot about C vrs C++ interface to get what the AI gleamed from it's sources:

Thanks for the refresher I didn't need. I'm sure there's a few problems in there mostly in the MPI I would imagine but I didn't test it for s**t so my bad. Since there's an apparent desire for self containment, static compile, etc, etc I'm just making sure you have a choice at this moment rather that it coming up again later.

[ejaquay]

GetPakFactory() should be able to be made stable. However I am in favor of keeping the capi interface longterm as well. There seems to be no obvious conflicts between the two and I see no reason to rush changing all the hardware paks to use the new interface because they don't need the flexibility it affords. From my point of view only the mpi needed that kind of flexibility and a better direction might have been to just include it into vcc.exe with a swwitch to turn it on/off.