@Slash:

I guess it's a Sam 440ep-Flex (with PCI graphics card)? Your new graphics card is sure to support 1920x1080.

If on the other hand you are getting an older Sam 440ep with built-in Radeon M9 graphics, it might be working a bit hard trying to keep up with 1920x1080. You may find you can do better by using a lower resolution.

In both cases, if you open Prefs/Screenmode and select the Monitors tab, you can select the "Detect settings automatically" and "All supported modes" buttons, then, after a reboot, you'll see all the modes that the monitor can display. You can then choose something less taxing.

Don't make my mistake and use a DVI-VGA adaptor between the cable and the computer. All the adaptors that I've tried don't have the DDC conductors wired through, so the automatic detection can't work.

@Deniil

Try it with Notepad or any other system app - it works with them.

I seem to remember that I had to write down the current size and position of my window when it was iconified, then restore those values after un-iconification. Perhaps if you showed us your Window Tags, we could suggest a fix.

@djrikki:

Do you have the PIPE: driver in Devs:DOSDrivers? If not, you'll find it in Storage/Devs/DOSDrivers. Simply copy or move it across and reboot.

@djrikki:

Not everyone likes Mason's icons. To my tired old eyes they are much too faint and hard to interpret. I prefer stark colours that are easy to see.

@Antique:

Regarding EXT2 or NTFS: in order to do a thorough port, you would have to be familiar with the FS you were porting - that means being a Windows dev or a Linux expert. It's a bit outside my experience, I'm afraid.

In any case, I prefer to transfer at a higher level, eg FTP or SMBFS.

@Amigo1:

I don't think it matters how you connect the drive to the Amiga (USB, SATA or PATA), you will still need a filesystem to support the content. Until there is an up-to-date filesystem for EXT2 (or any of the others), you can't process I/O properly with a direct connection.

Your only recourse at the moment is the remote connection via FTP to the server.

It looks wrong, doesn't it? I would expect that when you rename one of the existing files, the name in the requester should not change (as kas1e said).

I'll put in a report about it.

He didn't claim he'd take it down, but take it over.

Seriously, though, I bet he's feeling amused that it just happens to have fallen over at this time.

When you use the button "Add Path", the added path is only temporary. When you exit the program and restart, the added path has gone.

It would be great if we could add our favourite paths to tooltypes and keep them for next time. For instance, I would add SDK:Documentation/Autodocs/ and SDK:include/include_h/.

IF you had "a proper debugger", you would use it to add breakpoints, then examine data at the point, right?

So just add some IExec->DebugPrintF() statements at the places where you would put breakpoints, and go from there.

Is that using AmiCygnix? Try it using a normal WB window.

@Daz:

Yes, I see the picture. Sorry, I've never seen one of those in the flesh, so I can't offer any help.

What sort of fan is it? There were several types used over the years.

A photo would help.

It still exists with the latest version.

How long ago did you send the email? I'll raise a formal bug report if you like.

@Raziel

If you want a trace of where the program went before it crashed, then you probably want a debugger with breakpoints, etc. GrimReaper is only a crash reporter, not a debugger.

The debugger that goes with the gcc suite is gdb, but no one has ported or compiled it for OS4 since the very early days, and things have changed.

There was a "graphical" version of gdb years ago but it was pretty ordinary. Have you tried Codebench? It may provide the support you need, although I don't know what it can do in the debugging functions.

If a "Stack Trace" is not a "back trace", then just what do you want? A trace of where you've been?

The most reliable way to get that is by using IExec->DebugPrintF().

If you have a crash log, post the guts of it (not all the system & library stuff) and perhaps we can help get some sense out of it.

Are you using the debug kernel?

It's changes in elf.library that have made the difference.

I use the alias "whereis", as in:

"whereis 5689" (you don't need the "0x" prefix)

The alias is "Alias whereis addr2line -j.text -sfe currimage []",

...which gives the name/line number of the source module and the name of the function.

Why not? Is it because you are doing it at work?

No, the only SCSI controller supported is the LSI53c8xx series.

@whose:

I think the "mess" is of your own making. No one should be using clib2 these days, it is not thread-safe and is obsolete. There is no problem using newlib calls mixed with calls to utility.library, although it seems to me to be a duplication: I can do far more with an "sprintf()" in C than I can do using utility.library, and I can look it up in any C textbook.

I still don't see a problem, but I'll leave it at that, we're getting nowhere with this discussion.