AmigaOS 3.2 released!

[Jope]

Originally Posted by Swe_Kryten2x4b

Toolsdaemon seems to trash execbase too (also a massive hack though).

Are you running 2.1a or have you applied the 2.2 patch?

[boemann]

Originally Posted by Steril707

Really happy with 3.2 so far. some of its features are kind of hidden at first glance, especially for someone like me who isn't an AmigaOS nut.

Love being able to shove windows out of the screen and the resizing. And finally having word wrap in the text editor. And the adf mounting. But also so many other nice little details.

I am happy you like the resizing. Getting the chance to implement that was the reason why I joined the development team in the first place.

[Tigerskunk]

Originally Posted by boemann

I am happy you like the resizing. Getting the chance to implement that was the reason why I joined the development team in the first place.

This feature is so crazy useful and such a huge improvement. I wonder why this along with dragging windows out of the screen is hidden in that icontrol prefs menu.

If there is one thing I wished for, it would be to have one "big command center" pref where you can switch on/off and change the biggest things in the Workbench.

Should have the aforementioned resizing and window offscreen feature, the stuff that's already in the workbench pref, and the theming that currently hidden somewhere in the menu bar of the palette pref.

I know now where I can find that stuff after reading up about it, but after installing yesterday I was a bit puzzled, like "so, where is all that new stuff now I have been hearing about?"

Anyway, great job you people did.

[gazsp]

Just wanted to say thanks to all the devs for their work on OS3.2. It's really nice to be able to finally get rid of a whole bunch of patches, and the whole OS feels solid and responsive.

If anybody wants to see how much work as actually gone in to this, I'd recommend taking a look at the release notes in the NDK.

Also, make sure to read the reference manual - there's a whole bunch of useful information in there, including some tips on how to change the way tab completion works in the shell.

[phx]

Originally Posted by boemann

No need for all these generation from FD and SFD. While technically correct, the NDK comes with these pre generated. If you don't trust us you are welcome to generate them on your own, but it shouldn't be necessary for any of the wel known compilers out there

Thanks. That's good to know!
I haven't seen the new NDK yet and was never contacted about vbcc support in it, so I just assumed the worst.

[npagonis73]

Originally Posted by Jope

Are you running 2.1a or have you applied the 2.2 patch?

Tools daemon works fine on Amiga OS 3.2. Just make sure you apply the 2.2 patch.

[boemann]

Originally Posted by Steril707

This feature is so crazy useful and such a huge improvement. I wonder why this along with dragging windows out of the screen is hidden in that icontrol prefs menu.

If there is one thing I wished for, it would be to have one "big command center" pref where you can switch on/off and change the biggest things in the Workbench.

Should have the aforementioned resizing and window offscreen feature, the stuff that's already in the workbench pref, and the theming that currently hidden somewhere in the menu bar of the palette pref.

I know now where I can find that stuff after reading up about it, but after installing yesterday I was a bit puzzled, like "so, where is all that new stuff now I have been hearing about?"

Anyway, great job you people did.

The answer to this is partly that each prefs editor has it's own prefs file, and since they can be run at the same time it would mean that different prefs editors would be changing the same file.

And the reason is also how these prefs files are applied to the system. Sort of the same thing, but yet another big change.

Finally we didn't want to touch the prefs editors this time around. In the future (but maybe not even 3.3) we have an idea that we might want to rework the prefs editors, so it will have to wait until that point to make things more logical.

[nogginthenog]

I just read on Amiga.org that the serial number is printed on the outside wrapper of the packaging.
Keep your packaging people!!

Mines gone to landfill

[QkiZ]

Originally Posted by nogginthenog

I just read on Amiga.org that the serial number is printed on the outside wrapper of the packaging.

Keep your packaging people!!



Mines gone to landfill

Yes, it's true and odd. Today i received my copy of AmigaOS 3.2 and serial number is sticked on transparent package foil.

[alancfrancis]

Originally Posted by nogginthenog

I just read on Amiga.org that the serial number is printed on the outside wrapper of the packaging.
Keep your packaging people!!

Mines gone to landfill

What is the serial number needed for? My ISO from amigastore.eu didn't ask for it on installation.

Is it for whenever we can register with Hyperion for updates ?

[boemann]

Originally Posted by alancfrancis

What is the serial number needed for? My ISO from amigastore.eu didn't ask for it on installation.

Is it for whenever we can register with Hyperion for updates ?

Yes it will be needed to get updates

[alancfrancis]

Originally Posted by boemann

Yes it will be needed to get updates

I shall make sure and hold onto it :-)

[Olaf Barthel]

Originally Posted by alancfrancis

Given a working, out-of-the-box install of SAS/C and a couple of folders e.g. Work:NDK3.2 or Work:NDK39. what do I need to do to configure SAS properly ?

bebbo-gcc downloaded and configured NDK3.9 for me as part of installation, VBCC asked for the location of the NDK during installation, but SAS (of course because of its age) has no awareness of this so I assume has to be manually configured somehow ?

Camilla has already covered this, but in case you want to start from scratch and replace everything in your existing fresh SAS/C 6.5x installation with what's in the NDK 3.2, I would suggest the following approach.

When the compiler's installation script has concluded and you reboot for the first time, have a look at the S:User-Startup file. It should have the following additions, if you installed the compiler to the "Work" device/volume:

;BEGIN SAS/C
assign sc: Work:sc
assign lib: sc:lib
assign include: sc:include
assign cxxinclude: sc:cxxinclude
path sc:c add
;END SAS/C

The files which need to be replaced are found in the directories pointed to by the "lib:" and "include:" assignments.

Start with the files which are used by the compiler and its assembler and delete only those which will be replaced by the 3.2 header files:

delete all include:clib
delete all include:datatypes
delete all include:devices
delete all include:diskfont
delete all include:dos
delete all include:exec
delete all include:gadgets
delete all include:graphics
delete all include:hardware
delete all include:intuition
delete all include:libraries
delete all include:pragmas
delete all include:prefs
delete all include:proto
delete all include:resources
delete all include:rexx
delete all include:utility
delete all include:workbench
delete include:all.gst
delete include:all.gst.info

Now copy the replacement files from "NDK3.2" to the "include:" directory:

copy NDK3.2/Include_H/#? include: all
copy NDK3.2/Include_I/#? include: all

Finally, copy the new link libraries:

copy NDK3.2/lib/#?.lib lib:

And that should be it

Note that the "include:all.gst" file is deleted as a precaution so that you do not use it by mistake. It contains all the old Kickstart/Workbench 3.1 header files in a precompiled form which can be helpful to cut compilation time. But we just replaced all the 3.1 header files with the 3.2 versions...

I recommend not to use "include:all.gst" file but to generate that precompiled global symbol table file in each of your projects as needed. The compiler options you use to generate these header files may have an impact on what is generated, and that may not be a file which works well with a different set of compiler options.

[Olaf Barthel]

Originally Posted by phx

It uses any NDK you like to use. Although I would recommend the kick13 configuration for Kickstart 1.x NDKs.

Are there any new static amiga.lib functions, which are not in a shared library? I doubt that. New shared library functions have to be added with fd2pragma: http://phoenix.owl.de/fd2pragma.tar.gz

Any real AmigaOS NDK comes with FD and probably even SFD files. You can generate the compiler specific proto and inline headers, as well as the amiga.lib stubs with fd2pragma, using a library's FD file and its clib file.

The NDK 3.2 comes with both FD and SFD files. The SFD files are actually reworked and updated, with CONST qualifiers for pointer parameters which are (according to a code review) referencing data not going to be modified by the respective operating system functions. Mind you, it's possible that future NDKs may update these again as new information on the operating system code comes to light with regard what pointers realy ought to use CONST qualifiers. Previous NDKs were not always correct, and likely NDK 3.2 might need fixes, too.

We have new and reworked interface files in the proto/protos/clib/inline/pragma/pragmas 'C' header file directories, generated from the updated SFD files. We tested these with the "old guard" (Lattice 'C' 4/5, SAS/C 6.x, Aztec 'C' 5.0b, DICE, GCC 2.95.3) but did not test specifically with VBCC We (meaning that it's my fault that VBCC slipped by) will try to do better next time.

Hopefully, all three essential variants (#pragma libcall/tagcall/syscall for Lattice 'C' 4/5 and SAS/C, #pragma libcall/syscall and #pragma amicall for Aztec 'C' 5.0 and the inline functions and macros used by GCC 68k) will cover all the corners. If not, please let us know what needs to be done.

Please note that support for precursors to C89/C90 (ANSI 'C'/ISO 'C') might at some point no longer be tenable. We did not test, specifically, if the old guard (Lattice 'C' 3, Aztec 'C' 3.6) could handle these header files.

[phx]

Originally Posted by Olaf Barthel

The NDK 3.2 comes with both FD and SFD files. The SFD files are actually reworked and updated, with CONST qualifiers for pointer parameters

Very nice!

but did not test specifically with VBCC We (meaning that it's my fault that VBCC slipped by) will try to do better next time.

Too bad. I would have been glad to assist.

Hopefully, all three essential variants (#pragma libcall/tagcall/syscall for Lattice 'C' 4/5 and SAS/C, #pragma libcall/syscall and #pragma amicall for Aztec 'C' 5.0 and the inline functions and macros used by GCC 68k) will cover all the corners. If not, please let us know what needs to be done.

No, vbcc has its own inlines. So I understand they have not been generated and are not included?

Not a big problem though, as they can be easily generated using the supplied FD files, and I will take care of that during the next vbcc release.

Please note that support for precursors to C89/C90 (ANSI 'C'/ISO 'C') might at some point no longer be tenable. We did not test, specifically, if the old guard (Lattice 'C' 3, Aztec 'C' 3.6) could handle these header files.

Unlike all these old compilers vbcc is C99 and supports 64-bit arithmetics.

[boemann]

Originally Posted by phx

Very nice!

Too bad. I would have been glad to assist.

No, vbcc has its own inlines. So I understand they have not been generated and are not included?

Not a big problem though, as they can be easily generated using the supplied FD files, and I will take care of that during the next vbcc release.

Unlike all these old compilers vbcc is C99 and supports 64-bit arithmetics.

Actually please help us out - we will very likely update the NDK rather frequently initially - so if you have input on how better to generate inlines for vbcc please tell us.

That said I know someone has tested the NDK with vbcc so it should work.

[Michael]

Originally Posted by E-Penguin

@ 3.2 devs: I had snoopdos open and noticed that whenever anything opens an intuition window, there's a failed attempt to load cybergraphics.library (I don't have cybergfx installed, or indeed, p96). Is this expected? Can I turn it off somehow?

Is it a clean install ? Or you have other things installed ?
A lot of programs and libraries called by programs can do checks for features and do optimized rendering based on the system configuration, so it's normal behavior for GUI toolkits.

[Michael]

Originally Posted by Akiko

A silly question perhaps, but does AmigaOS 3.2 exceed the feature set offered by AmigaOS 3.9, or is it an evolutionary catch up since 3.9 isn't being sold and supported anymore?

Most features should be available in 3.2, some needed to be rewritten from scratch or redesigned for better compatibility, performance or robustness since the code for some of them was unavailable.

But 3.2 brings in many new and revolutionary features never seen before even in 4.x series without overloading resources. In that respect 3.2 has caught up with 3.9 and superseded it. You are still able to use some of the 3.9 bundled applications that are not part of 3.2.

[phx]

Originally Posted by boemann

Actually please help us out - we will very likely update the NDK rather frequently initially - so if you have input on how better to generate inlines for vbcc please tell us.

I haven't seen the new NDK yet, so I'm still guessing what's in it.

I'm glad to help. Just contact me by email with a copy of the latest NDK, and I will test it and provide suitable header files. My address should be known, but you find it here on top: http://sun.hasenbraten.de/~frank/

[trixster]

Is anyone using a Deneb with 3.2 yet? Can the new rom modules be flashed into the Deneb flashrom like the 3.9 rom modules and boingbag elements can?