Sas-C Linker (Stub) Issues...

[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

[EDanaII]

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.

No hurry. Since you're doing me the favor, whenever you feel like looking at it is fine.

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.

Well, considering I might make similar mistakes, I'll give them a little wiggle room. But that's why I invite criticism, sometimes that's the best way to learn.

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.

Actually, I think I'm going to make the effort to compile MUI++ next. It may have the most promise for this kind of framework since it actually uses MUI. But it came only with sources and nothing is compiled. My dillema there is figuring out how to compile it as a library and then linking to the examples. I'll post a thread on this later if you want to look it over.

[Joloo]

No hurry.

Pweeh, I am glad.
Currently, I am a bit overworked (working from dawn till dusk), hence I don't find much spare time, and more important, I am not in the mood to do any kind of programming job. I am too tired for this.

Well, considering I might make similar mistakes, I'll give them a little wiggle room.

Well, we all make mistakes and we all learn from those, but when something is made publically available, it should be tested. Imagine if a beginner took a look at these source codes and adopted their programming styles. He would have spent days to investigate the source codes to figure out what's going wrong but would have never come to a conclusion. That AFrame partially worked has got only one reason, and that is soley SAS/C that creates code, which sparely uses the stack. Other compilers drop more information onto the stack and then the code will crash instantly.

Actually, I think I'm going to make the effort to compile MUI++ next.

In my humble opinion that's the better approach.

But it came only with sources and nothing is compiled. My dillema there is figuring out how to compile it as a library and then linking to the examples. I'll post a thread on this later if you want to look it over.

If I find the time on sunday, I'll take a look at it. Hopefully it is in a better shape than AFrame.
BTW. It's a static library, right? Well, a static library is just a collection of object files, under OS3 and a compliant compiler (not g++ !!!) you can use the "join" command to combine those object files as one static library.

Regards

[Joloo]

I only want to inform that I've downloaded Mui++ (MorphOS version, because it is newer) and after applying the required modifications for OS3 I tried to compile. Hmm, there are plenty of errors when compiling using g++ 3.4.0. I don't think that I am able to fix these errors without touching my system header files, but that is one of the things I don't want to do, at least not as a lasting solution. I have to think about a temporary workaround...

Besides that, I haven't taken a look at BlackJack3 till now, due to lack of time.

Regards

[EDanaII]

No rush on either. My priorities just changed, so I'm not focused on either of these for the moment. I'll get back to them later.

The errors you uncovered, do they look like the errors I found in this thread? That's where I am with MUI++ and they look like they might just be something you might understand.

[Joloo]

No rush on either. My priorities just changed, so I'm not focused on either of these for the moment. I'll get back to them later.

Perfect!

The errors you uncovered, do they look like the errors I found in this thread?

No, unfortunately not, I spotted different sorts of errors.

That's where I am with MUI++ and they look like they might just be something you might understand.

Well, I am not that optimistic in regard of my C++ skills.

Anyway, the main issues I have, as far as I am able to tell - because of my limited C++ skills, is that unnamed structures in C cause no problems at all, in contrast to C++, where the compiler doesn't know how to treat it properly. Example.

While something like this:

typedef struct
{
whatsoever
} *identifier;

is allowed in C, it must be converted for C++ into:

typedef struct STRUCTURE_NAME
{
whatsoever
} *identifier;

Because Commodore Amiga used this type of "unnamed structure declarations" especially for Intuition include files (NDK 3.9 installed here), I would have to examine these files and modify them accordingly.
Yet, after more investigations, I think I can change these include files and add the STRUCTURE_NAME for these structures in question without breaking compatibility for C compilers.

Next issues I am faced with is that the proto include files are not well suited for C++. Passing the pointer to TagItems where a variable argument list is expected without denoting it correctly for C++ in the corresponding proto include file must result in errors... Hence these files must be altered, too.

In short, I think Mui++ (the MorphOS modified version I am trying to compile) should work once these system header files were changed accordingly.


Regards

[Joloo]

Merry Christmas to all who are celebrating it, for all others, enjoy life as it.

I've uploaded the modified source codes of Mui++.

Please, before you try to compile, locate this,

typedef struct {
 ULONG MethodID;
 /* method-specific data ... */
 } *Msg;
 
and change the typedef to:
typedef struct _Msg {

in intuition/classusr.h

This is essential for C++.

I have only tried to compile it (using gcc 3.3.0 and 3.4.0), I did not build something based on it. Hence errors were not fixed, if any exist.

Regards

[EDanaII]

Let me know what you get figured out... unfortunately, my other distractions are taking up my time, like having to fix some broken pull-down menus on a website I maintain, so I haven't had a chance to revisit this of late.

[Joloo]

Let me know what you get figured out...

The first step was to change the include files ("intuition/classusr.h", "utility/tagitem.h" and "clib/alib_protos.h") to be used from C++.
In "intuition/classusr.h" I changed,

typedef struct {

to

typedef struct _Msg {

In "utility/tagitem.h" and "clib/alib_protos.h" the obligatory statement <#ifdef __cplusplus [] extern "C" {> was missing again.

The changes I've applied to the source code are minor - the issues I faced probably are due to the compiler initially used. I guess that it was g++ of version 2.9.x. For 3.3.0 and 3.4.0 the preprocessor doesn't accept anymore "::" within a macro definition. Hence I didn't use this macro but wrote it out in full (copy and paste orgy). Besides, I am not a fan of macros anyway, at least, if source codes should not be bound to one compiler only.
If I am right, any version of g++ 3.x is more strict than any previous version, so I had to cast some parameters before they were accepted.
I then changed one m68k-style VARARG function to a linear memory array.
Okay, the hook function (dispatcher) had to be rewritten, because g++ doesn't accept parameters in specified processor registers, but that was it in the end.

unfortunately, my other distractions are taking up my time, like having to fix some broken pull-down menus on a website I maintain, so I haven't had a chance to revisit this of late.

Don't mind. I have time issues, too.
Hopefully our situation will change in the future, although I have my doubts...

Besides, can you make the latest version of Black Jack available, so I can have a look at it, once I find some time?
If I recall correctly, you wrote that you have issues with the latest version, but not with the version I did download?
I ask because I have to work at the weekend anyway and I need something to relax, i.e. which distracts me from the boring work.


All the best for the upcoming new year,

Joerg

[EDanaII]

Hopefully our situation will change in the future, although I have my doubts...

My time situation comes and goes... It's all dependent on my job, my aging father, family, my involvement with the 401st, friends, etc...

I actually would like to find some kind of framework that is C++ oriented, which is why I've been investigating these. When I first learned C++, I created a object orient Blackjack framework to demonstrate I understood the concepts of OOD. I'd like an OO GUI to take that learning a step further, which is why I've been looking at these frameworks. I could just use Java or C#, but what fun is that? Unfortunately, as you seen, the Amiga lacks these and I've found trying to learn MUI, or Reaction or whatever else to be quite frustrating. Lack of a good knowledge base, documentation, etc... that mixed with the lack of time and the need to continue learning job related things (Unit testing, SOA, etc...) have made it extremely difficult to get anywhere.

I actually appreciate you taking an interest in this and if I can help you in anyway let me know.

As to my latest version of the game, contact me privately with your email address and I'll send you a zipped version. The remaining issue was a memory leak problem that I couldn't nail down, especially with the tools I have available. There was an issue with the IDCMP flags getting out of sync with the games basic functions but I hope I fixed it. As it was a random thing, so I'm still not 100% sure.

And a very Happy New Year to you too.