The nature of the change

I’ve seen lots of discussions that talk about how certain bugs have been copied over from API 1.0 to API 2.0.

This is unlikely and mostly not correct. From what I can tell nothing was “copied” from one API to another.

Let me detail why I think this is the case with an analogy.

Suppose you had source code that you could compile into a dynamic library for macOS (a dylib), Windows (a DLL), or Linux (a .so). But in your Xojo application instead of having to write all the declares every time you wanted to call you dynamic library you created class, or module, that put a nice API on it that hid all those declares. A great example of this is something like macOSLib which hides a lot of the details of calling into macOS Cocoa API’s from you. Behind the nice Xojo API this presents are a lot of declares. But you dont have to deal with those. You just use the classes available.

Thats roughly analogous to API 1.0 – the classic API used from the days of REALbasic through to Xojo.

Now if you altered the Xojo code in all those methods and classes by renaming the properties and events in the Xojo API or added new ones, but did not alter the underlying declares, you would have a new, or modified, API. And if you brought all this code into existing projects you’d have to adapt all your existing code if you wanted to use this new API. But you would still retain all of the old bugs you had in the C++ code.

This is roughly whats happened with API 2.0

API 2.0 is a new API on top of much of the same framework that has existed for years. Hence there are old bugs still present along with new ones adding this new API has introduced.

Thats not to say the new API 2.0 work didnt alter any of the underlying code. There are some things like Folderitem which appears to have new more modern OS API’s in use on macOS (a very welcome thing) and a handful of other items.

But by and large API 2.0 sits on the same framework as API 1.0 did.