The "Redzone damage" is a special indicator for OS4 kernel- and exec-programmers.
It has to do with features that are planned or currently in development.

_________________

@ssolie

Too bad, I just ported ViM 6.2 to OS 4

GoldEd runs very well, though, even emulated. Vim is very handy for a quick shell edit, though.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

@Rogue
Quote:

Too bad, I just ported ViM 6.2 to OS 4

That's excellent news. Considering ViM's origins, I suppose I could bend my Amiga purity rules just a little bit... [carefully removing foot from mouth]

I'm looking forward to giving your ViM port a try soon enough. Cheers!

_________________
ExecSG Team Lead

@Hyperion

What's the reasoning behind deprecating the standard (so far) AmigaOS types, like LONG, WORD and so on?

_________________
“It is well enough that people of the nation do not understand our banking and monetary
system, for if they did, I believe there would be a revolution before tomorrow morning.”
~~ Henry Ford

@falemagn:

Heh, I hadn't noticed that. At a guess, making things more modern (there are a fair number of desktop CPUs out there a word is 64 bits, and on the rest it's 32 bits), and also making the transition to 64 bit code less painful; I can see 'long' being a 64 bit quantity in the not-too-distant future, and it would suck if LONG and long were different integer types (LONG would have to remain 32 bits if we're keeping it around for backwards compatibility). That's just a guess, though.

Naming integers int32, uint32 etc is also a standard procedure, C99 has a header (inttypes.h IIRC) where these typedefs are stored. We left K&R C behind, it's good to know that when we move to C99 we won't have to change our source code.

Quote:

Heh, I hadn't noticed that. At a guess, making things more modern (there are a fair number of desktop CPUs out there a word is 64 bits, and on the rest it's 32 bits), and also making the transition to 64 bit code less painful; I can see 'long' being a 64 bit quantity in the not-too-distant future, and it would suck if LONG and long were different integer types (LONG would have to remain 32 bits if we're keeping it around for backwards compatibility). That's just a guess, though.

Why would it "suck" if LONG and long were different? If they were meant to the the same by force, then there would have been no need to use one in place of the other one to begin with, one would just have used one the compiler provided, that is long. On AROS LONG is fixed to 32 bit, simply because of backward compatibility, and QUAD is 64 bits.

Quote:

Naming integers int32, uint32 etc is also a standard procedure, C99 has a header (inttypes.h IIRC) where these typedefs are stored.

Mmm, not really. The header is stdint.h, and the types have a trailing _t, as it's usual for ISO C type names (the trailing _t helps avoiding clashes, and stands for type). So, this change makes things no more standard than they were before. But anyway, even if those were the standard types of c99, using them certainly wouldn't make a program written for AOS4 more portable than if it used one of the old types: it's not like AmigaOS4 API's were "standard".

_________________
“It is well enough that people of the nation do not understand our banking and monetary
system, for if they did, I believe there would be a revolution before tomorrow morning.”
~~ Henry Ford

@Bodie_CI5

Quote:

Oh no! You're all breeding!

I think they're all clones. Well, the original pair seem to have worked out okay. (FriedEin and FriedZwei) Third one looks like a nice addition. (Thanks for the screenshots, btw, new clone-guy! )


But please, don't ruin your lucky streak by creating an evil one. You know there's always an evil one when you push these things too far, don't you?

@ssolie

Quote:

Seems the market is wide open for an OS4-native text editor at the moment.

Maybe I should nag Martin Reddy some more about digging up the sources for the latest EdWord version then?

It's in GFA Basic though, so some clever git with some programming skills ought to rewrite that in C for OS4...hint, hint, nudge, nudge...

_________________
A1G4XE, OS4-pre

Quote:

Why would it "suck" if LONG and long were different?

Oh no, it wouldn't suck at all. While we're at it, why not make Short into a typedef for float and Long into one for double. No-one's going to get confused.

The whole point for typedefs like these is to isolate compiler implementation differences. Back in the days of AmigaOS 1.x, some compilers were using 16 bit integers and others 32 bit integers, so what the guys putting together the first NDK did was to come up with some typedefs (probably #defines at the time) that the compiler vendors could use, so that if my program uses SHORT, it will be using a 16 bit integer (which in compiler A might be an int, in compiler B it might be a short). The way they avoided clashes was to use uppercase for the names of the typedefs. With 20/20 hindsight, one can tell that they should have used names line INT16 and INT32, but that's the way things turned out. Now that AmigaOS is getting an overhaul and people are expecting some bumps in the road (and there are a lot fewer developers), is the best time to redress those past mistakes. Right now you're likely to piss off a few dozen people from the changes - if you introduce this change 5 years from now you'll be pissing off a few thousand.

Quote:

But anyway, even if those were the standard types of c99, using them certainly wouldn't make a program written for AOS4 more portable than if it used one of the old types

They would be as portable as a Windows program that uses HWND: the point is to make programs compatible with future AmigaOS NDKs, and shield them from differences in compiler implementations.

Quote:

Oh no, it wouldn't suck at all. While we're at it, why not make Short into a typedef for float and Long into one for double. No-one's going to get confused.

Using this kind of sarcasm will lead you nowhere. First of all, you went way too far with your "sarcastic suggestions", as you're suggesting one would define what is intuitively considered an integer type as a floating point type, which is not what I suggested. Basically, the confusion there would come from something totally different than what we were talking about.

LONG is not to be confused with long, it has never had to be confused with long, don't see why it would be confused now.

Besides, I've made a further point which you've avoided answerin at: if LONG were meant to be the same as long, why use LONG at all?

LONG there means "long word" as on a 68k architecture, which means 32 bits. Windows uses the same approach, except that it calls it DWORD. Moreover, SHORT is deprecated, and WORD should be used instead (see, that goes to show that the intent was NOT to have the AmigaOS types mirror the compiler types, or else SHORT would have stayed).

Quote:

The whole point for typedefs like these is to isolate compiler implementation differences. [...]

No need to tell me that, I'm very well aware of the issue, but I don't get your point: I know why UWORD and friends were there, and that's for the same reasons uint16 and friends are there now, and since it's well known that UWORD is 16 bits, just like it's well known that uint16 is 16 bits, and since none of them is any more standard than the other, I don't see any gain in exchanging one with the other: if it ain't broken, don't change it, as they say.

Quote:

hey would be as portable as a Windows program that uses HWND:

Ehum... HWND is an entirely different beast. It's simply an opaque handle to a window object, it has nothing to do with type sizes.

Quote:

the point is to make programs compatible with future AmigaOS NDKs, and shield them from differences in compiler implementations.

This goal was already achieved well before the "old" AmigaOS types have been deprecated by Hyperion.

_________________
“It is well enough that people of the nation do not understand our banking and monetary
system, for if they did, I believe there would be a revolution before tomorrow morning.”
~~ Henry Ford

@falemagn

Quote:

What's the reasoning behind deprecating the standard (so far) AmigaOS types, like LONG, WORD and so on?

The reasoning is already clearly explained in the "AmigaOS 4 Migration Guide" which is included with the SDK all OS4 developers will be accessing shortly.

_________________
ExecSG Team Lead

Rogue wrote:
Quote:

I just ported ViM 6.2 to OS 4

This all looks better and better. And now with vim, it's about time for me to get that A1 and start some Amiga development again.

Quote:

LONG is not to be confused with long, it has never had to be confused with long, don't see why it would be confused now.

Really? I admire your certainty. Have you ever gone to a programming class, or are you one of those rare gifted individuals who could write a shell sort before he knew how to walk?

Quote:

LONG there means "long word" as on a 68k architecture, which means 32 bits. Windows uses the same approach, except that it calls it DWORD.

For the sake of expediency I'm going to just assume that you're correct, and that is what "LONG" really means (as opposed to, say, "the same type as 'long' in the compiler used in-house to write AmigaOS 1.0"). If we wanted AmigaOS to stay a 3.1 clone for ever, that would make perfect sense. However, AmigaOS is now a PPC OS, and PPC is quickly going 64 bit. What type do we use to represent a 64 bit integer, ie the natural machine word size? QWORD? If a machine word is 64 bits wide already, what does the Q stand for? If you look at the drafts for the new "longhorn" Windows APIs, you'll see that Microsoft also wants to get rid of the old 16 bit baggage. In fact, in C# a "long" is a 64 bit integer.

I'm starting to think that you're just pissed off that the new typedefs introduce source incompatibility with AROS, and that is the real reason why you don't like the deprecation of the typedefs (I'm not going to go into religious territory, but that reason has also crossed my mind). In the time it took you to write your "I want my old typedefs back" post, you could have written an "os4types.h" file, which would have made this whole thing a non-issue for AROS. I guess getting it off your chest gave you more satisfaction.

@ Codesmith

On the issue being discussed, I agree with you, but...

Quote:

Have you ever gone to a programming class, or are you one of those rare gifted individuals who could write a shell sort before he knew how to walk?

... fabio is a stubborn @#$ sometimes, but there's no need to personally question his programming ability.

Oh look, now I'm the guy no one asked an opinion from who should shutup

@csirac:

I'm not questioning his programming ablity (I've mentioned a few times that I find him to be a very competent programmer), just his inability to see that not everyone is at his level (in a programming class, you'll see some people cruise and others struggle). When I read his statement saying that having a LONG and a long being different integer types was not confusing, it reminded me of all the time I've spent teaching people why it's a good thing to have different kinds of integers in a programming language. If I'd had to explain to them that, on top of all that, LONG and long are not the same thing, I would have been chased out of the classroom!

@Fabio

"LONG is not to be confused with long, it has never had to be confused with long, don't see why it would be confused now."

uh? I thought it was the same. Maybe because I don't read the manuals, but with my logic I think something like this:
#define LONG signed long int
#define ULONG unsigned long int

etc...
It's the first time I heard that LONG and long weren't the same.

Taking a look at the Basilisk2 sources I think I prefer something like that...
uint16, uint32, uint64, etc... that way we avoid confusion. We can keep the old standard for compatibility but if LONG isn't the same as long then we have a problem and we should use something more intuitive (like uint32, uint16...).

I think that 99% of people will think the same as me.

_________________
The only spanish amiga news web page/club: CUAZ

Quote:

"The Redzone is for loading and unloading only. there is no parking in the redzone" "The White zone is for loading and unloading only. there is no parking in the white zone".

It seem somebody has been watching "Airplane!" lately

Cheers,

Seppo

_________________
"Those are my principles, and if you don't like them... well, I have others." (Groucho Marx)

Quote:

It seem somebody has been watching "Airplane!" lately

Funny, I've been playing Tron 2 for a while now, and I would easily imagine such zones coming from that game.

Quote:

There's an icon in there for a file called "os4_libraries_devices.pdf". Would that be the new RKRMs?

No, just some comparison guide comparing old libraries to new ones...

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment

Quote:

What's the reasoning behind deprecating the standard (so far) AmigaOS types, like LONG, WORD and so on?

They are still available.

However, there's a problem with the term "WORD": A word on the PowerPC is a 32 bit integer, while a WORD on the 68k is a 16 bit integer (which is a halfword on the PowerPC). To avoid confusion, the new types (with bit count) where introduced.

However, the old ones are still available. We just thought that it was a good idea to clean up with this.

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment

Quote:

What's the Redzone?

The Redzone is the stack bottom. If it's damaged, your program probably used too much stack.

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment