@whose:
Because that would only duplicate library code. Utility.library uses the C runtime library, just as Centaurz's code does.

@abalaban:
Quote:

Where does DOS come into this? I thought you were using utility.library? That does not use DOS.

BTW, many OS components use IUtility->SNPrintf() and C runtime calls and mix them up (I do it in many places); and we don't have a problem.

OK, I'll ask the question a different way - why use IUtility->SNPrintf() at all, if it doesn't do what you want (floating point) ?

By "native" calls, I suppose you mean AOS-centric calls? Why restrict yourself to AOS-centric calls? Why not use the standard, built-in C library that's already there? No one is going to think less of you if you use built-in calls and external-library calls in the same module.

Maybe I'm missing the point, but I don't understand your reluctance to use the standard tools provided.

Why do you want to use IExec->RawDoFmt() ?
What's wrong with sprintf() ? At least it's portable.

IExec->RawDoFmt() is an exec call installed for minimal I/O. It doesn't handle floating point variables [neither does its more modern replacement, IUtility->SNPrintf()].

Applications that want to output floating point are likely to use the C runtime library, so they can use printf().

It's not a kernel function.

You need a means to abort a running task/process cleanly and that isn't possible from outside the task, because you don't know what resources the task has allocated or requested. The way AmigaOS is designed, only the task itself can perform a graceful cleanup and exit. There are some hacks that can close somebody else's window, but they won't work once we get proper memory management.

Ctrl-C won't work unless the task is waiting for keyboard input. SIGF_BREAK won't work unless the task is written to watch out for it and obey it. We don't have any means to abort a task like Windows' "Exit Task".

Sorry, duplicating stuff that didn't appear (?) the first time.

@walkero

Love the new look, it's fresh and modern. I have no problem using OWB with it. However, I don't see a need for the "Reply" box at the end of every thread - in fact, it's probably only encouraging verbosity. I would have thought the "Reply" button was good enough.

I realise this sounds like a whinge and perhaps others don't find it irritating, but when I get to the end of a thread, I like to be able to return to "Home" with a single click ("Back" doesn't work if you've been reading the thread page by page). On the temp site, you (or Orgin?) were kind enough to add a "Home" link on the bottom of the page, but I see no such link on this new site.

Could we please have a "Home" link at the bottom? Otherwise I have to scroll back up to the top of the last page, then click "Home" in the links bar.

It's being worked on. I know the guy that's doing it (in fact, he has my 460 for development support at the moment).

Can't say how far he's got or how long it will take, dunno.

Because it's secret (you have to be part of the DRM cartel) and we're not a part of it.

@whose

Quote:

Quite right, and that is the opinion of the OS4 devs as well. It's OK to use ESC to close a requester, but not the main application window.

Multiview is an obvious offender in this example, and there are plenty of other applications that are just as bad.

@centaurz

[Just trying it]

Yes, you're right. I don't remember where I got that idea from, but I've always used DebugPrintF that way, so I've been doing it like that for years!

Alignment seems to be a problem only with 64-bit data.

@centaurz

You have to use the same strange formatting with IExec->DebugPrintF() as well. Even more, if you have some int64s that you want to print, you have to pad the int32s out to int64 if you mix them, since int64s are lined up on 8-byte boundaries.

For example, DebugPrintF ("%lld, %ld\n", int64, int32) works OK, but
DebugPrintF (%ld, %lld\n", int32, int64) will give the wrong result for the int64, you have to say DebugPrintF ("%ld, %lld\n", int32, dummy int32, int64).

@TSK

That's not a bug, as you'll find if you read the documentation. SNPrintf() does not behave the same as the printf()" in the C run-time libraries clib or newlib.

AmigaOS always puts 32-bit data on the stack, so "%d" will put a 32-bit uint32 on the stack. In the low-level functions like IExec->#? and IUtility->#?, you have to use the formatting codes "%ld", "%lx%, etc.

So your example should be changed to read:
IUtility->SNPrintf(str,sizeof(str),"%ld%ld%ld%ld%ld%ld",1,2,3,4,5,6);
...then it will give the right values.

For instance, if you want to print a single byte as a hex character, you must use "0x%02lx" to get say "0x41" for an "A".

Note also that SNPrintf returns a character count that INCLUDES the null on the end of the string (unlike the C run-time library printf()).

@RIBDEVIL

Now, that wasn't what he asked, was it?

@thomas

... or if there is an assignment to that disk volume or a directory on it...

@Deniil

It's easy to get the wrong values. The SpaceBox returns a pointer to an IBox, so you have to give it an address to write that pointer into. If you do this, it'll work:

struct IBox *spacePtr = NULL;

IIntuition->GetAttrs (SpaceGadget,
SPACE_AreaBox, &spacePtr,
TAG_END);
// The GetAttrs call returns a pointer to an internal IBox and writes that pointer into the address that you specify.

printf ("SpaceBox = Y: [%d:%d], X: [%d:%d]\n",
(int16)spacePtr->Top, (int16)spacePtr->Top + (int16)spacePtr->Height - 1,
(int16)spacePtr->Left, (int16)spacePtr->Left + (int16)spacePtr->Width - 1);

The only way to get the right background colour is to use IGraphics->RectFill() to fill the Space gadget before you draw your stuff into it.

If you specify a Bevel, it draws it on the inside of the box, but also occupies a 4-pixel margin around the inside of the box. That margin is redrawn every time the rastport is refreshed, so anything you put within that margin will be erased.

@ChrisH

OK, so I misunderstood, then. I must have missed that change, I thought they were all limited to 128 MB still.

My apologies to 'netrot'.

@netrot

The currently-released Radeon drivers can not handle 256 MB because it is usually broken up into two disjoint 128 MB banks.

It is for this reason only that OS4.0 and OS4.1 limited graphics memory to 128 MB.

@bright07

"OWB" is just a GUI written around the Sand-Labs web kit. If you want data about its features, consult the Sand-Labs website.

The OS4 version doesn't add or change any features of the web kit, it just draws the pretty pictures on an OS4 screen.

@Ant

Run MediaToolbox from System/ drawer. It will probably say that something has changed and suggest that you let it "fix it up". If you then click on "Info" (or something, can't remember), it will say something like "xxx is no longer last unit".

If you let MTB fix that for you, the system will henceforth recognise your new drive.