Amiga OS 3.3 top 3 "must have" features (Wishlist)

[Mathesar]

Originally Posted by Thomas Richter

I wouldn't suggest doing so - to my knowledge, the library still does not handle long file names properly. Something changed there from 3.1.4. onwards, and the code needs to be monitor where a file system truncates the name instead of relying of a now obsolete user setting.

Couldn't that be added? PeterK's icon.library is such a massive speed improvement!

[Thomas Richter]

Talk to Peter, not me.

[alexh]

The biggest improvement (patch) to Amiga OS I ever tried had to be TLSFMem by Chris Hodges aka platon42 who did Poseidon USB stack. It increased AmigaOS performance more than anything I'd seen. It was so close to being finished and becoming a must have part of AmigaOS when Chris left the scene. He did a few patches after but it never quite left beta. Something like this (if not a continuation of this work) would be great

[Thomas Richter]

This is probably no longer as much needed as it was in 3.1. In 3.1.4, the prime sources for memory segmentation were already removed, and those are ClipRects (layers V45 fixed that) and Regions and RegionRectangles (graphics V45 fixed that). Other than that, I would suggest PoolMem, which also keeps a scratch list for small memory allocations. That is probably already sufficient to speed up the rest as it buffers small blocks in a scratch list.

Note that the singly-linked chunk list of Amiga memory is unfortunately documented and thus some programs depend on it. This limits the design space any alternative implementation can live in.

[alexh]

Thanks for the explanation

[Tpod]

1. True Type fonts support – ttflib from aminet is generally OK but imho improving built in support for common font types (outside Amiga) would be a real plus for the OS.

2. Unzip Utility – I would think & hope this ones on the to do list/being done anyway.

3. MultiView able to view PDF's – Not a “must have” but would be great. There is no PDF viewer for 68000/10 Amigas that I know of, so it would be particularly nice for people like me with low end 68000/10 accelerators; all but small/simple PDF's would be painfully slow using ECS + 68000 but something is better than nothing!

[roberthazelby]

My suggestions are:

- Built in TCP/IP stack
- Ability to print to PDF

[QuikSanz]

Speaking of Printing, Ahem, we could use something better there too. A decent imitation Turbo Print would do.

Chris

[Thomas Richter]

Originally Posted by Tpod

1. True Type fonts support – ttflib from aminet is generally OK but imho improving built in support for common font types (outside Amiga) would be a real plus for the OS.

Why would the result look any different from what you have now?

Originally Posted by Tpod

3. MultiView able to view PDF's – Not a “must have” but would be great. There is no PDF viewer for 68000/10 Amigas that I know of, so it would be particularly nice for people like me with low end 68000/10 accelerators; all but small/simple PDF's would be painfully slow using ECS + 68000 but something is better than nothing!

APDF exists, and frankly, this would be really very slow on a plain old 68000, I'm not sure whether this is "better" by any means.

[Thomas Richter]

Originally Posted by QuikSanz

Speaking of Printing, Ahem, we could use something better there too. A decent imitation Turbo Print would do.

Chris

In which sense? The current printing system had been enhanced for 3.1.4 already, more printers, and high- and truecolor support is all on board, and the system is working - unlike the printing system of 3.9 which was seriously flawed due to a defect in its buffer management. The trouble is more finding sufficient information for printers - most of what you get today are Windows GDI printers, depending on the windows system for rendering, and proprietary unpublished interfaces. This rules out any third party support. Two types of printers remain: postscript printers, which are supported, and PCL based printers. These are the two families of open printer languages you find today (besides Windows GDI I mean), and they are both in the Os.

[Tpod]

When it comes to using ttflib for True type font support I new I had some issues with it before. Tried to install some new fonts on my A2000 & get Software failure when use FIX FONTS (error#80000003). I know it worked better on one of my A1200's in the past.

Even if ttflib was 100% without issue as I said l think TTF support as standard would be a real plus.

APDF requires 020+. I was really thinking of it being usable (for small/simple pdf) for accelerators like my Supra28 i.e. accelerators based on a 68000 or 68010 CPU.

As with TTF support having PDF support out of the box would be nice because its such a commonly needed/useful feature (one less add on needed after a fresh install).

[daxb]

You may try ghostscript: http://aminet.net/search?query=ghostscript

[Tpod]

I have vague memories of trying to use goastsript to view PDFs years ago … unfortunately not pleasant ones! I sort of got it to work in the end but with a recoverable alert or something similar & that was only when I used an extra old version. Cheers for the suggestion though.

[desiv]

In my mind, my concern with something like Ghostscript is that while it is a great app for Linux or Windows, it was designed for those environments. Meaning that it isn't really designed to be lean...
And while I might not call Ghostscript on Linux bloated, I do think that I might call Ghostscript for AmigaOS bloated. ;-)

For my other thoughts, I do think possibly an integrated TCP/IP stack is great, if perhaps there are some "standards" or something around a TCP/IP stack that would make it better, then maybe that is more important than the stack itself.
Not sure what that would be tho, so that might just be silly.
But I think of our current stacks as the "Trumpet Winsock" for the Amiga. Whereas TCP/IP was integrated into the later versions of Windows. So, is there anything that needs to be done OS wise for a TCPIP stack (part of the OS or external) to work better?
If so, then that might be more important.
Of course, I might be way off and that's just a stupid thought too... Probably more likely. ;-)

[spudje]

Originally Posted by Thomas Richter

There is a small tweak of the scsi.device that enables the second channel - just use LoadModule to load a dummy resident module named "ATAPIismajik" (it doesn't have to do anything, it just needs to be present), and you have the second channel - maybe, depending on your hardware.

I tried with Atapimagic/atapismajik but never got a CD working (with CDFileSystem). I have seen others get HDDs working on the 2nd IDE, but never a CDROM. I always had to revert back to a minimal IDEfix setup, with just using atapi.device & CacheCDFS.

[Thomas Richter]

As stated, the thing is not tested well enough. However, the file system layer is completely independent from that, so there is no need to use CacheCDFS.

[Rene_1974]

I only have 2 wishes

1. A built in unpack / pack utily that can unpack LHA and ZIP files, as those are the most common packer programs.

2. Built in network funtionality, because its not easy to get networking work when you're emulating an Amiga.

[Phantasm]

Originally Posted by Rene_1974

I only have 2 wishes



1. A built in unpack / pack utily that can unpack LHA and ZIP files, as those are the most common packer programs.



2. Built in network funtionality, because its not easy to get networking work when you're emulating an Amiga.

When you are emulating the Amiga (at least in winuae or fsuae) you don't need to install any networking software. It can be handled by the emulator just by enabling bsdsocket.library emulation and it works extremely well. In fact I see that as a good reason for not bloating the os with it.

[eXeler0]

Originally Posted by Phantasm

When you are emulating the Amiga (at least in winuae or fsuae) you don't need to install any networking software. It can be handled by the emulator just by enabling bsdsocket.library emulation and it works extremely well. In fact I see that as a good reason for not bloating the os with it.

I think he might have meant that its difficult to set it up on an emulated system in a way’d want when you try to install /prepare a cf card for use in an actual Amiga?

[Phantasm]

Originally Posted by eXeler0

I think he might have meant that its difficult to set it up on an emulated system in a way’d want when you try to install /prepare a cf card for use in an actual Amiga?

Ok that makes more sense.