Sas-C Linker (Stub) Issues...

[Joloo]

Have any Holy Water handy?

ur code seems to be posessed. :madashell:

Na, C++ code is evil per se.

I'm a newbie when it comes to C++, so forgive me if I'm missing anything obvious...

...and I am really rusty when it comes to C++...

But now that I know you are really using C++ your issues look quite clear to me.

If you are compiling C++ source codes with SAS/C (didn't know it is possible at all) the thrown error means SAS/C had created the calling convention in style of C++ but since ReqTools is an Amiga shared library the calling convention should have been plain "C" (for the nitpicking ones, I know that this is incorrect, too, but describing the real technique creates more confusion)!

I guess that in the file "clib/reqtools_protos.h" these lines are missing,
in front of the function declarations,

Code: [Select]

#ifdef __cplusplus
extern "C" {
#endif

And right after all function declarations,

Code: [Select]

#ifdef __cplusplus
}
#endif

That's all. Maybe you have to compile those source codes newly which are accessing "clib/reqtools_protos.h", i.e. those which include "proto/reqtools.h". Look for example in "clib/exec_protos.h" how it was done. Hope it helps.

Regards

[EDanaII]

Wow. You nailed it, Joloo. I'm impressed.

But now I have a similar problem:

Code: [Select]

Undefined symbols        First Referenced
@InstallClipRegion__FP5LayerP6Region File 'gadget.o'
Enter a DEFINE value for @InstallClipRegion__FP5LayerP6Region (default ___stub):

The InstallClipRegion is defined in the clib\layers_protos.h and does have the __cplusplus defines you suggested where they're supposed to be.

Any ideas?

[Joloo]

Any ideas?

To be honest, no.

If the C++ style for the calling convention was suppressed, no such call may be generated unless there is a compiler bug.

I had now enough interest and downloaded both archives, aframv02.lha and afexampl.lha.
In neither of the two archives is a reference to @InstallClipRegion__FP5LayerP6Region, so my questíon is what did you do in order to spot them?

In "Lib/AFrame.lib" are two references to "_InstallClipRegion" and in "Lib/gadget.o" is one reference to "_InstallClipRegion, but I don't see any reference to "@InstallClipRegion__FP5LayerP6Region". In the example drawer are approximately 60 references to "_InstallClipRegion". So far it looks quite okay to me.

Sorry for being of no help

[EDanaII]

Actually, you've been a great help. I've got a lot more clues about what is going on than I did before.

This is what Visual Studio tells me:
gadget.cpp(119): m_oldregion=InstallClipRegion(m_pwindow->m_pWindow->WLayer,m_newregion);
gadget.cpp(128): InstallClipRegion(m_pwindow->m_pWindow->WLayer,m_oldregion);
layers_protos.h(56): struct Region *InstallClipRegion( struct Layer *layer, CONST struct Region *region );

So, lines 199 and 128 in gadget.cpp and the function call defined in clib\layers_protos.h at line 56.

And layers_protos has a pointer to a struct and one to a const. Doesn't this fit the formula you defined in an earlier post? @InstallClipRegion__FP5LayerP6Region

What am I missing here?

BTW, what do you think of this AFrame? It caught my attention because it provides objects in a fashion recognizable to me. I even like the fact that, for example, a window has "events" like OnWindowClose or OnGadgetDown.

[Joloo]

This is what Visual Studio tells me:

Stop!
What you see is just the instruction (here, generate code in order to call a function) for the compiler.
What I investigated was the code already generated by the compiler (.cpp vs .o).
So we both are talking about two completely different things.
Let's clear things up:

m_oldregion=InstallClipRegion(m_pwindow->m_pWindow->WLayer,m_newregion);

If this is compiled in C++ mode, SAS/C will produce an "external reference" to a function called "@InstallClipRegion__FP5LayerP6Region". This is an ordinary C++ functions, which SAS/C has already created / has to create.

But if this is compiled in C mode, SAS/C will produce an "external reference" to a function called "_InstallClipRegion", which is either the synonym for the shared library's function offset or some sort of glue code, which makes this function offset available to the compiler.

Now I have to speak verbosely.
An ordinary C/C++ function is just an address in memory, if you call it, f.e. "InstallClipRegion(...)", the code generated by the compiler just puts the parameters either on the stack frame or in the appropriate registers (or both, depends on ABI) and then jumps directly to the address, which you used by its synonym. In this example "InstallClipRegion" is the synonym, let's say (as an example) for the address 600000 in memory and the compiler respectively the linker, knows exactly this synonym's address, because the compiler generated it.

Amiga OS1.x to 3.x shared libraries don't contain addresses which are directly jumpable. Instead, there is a base address and from there downwards (i.e. negative) the jump offsets are defined, called library vector offsets (LVO). Normally, you cannot reach these jump addresses with the instruction set offered by a C/C++ compiler, because something like LayersBase->InstallClipRegion() isn't near any possibility, because "InstallClipRegion" is just the synonym for the negative number '-174' and due to the AmigaOS 1.x to 3.x ABI the parameters have to reside in varying processor registers!
Thus what was made in the early days of Amiga OS1.x was to grant the poor C coder access to those shared library offset in form of assembler generated glue code:

Code: [Select]


XREF _LayersBase ; Reference to an absolute 32-bit symbol
XDEF _InstallClipRegion ; Define an absolute 32-bit symbol
; Symbols (as we use them here) are just 32-bit memory addresses!

_InstallClipRegion
move.l a6,-(sp) ; Remember for restoring the processor
; register A6 within the stack frame
movea.l 8(sp),a0 ; Take parameter 'layer' from stack frame
; (the C compiler stored it there)
movea.l 12(sp),a1 ; Take parameter 'region' from stack frame
; (the C compiler stored it there)
movea.l _LayersBase,a6 ; Put base address in processor register
; A6 (convention), _LayersBase was set up by
; the C/C++ compiler, see OpenLibrary().
jsr -174(a6) ; Jump to this address and carry out the instructions
; residing there
movea.l (sp)+,a6 ; When we get back, restore this register's content
rts ; Back to C/C++ compiler generated code with return code
; in processor register D0


In reality, the offset -174 is not named InstallClipRegion but _LVOInstallClipRegion - but the function which is carried out is named InstallClipRegion!
Because it was a mess for any C coder to link against those glue code, there were approaches to avoid using glue code; SAS/C does it by specifying "#pragma libcall LayersBase InstallClipRegion ae 9802", which when encountered by the SAS/C compiler, will produce the necessary code in order to fire up the function hidden behind the offset "ae" (174) automatically, including that all parameters were put in the appropriate registers without touching the stack frame. First of all, any time now InstallClipRegion() is called by the application programmer, the corresponding code will be generated, what makes the executable file a little larger, but the benefit is that the code is drastically faster than before, because the compiler will "inline" this code, i.e. does directly jump to the appropriate code which resides in the corresponding shared library without taking the detour via the glue code.
Today, any Amiga compiler will use "inlined" code, whether by preprocessor commands or directly using assembler instruction doesn't make any difference. But still LayersBase->InstallClipRegion() isn't possible under C/C++, what would be the correct notation if we speak about genuine C/C++ functions. OS4 introduced therefore a more abstract method, ILayers->InstallClipRegion() - note the change from LayersBase to ILayers!

Now you and me know that OS functions (or any functions in a shared library), when we use them, are *not* any kind of genuine C/C++ functions, but some very complicated constructs (from a C/C++ compilers point of view), which fortunately is causing us today no headache anymore, thanks to the work done by the compiler builder!

Hence, "@InstallClipRegion__FP5LayerP6Region" is just a memory address (genuine C++ function), whereas "_InstallClipRegion" is the synonym for code that calls a certain function in a shared library. On the paper (i.e. within a source code) they look pretty much the same, but once the compiler encounters them, it will create different code.

Thus,

m_oldregion=InstallClipRegion(m_pwindow->m_pWindow->WLayer,m_newregion);

compiled in C++ mode without telling the compiler that this is a special function (i.e. without using 'extern "C"') will produce code, which will create a reference to "@InstallClipRegion__FP5LayerP6Region".

Compiled in C++ mode but using 'extern "C"' should not at all create a reference to "_InstallClipRegion" but should "inline" the required code.
The same goes for C compiles; there should be no reference to "_InstallClipRegion", just the inlined code.

If, and only if one does *not* specify "proto/layers.h", there will be references to "_InstallClipRegion", i.e. the compiler will not create inlined code. Thus, if one specifies "proto/layers.h" SAS/C will include "pragmas/layers.h" and "clib/layers.h", which will have the result of inlined code for Amiga shared library functions (offsets) without any references written out to the corresponding object file.
Maybe, but only maybe, SAS/C will not directly write such inline code, but let this do the linker - but, to be honest, I wouldn't bet a dime on this. Like I already told, I don't have a copy of SAS/C to explore this.

Besides, hopefully my English is not so bad that you do not understand what I mean. I have praised already once in a while to take an English course but earning money do foil my best plans...

BTW, what do you think of this AFrame? It caught my attention because it provides objects in a fashion recognizable to me. I even like the fact that, for example, a window has "events" like OnWindowClose or OnGadgetDown.

Well, I haven't taken a closer look. I just listed the object file structure of the static lib and searched for external references in the object files.
Since I don't own a copy of SAS/C I cannot run any own tests (static libs are bound to the compiler that created it, especially C++ static libs) - or are all source codes provided?
In addition, I tried some of the examples, but unfortunately, a lot of them crashed instantly. Next, there is no real layout method, nor font sensitivity as far as I saw. But then again, I have only spent five minutes or so investigating. No closing judgement possible...

Regards

[EDanaII]

Stop!

Whoa! OK. I'm stopped. =)

m_oldregion=InstallClipRegion(m_pwindow->m_pWindow->WLayer,m_newregion);

If this is compiled in C++ mode, SAS/C will produce an "external reference" to a function called "@InstallClipRegion__FP5LayerP6Region". This is an ordinary C++ functions, which SAS/C has already created / has to create.

But if this is compiled in C mode, SAS/C will produce an "external reference" to a function called "_InstallClipRegion", which is either the synonym for the shared library's function offset or some sort of glue code, which makes this function offset available to the compiler.

Actually, you got me to thinking and I took another look at the Sas-C SCOPTIONS command that comes with the project. Under "Compiler Options" was a setting that said "NoCxxOnly" which can be changed to "CxxOnly". Changing it to that value causes the program to compile correctly. I guess I made the mistake of assuming that the Sas Build command was set to build C++, but looks like I assumed incorrectly. Not to mention the fact that, somehow, NoCxxOnly is supposed to mean "compile code using C." Not exactly obvious, to say the least.

Now I have to speak verbosely.

Boy, that really was verbose! =) But appreciated. Good facts to know while I dig through this ancient code. Thank you.

Besides, hopefully my English is not so bad that you do not understand what I mean. I have praised already once in a while to take an English course but earning money do foil my best plans...

Actually, your English is quite good. It's clear you're not a native speaker, but you speak well enough that I can understand you easily. For example, using the quote above, an English speaker might have said: "Besides, my English is, hopefully, not so bad that you can't understand my meaning." You're statement is close enough that I can understand you easily. Your second statement's a little tougher to understand, but the meaning is still pretty clear. I, personally, might have said something like "I've thought about learning English, but my need to earn money keeps foiling my plans."

If you wants some tips on English, I'd be happy to help you there. It's the least I can do considering the help you're giving me here.

Well, I haven't taken a closer look. I just listed the object file structure of the static lib and searched for external references in the object files.
Since I don't own a copy of SAS/C I cannot run any own tests (static libs are bound to the compiler that created it, especially C++ static libs) - or are all source codes provided?

All source code for the AFrame objects are provided, in fact, they're provided repeatedly. There is, for example, an Object.cpp file that exists in every example directory in the package. I'm not sure why they chose to do it this way, over, let's say, putting it in a single directory and compiling everything to a single library file.

In addition, I tried some of the examples, but unfortunately, a lot of them crashed instantly. Next, there is no real layout method, nor font sensitivity as far as I saw. But then again, I have only spent five minutes or so investigating. No closing judgement possible...

Interesting. They ran fine for me until I started compiling them. Not sure what to tell you there.

Thanks for the help. It's definitely appreciated. Can I call on you for more help as I dig through this code?

[Joloo]

Stop!

Whoa! OK. I'm stopped. =)

Then you're the first person ever who gives a dime on things I say.

Actually, you got me to thinking and I took another look at the Sas-C SCOPTIONS command that comes with the project. Under "Compiler Options" was a setting that said "NoCxxOnly" which can be changed to "CxxOnly". Changing it to that value causes the program to compile correctly. I guess I made the mistake of assuming that the Sas Build command was set to build C++, but looks like I assumed incorrectly. Not to mention the fact that, somehow, NoCxxOnly is supposed to mean "compile code using C." Not exactly obvious, .

A really misleading option description. But luckily you found out.

Now I have to speak verbosely.

Boy, that really was verbose! =) But appreciated. Good facts to know while I dig through this ancient code. Thank you.

It was my pleasure.
Frankly, if I would have been able to explain this background knowledge within one line of text, I would have done so. Unfortunately, like you already found out, my English is far away from being called perfect (to say the least).
Thus, I need much more words in order to explain something than someone who calls English his native language, hence no intention from my side but caused due to lack of knowledge.

If you wants some tips on English, I'd be happy to help you there.

I don't feel comfortable when writing in English, hence any tips are always warmly welcome - no question!

It's the least I can do considering the help you're giving me here.

You don't owe me anything. I am here on this forum to learn and to assist. I think we all are present here for these reasons.

Since I don't own a copy of SAS/C I cannot run any own tests (static libs are bound to the compiler that created it, especially C++ static libs) - or are all source codes provided?

All source code for the AFrame objects are provided, in fact, they're provided repeatedly. There is, for example, an Object.cpp file that exists in every example directory in the package. I'm not sure why they chose to do it this way, over, let's say, putting it in a single directory and compiling everything to a single library file.

Hmm, then one doesn't need to link against 'aframe.lib'? Perhaps then I can try to compile it myself and see how far I can get. Till now I thought one has to link against 'aframe.lib', which when compiled using SAS/C, is exclusively useable under SAS/C. Well, I will check these source codes in a few days but due to my experiences with source codes targetting towards SAS/C, I would be surprised if they can be compiled unmodified (SAS/C isn't really strict on type checkings, what is a must under C++).

In addition, I tried some of the examples, but unfortunately, a lot of them crashed instantly.

Interesting. They ran fine for me until I started compiling them. Not sure what to tell you there.

I've only a basic installation (OS3.9) without any fancy stuff. A lot of programs which came with OS3.9 were removed for the reason of making the system as nitpicking as possible. Hence it is a pure system just setup for developing and testing. Perhaps, some stuff is missing in my system and no proper error handling is carried out in the source codes? Don't know yet, have to dig out, but not today nor tomorrow.

Can I call on you for more help as I dig through this code?

Yes, that should be obviously.
But I must confess that I'm not very proficient in C++. My last C++ project originates from 1998...
In addition, I visit forums only sporadically and then mostly only the front page. If I don't respond in time (let's say three days), I didn't spot the thread in question. If this should be the case, please inform me by email.


Best regards,

Joerg

[ChaosLord]

You guys have a secret trick for compiling C++ with SASC!

Do u have a trick for doing:

long a

• ; // Declare an array at runtime

I hope u can say yes?

[Joloo]

You guys have a secret trick for compiling C++ with SASC!

Do u have a trick for doing:

long a

• ; // Declare an array at runtime

I hope u can say yes?

I am afraid that this isn't possible with SAS/C - it's a C++ feature under C99 (VLA, variable length array). But it is a feature that has got its disadvantage:

After the very first allocation the size of the array won't change anymore, even if now data exceed this storage size. Thus, if one doesn't know about this fact, a serious error (damage to memory/stack frame) isn't very far.
In my opinion something like "long a

• ;" is thus less useful than it appears on the first look.

If one has to deal with varying array sizes, he is better off using malloc() and a copy function and use instead of "long a

• " just "long *a;". Of course that's a lot of work if one has to modify an existing source code.

In my opinion these constructs (VLAs) are therefore true mines of information for faults which are only hard to find.

Regards

[ChaosLord]

What are the advantages of running SASC in C++ mode?

What are the disadvantages?

[EDanaII]

The only advantage from my perspective is compiling old code written specifically for it, such as AFrame. I tried compiling it using GCC, for example, and got a lot of "virtual function" errors which, I assume, has to do with the difference in age between the two versions.

OK, one other advantage is that it's debugger's a little easier to use that GDB, but... that probably has more to do with my not learning to use GDB yet.


@ Joloo:

Hmm, then one doesn't need to link against 'aframe.lib'? Perhaps then I can try to compile it myself and see how far I can get. Till now I thought one has to link against 'aframe.lib', which when compiled using SAS/C, is exclusively useable under SAS/C. Well, I will check these source codes in a few days but due to my experiences with source codes targetting towards SAS/C, I would be surprised if they can be compiled unmodified (SAS/C isn't really strict on type checkings, what is a must under C++).

There is an AFrame.lib, but none of the examples appear to link to it, but I may be reading thing wrong. The code needed, nonetheless, is repeated over and over again each example.

I tried recompiling using Visual Studio and AmiDevCpp, both of which use GCC and, as I pointed out to Chaoslord, failed owing to changes in standards between the two versions. Eventually, I'll try again, but... so many distractions, so little time...

But I must confess that I'm not very proficient in C++. My last C++ project originates from 1998...
In addition, I visit forums only sporadically and then mostly only the front page. If I don't respond in time (let's say three days), I didn't spot the thread in question. If this should be the case, please inform me by email.

That's still more than I got. I cut my teeth on BASIC, started professionally on COBOL, moved to a few languages you probably never heard of, PL/SQL, Java and now C#. I learned C when I got my Amiga, but never got to use it seriously, because my career had just started, and only recently learned C++. So, you're experience might be 13 years ago, but it still appears to be better than mine.

[Joloo]

@Ed:

There is an AFrame.lib, but none of the examples appear to link to it, but I may be reading thing wrong.

No, you're right. The 'aframe.lib' isn't involved at all upon creating the applications.

I tried recompiling using Visual Studio and AmiDevCpp, both of which use GCC and, as I pointed out to Chaoslord, failed owing to changes in standards between the two versions. Eventually, I'll try again, but... so many distractions, so little time...

I've removed the SAS/C dependencies out of the source codes I was laying my hands on (PictureDT) and tried to compile using MaxonC++ (HiSoft++, identical software). Unfortunately, as I already pointed out, SAS/C isn't as nitpicking as it has to be in order to compile C++ source codes. Then, there are a lot of mistakes made by the initial authors, unless I am mistaken, as they create objects within the stack frame and passing the address of that object to the callee. Of course, then a crash isn't very far, because that object was locally created in the function that it used. I solved it by using the 'static' keyword, but I haven't got the time to look through all the source codes and spot every occurrence. In addition, instead of telling something like:

Code: [Select]


if(!(picture.LoadPicture(rt.GetFileName()->data()))) { // Load the picture

they used,

if(!(picture.LoadPicture((char*)rt.GetFileName()))) { // Load the picture


For me that does look like an error, because LoadPicture() requires the parameter of type char and not of object AFString.

I don't know why the examples should have worked at all, even the initial authors didn't care whether a possible 'new' call succeeded or not...

Overall, I am not impressed by AFrame (due to the obviously errors the initial authors made), although the approach to create a simple C++ wrapper for what's otherwise costly to write in C isn't the badest idea at all, if now the implementation would be carefully carried out, nothing speaks against AFrame. Unfortunately, what I am missing is font sensitivity and automatically laying out of objects.
Well, I did invest only an hour or so, to understand, apply fixes and compile these source codes. Maybe I am all wrong. Who knows...

BTW.: I haven't checked yet if the source codes are compatible to 'g++' (although the register parameters are now compiler independent by using 'SDI_compiler.h'), that would be a task if I get more time (not very likely this week).

But I must confess that I'm not very proficient in C++. My last C++ project originates from 1998...

So, you're experience might be 13 years ago, but it still appears to be better than mine.

Maybe it appears to be better, but it isn't, trust me.
I think procedural ( ), not object oriented, and my projects are very tiny (usually less than 1 MB source code in size) and not complex, thus I chose C over C++ long ago, even I am the only one who develops these source codes (with exceptions from time to time).
C++ is a completely different shoe compared to C. Both follow two different philosophies and that makes it so hard for one who is familiar with one to get comfortable in the other. At least this is valid for me. I know persons who are really good in both camps, but they count as exceptions.
Long story short: If you already know a little Java and C# you follow a different programming philosophy than me and hence you must have much more knowledge of object oriented programming than me.
I do only know the basics.

Anyway, if you wish, I can upload what I've achieved so far, not that it is now error free nor really useable (I did invest too less time for this), but it's a starting point, in case you don't want to abandon the project now.

Regards

[EDanaII]

Overall, I am not impressed by AFrame (due to the obviously errors the initial authors made), although the approach to create a simple C++ wrapper for what's otherwise costly to write in C isn't the badest idea at all, if now the implementation would be carefully carried out, nothing speaks against AFrame. Unfortunately, what I am missing is font sensitivity and automatically laying out of objects.

Actually, that's why I'm looking at it: studying the approach to creating wrappers. In addition to it, I've looked at something called "Intuition++" which is not as complete as AFrame and A++ which I haven't compiled just yet. And I just now discovered something called "CIT".

Long story short: If you already know a little Java and C# you follow a different programming philosophy than me and hence you must have much more knowledge of object oriented programming than me.

OK, you win. (I still wouldn't have figured out that SasC stuff without your help.)

I'm actually from the procedural world myself. I cut my teeth on BASIC ages ago, began my career in COBOL, and moved from several different languages to PL/SQL. I didn't start with OO professionally until a couple of years ago. I can't claim I'm the greatest, but I do think in OO, owing I suppose, in part, to my training and experience with database design.  

Anyway, if you wish, I can upload what I've achieved so far, not that it is now error free nor really useable (I did invest too less time for this), but it's a starting point, in case you don't want to abandon the project now.

I would like to see it, yes. This is my way of learning, picking up new techniques and different perspectives.

In a week or two, I may start poking around with some of those other frameworks I mentioned above.

[Joloo]

Anyway, if you wish, I can upload what I've achieved so far, not that it is now error free nor really useable...

I would like to see it, yes. This is my way of learning, picking up new techniques and different perspectives.

Frankly, I don't know whether I should release those through me modified source codes, because there are countless and evidently made errors by their initial authors, which I already spot with a shallow sight, and one can get the impression that AFrame can be made useable with little work put in (and that's definitely not the case!). In my humble opinion AFrame should be put into the trashcan as soon as possible (sorry for those harsh words). It's a vain project, unless someone is really, really willing to spend a lot of time fixing all the mistakes, but, this requires great knowledge of the Amiga-API, it's peculiarities, C++ and the right tools.

What I found out:
Libraries get closed although they weren't opened at all (stumbled by accident over that).
Library bases were reset (put to zero) although other programming parts still needed their addresses.
Global variables get treated as if they were local.
The addresses of locally created arrays (stack frame) will be stored in the object, although upon returning to the callee, they are already gone, that's one of the reasons why the created executables do crash instantly here (context switch in the middle of it - bang!).
No care spent at all if 'new' returned success and moreover, no correct (not to speak of global) error handling.
Cast operator used instead of using a proper function.
Not even a bit of this code is thread-safe.
Intuition message parsing does only work if there is just one window.
BTW, the Intuition message parsing is broken per se.
The implementation for lists is broken for dynamically removing items.
Testing pointers although the memory where these pointers reside in (object) is already freed from memory.

Anyway, here it is:

Modified example of PictureDT

Watch out, it is still broken and will bomb if fired up.

In addition to it, I've looked at something called "Intuition++" which is not as complete as AFrame and A++ which I haven't compiled just yet. And I just now discovered something called "CIT".

Although I don't know one of the two, I would speculate that they count for more steadiness.
AFrame is too buggy.

I didn't start with OO professionally until a couple of years ago.

Hence you are a professional programmer, while I am just a lazy hobbyist. Thus one more point for you.
Though, I know the AmigaOS API since more than twenty years and therewith spot mistakes made by others very quickly.


Regards

[EDanaII]

Watch out, it is still broken and will bomb if fired up.

Actually, I was able to run it without too many issues. Only one picture was not loaded, the others loaded fine. This is no different than the original version. I'll take a closer look at your changes when I get a moment.

Although I don't know one of the two, I would speculate that they count for more steadiness.
AFrame is too buggy.

Well, considering the version number (0.2) I'm not too surprised there are problems. Like a lot of stuff found on Aminet, somebody got started on a good idea and never finished it. It's still of interest to me.

In addition to AFrame, CIT, APlusPlus, I've also found MUIPlusPlus and OOP4A. I can't get MUIPlusPlus or APlusPlus to compile even though APlusPlus comes with SasC icons and I haven't figured out how to use OOP4A as it doesn't exactly look like C++, so, right now, AFrames still my best "choice."

Hence you are a professional programmer, while I am just a lazy hobbyist. Thus one more point for you.
Though, I know the AmigaOS API since more than twenty years and therewith spot mistakes made by others very quickly.

Would you mind critiquing me then? A few years back I updated a Blackjack game on AmiNet to be a little more "modern." That game still has a couple issues, such as memory leaks and problems with idcmp flags. You don't have to do this if you don't want to, I just thought I'd ask just in case you were willing.

It can be found here. ALthough I have a slightly updated version not yet loaded to aminet, simply because I've had issues with getting it tested.

[Joloo]

Watch out, it is still broken and will bomb if fired up.

Actually, I was able to run it without too many issues. Only one picture was not loaded, the others loaded fine. This is no different than the original version.

Exactly, because I didn't compile the modified source codes to an executable file, which I could have enclosed, but did left the old, SAS/C compiled executable file intact. I should have removed it. My bad. :\

Here on my system no image was loaded at all with this SAS/C compiled executable file; I've worked around it, then it crashed immediately after having loaded the image in question, then, after a few more fixes, it displayed the image but wasn't anymore able to refer the input to the main window. Because I didn't have had and have the time to fix all of the mistakes, I decided to upload what I've achieved so far, even it is not really ready/useable yet.

Well, considering the version number (0.2) I'm not too surprised there are problems. Like a lot of stuff found on Aminet, somebody got started on a good idea and never finished it. It's still of interest to me.

Well, for me it isn't an excuse at all to make such mistakes; creating in a sub-routine a local array where something gets remembered/set up and then passing this array's address to the callee is a mistake that isn't excuseable. It's just careless programming without respecting the basics.
I am still surprised that it runs under other systems than mine to some degree. If you take a closer look at the source codes it comes close to a miracle... Nonetheless, it can be a starting point, but it really requires a lot of work.

I can't get MUIPlusPlus or APlusPlus to compile even though APlusPlus comes with SasC icons and I haven't figured out how to use OOP4A as it doesn't exactly look like C++, so, right now, AFrames still my best "choice."

Okay, but then please remove these self-made lists and nodes and replace them by Exec's list and nodes. They are far more robust.
Next, local arrays on the stack are taboo. Use 'new' or something else.
The message handling must be rewritten; save what was sent by Intuition (im_Class, im_Code and so on) and reply this message instantly, and just then react upon what was backed up. BTW.: Is the GadTools toolkit used or do you plan to use it? - then use GT_GetIMsg() and GT_ReplyIMsg() instead of the Exec's counterparts; same for Intuition's BeginRefresh()/EndRefresh(), use the GadTools equivalents GT_BeginRefresh()/GT_EndRefresh().
For anything that gets opened/allocated a counterpart must exist.
Don't test pointers to objects but examine the 'list' whether the object in question is still there (alive).

I can only guess, but I would speculate that a lot of Enforcer/Mungwall hits must have occurred after an object died, even on your machine!

I am willing to lend you a helping hand in case you want to develop AFrame further, but please note that my spare time is very limited, like yours, too. My situation will hopefully change with the new year.

Would you mind critiquing me then? A few years back I updated a Blackjack game on AmiNet to be a little more "modern." That game still has a couple issues, such as memory leaks and problems with idcmp flags. You don't have to do this if you don't want to, I just thought I'd ask just in case you were willing.

I would be happy to help you, in case you're not in a hurry. I have myself a couple of projects that I have to develop further, and I am already two month late. This wouldn't mean that I could take a look at these source codes in two month at the earliest, but it means that I need a couple of days.

It can be found here.

First step taken; I've downloaded it.

Regards