Hyperion Entertainment Message Boards

If you have the latest V54.16 SDK from:
https://hyperion-entertainment.com/index.php/downloads?view=files&parent=30

you should be able to find the struct ConsoleWindowData definition in "SDK:include/include_h/dos/dosextens.h" and documentation on the ACTION_OBTAIN_CON_INFO/ACTION_RELEASE_CON_INFO ...

In newlib the buffering mode for stdout will default to line buffered (i.e. buffer is flushed implicitly if full or when a newline character is written) if the stdout file handle is a terminal. To see if stdout is a terminal it checks with IsInteractive(fh) and then ObtainConsoleDataTags(OCD ...

@OldFart

If you don't need vbcc support you could try deleting the file "SDK:newlib/include/stddef.h" to see if it helps, or produces a different error.

I've added support for AmigaOS namespace in the <libraries/screenblanker.h> and <libraries/blankermodule.h> header files now (will be released with next updated SDK, I guess).

I just tried renaming RAM:T from an ASL requester and it works without any problems here (as in the directory gets renamed on WB as well). I assume you haven't done any changes to RAM:T on your system and it's still a regular directory (and not a soft link)?

You should pass a copy of the Input() file handle (as gained from DupFileHandle()), rather than the file handle itself. Also there is no need to make a copy of the string for NP_Arguments (dos.library should handle that according to the autodoc).

Edit: That is if you want the program to have the ...

@alfkil

In your code you are passing the parent Input() file handle directly to the child using NP_Input.

If you read the WARNING section in the dos.library/CreateNewProcTags autodoc entry (second paragraph) you can find there an explanation why doing this and providing NP_Arguments is bad ...

Are you sure that this is reproducible with RAM:?

I've tried reproducing this issue both with RAM: and an SFS\2 partition but with no success on either my FE update 2 or my beta OS installations. It could be that it's a file system specific problem as the ASL code holds a lock on the file to be ...

Okay, I found the problem: The fpclassify macro is first defined in a compiler generic section nearer the top of the header file and then defined again lower down in a VBCC specific section.

This modified math.h header file should fix the double macro definitions when using VBCC:
https://www ...

Since it complains that fpclassify is being redefined unidentically can you find where the other definition is (is it in the program you are compiling, a vbcc internal header or ...)? When using gcc and it encounters a problem like this it lists also the previous definition which is a quite handy ...