Quote:

Yeah, but all this debugging options are annoying, tiring and slow because for whatever reason you have no version of MOS hosted on top of Linux or Mac (instead of Quark) so you cannot do nice fast (reboot os + app in fractions of a second) debugging on single machine with everything still running at basically native speed and your tools (text editors) staying up and untouched after full OS crashes and tons of debug output also basically not slowing down things much at all. And possibility to use gdb and hardware watchpoints and stuff.

I only partially agree because the vast majority of good software that has been used for decades will not run properly or at all on MorphOS. If MOS/Amiga had lots of good options for say finance, ok go to another one and all is fine. That simply isn't the case, the limited selection of really decent Amiga programs do not work.

I see MOS more valuable if it makes the users life easier by keeping compatibility with legacy programs. It is about the software to get the job done so we can enjoy life at the end of the day.

I have reached out to a few authors to find source code, with no success thus far. Perhaps MOS could offer a paid service to patch the software somehow to make it work.


Quote:



[ Edited by matt3 22.07.2022 - 05:03 ]

Quote:

How about writing your own finance software with MUIbase?
It's easy and portable. I may help you

Hi Matt3,

MUIBase is a good choice. I use for a lot of things. I can send you some examples if you are new to MUIBase (and programming).

Tom

Well, speaking of MUIBase, how did the author created on the main.bbs example the MAIN(button) (emphasis on button) as it can be seen on the Structure Editor -> Main Window layout? I mean, creating a new "Main" table never gets displayed as Button... Any ideas?

[ Edited by Cool_amigaN 24.07.2022 - 00:18 ]

@matt3
Have you tried Digita Money Matters? I don't know how well it works under MorphOS though.

Quote:

Ahm, no.

As some people here know I use a PowerMac G4 933 Mhz for all my MorphOS software development and have all this stuff turned on. This system has two graphic cards. A Radeon9000 with 64MB and a Voodoo3 with 16MB of graphics memory. So you can clearly see it is at the lower end of all systems supported by MorphOS.

I have faster systems (like a 2 Ghz G5, iBook, Macmini,…) of course, but I mostly never use them, because I want to see sluggish software as soon as possible to point at it. When developing on a fast system you might not even notice design flaws or slow algorithms.

The boot time is usually not an issue. It is less than 30 seconds or so. Nothing to have a quick boot for. Just insert an SSD if you did not already. My PowerMac has a 64GB SanDisk SSD connected via an IDE2SATA dongle, so the 45MB/s are limiting the overall loading speed, but this is only an issue when loading bigger files like MPlayer, Wayfarer or Iris. MorphOS is usually very stable.

I also do not reboot my system that much during development. If something crashes I simply close the windows, minimize the shell and continue. Usually the system stays stable enough, which sometimes results in a desktop with 20+ iconified console windows I launched a binary from, that crashed. In very rare cases I kill the system, which is usually some missing result pointer check or a use after free issue.

One could say that compiling on such a system is slow, but thanks to the build in drive cache most file actions are buffered anyway. Sure this is not compensating the lack of processing power, but with a proper makefile handling dependencies it is not that bad.

I personally also do not wait for the compiling process to be done. We have multitasking, so there is no waiting. I clean up the source in the mean time. I revise and optimize code, add comments and useful debug lines. In the end this results in better source code, less bugs and therefor less debugging.

Speaking of gdb I actually have no clue about it’s state under MorphOS, but I think it works and is used. I personally just need a serial debug output to screen via Logtool, since all my functions have an entry and exit output, I usually can pinpoint a crash right away to the causing function anyway. All I need to do is turning debug on for all project files.

Same goes for memory violations. The function name is above and a hex dump shows the memories contents, so I even can identify the structure or data field by its contents.

Quote:
That sounds lovely and all.

But may I ask: have you ever tried running Odyssey on AROS hosted? It either crashes AROS hosted on Linux within, as you put it, "fractions of a second" or essentially hangs after eating 100MB of memory after partially starting up.

So, the one AROS application that could really truly benefit from heavy-duty debugging tools and fast testing methods cannot be used in the way you describe.

I genuinely wonder if deadw00d could have even created the AROS version of Odyssey with a 202x version of AROS hosted and a similar time budget.

Quote:

Well, I guess the only chance to get anywhere with it is to patch the software somehow to improve compatibility with MorphOS.
I didn't really look into it myself yet but it basically sounds like a viable option if the issues are not too complicated (compared to adding more legacy compatibility layers to the OS itself).
A paid service adds some implications like piru also pointed out, though.


[ Editiert durch cyfm 25.07.2022 - 05:24 ]

Quote:
There are numerous problems with this:
- The biggest issue is that there is no guarantee that the patching could even be done in the end. So it's hard to offer paid service that doesn't guarantee a return.
- Second is that many software titles explicitly prohibit reverse engineering or tampering with the files. While it could be argued that while this patching only improved compatibility, it still would be technically not legal if the license prohibits it. It is unlikely that legal trouble would arise, but at least I personally wouldn't want to risk it.
- It is very difficult to estimate the amount of work needed to patch some application. It could easily end up being huge amount of work (far more than the payment would be).
- It could also lead to issues later if the supposedly "fixed" application has some other, yet unidentified issues. So the fix wouldn't be complete, yet money was paid. What would happen in this case?

Quote:

I don't remember. I have only older AROS builds. It's normal that an AROS app crashing causes AROS hosted itself to crash. When debugging (you normally need a AROS debug build) you always debug AROS itself as a whole by launching AROS hosted with gdb from Linux. Then when crash happens (if it's a hang you can use CTRL+Z in Linux shell where gdb is running to break into gdb) you can use "bt" to show backtrace. There are AROS custom gdb commands (from ".gdbinit" file): "thistask", "taskready", "taskwait", "bttask <taskaddress>" (to see what other tasks are doing at the moment), "semowner <semaphoreaddress>" (for deadlocks, if you see a task stuck in obtainsemaphore. To see which task currently owns sem). If backtraces show "??" instead of function names there are commands to load the symbols. "loadmods", "loadbt", "loadseg <address>", ...

As said I don't have recent AROS builds, so I don't know if it all still works (or works like that).

Even with no debug build of AROS (and app) you can still try running it through gdb and then do a "bt" and maybe "disassemble <address>". If the disassembly shows stuff like "xmm0" (SSE stuff) then you may have run into stack alignment incompatibility they created in Linux 32 bit x86 some years ago when they changed default stack alignment to 16 bytes. This breaks old code (or other code which ignores it) if that code calls into new 32 bit libraries (like libX11, libxcb for gfx functions calls like being done by AROS hosted X11 gfx driver) which rely on that 16 byte alignment. So if you are running a 64 bit Linux distribution and you are running into this easiest fix might be to recompile this problematic 32 bit libraries with "-mstackrealign" flag.

You probably get better answers/suggestions on AROS Exec, as I mostly just know how it was some years ago when I still used 32 bit Linux distribution and older AROS versions.

Quote:
I had tested it with AROS from all the way back in 2016 too. Trying to run any of the standard Odyssey binaries found on AROS Archives will either quickly result in a hung app or crashed OS.

Quote:
deadw00d's Odyssey builds do run reasonably well on AROS native, yet when you run them on AROS hosted they do not work.

Would you say this normal?

Quote:
As far as I can tell, this has not worked with a large app like Odyssey for at least 6 years.

Quote:
In an attempt to emulate deadwood's own development set up in 2015, I was running Ubuntu 14.04 i386 (32-bit) when I tested it.

deadw00d mentioned that AROS hosted "became better at detecting memory override problems" compared to AROS native. He suspected that this may be the cause.

Either way, it is a jarring incompatibility between the hosted and native AROS versions.

Quote:
There do not really appear to be any answers to any of this.

Quote:
While MorphOS doesn't run hosted, it does run in QEMU. This offers all the same benefits as running hosted, and allows for even more flexibility than running hosted (since I can easily do the debugging and testing on any system, regardless of the host platform).

I do most of my debugging (except things that really are specific to some exact hardware) on my MacBook Pro M1 Pro.

@Tom and Polluks
Wow, thank you both for the generous offers. I will slowly take a look at MUIBase as my time permits. If everything clicks and comes together for this I will certainly reach out to you. Currently my time is pretty tight, but I will try and make sometime to look at is.

@Walkero
I looked at Money Matters in the 90's and I can't remember why I didn't like it. I will see If I can dig up a copy and see what the reason was. There were a few other systems like 2+2 and home budget, don't remember them either. From my findings the real old accounting software works decent with MOS, but they really cumbersome and not a good fit. Newer products say in the 90's tend to have more difficulties with MOS, they are all over the place for functionality. I did and exhaustive search in the mid 90's and CIO really is a really good accounting system. I chose all my software in the 90's with such diligence and most of them don't work in MOS LOL.

@Piru
Thank you for explaining the difficulties in patching.

Seems like my best options are to find source code or to use my classic system. Still waiting to see if I can reach Jim Philippou the author of CheckItOut. I did reach the developers of AmiBack and sadly the source seems to be lost forever, shame Amiback is really a great backup program...

Thanks to all who have helped me with this!

[ Edited by matt3 25.07.2022 - 11:47 ]

Quote:

Lost source? Maybe a job for Ghidra
However we have Diavolo Backup.

[ Editiert durch polluks 25.07.2022 - 16:33 ]

Quote:

After some hassle I managed to compile newer AROS hosted version (deadwood's altabiv0).

Then I tried odyssey/owb 1.25 binaries. First it crashed because somewhere in update_prefs() it did not check whether program icon (diskobject) loading succeeded (0 access). Then it started and I found out how to reproduce instability. It turns out stack size for "[OWB] Timer" somehow was allowed to being too small (4096) (for AROS hosted where some stuff on Linux side uses Exec stacks too). Changed exec/NewCreateTaskA() to not allow stack sizes smaller than AROS_STACKSIZE.

Then quick tests seems to indicate it is no longer unstable.

Debugged with gdb.

> we have Diavolo Backup.

He's probably aware :-)

Quote:
Great. Did you submit a patch to deadw00d's repository?

Quote:

Andreas you never disappoint! :)

@Polluks

I starting using Diavolo for MOS, recently and reluctantly. It complicated things, now I have to track 2 different softwares and I cannot interchange them as I would like.

Diavolo for 68k won't write across a network and doesn't have a scheduler.

Amiback is really the best backup solution for the Amiga, believe me I know I even wrote a review! I remember from many of the Amiga mags I used to read they pretty much said the same. Now it seems lost forever... I have a problem that I research and test what I'm using against other options to a silly extent... If I claim something is the best, it is proven believe me! If you want a personal finance software with a real good revenue/expense statement and balance sheets crossing multiple accounts and real fast processing and allocating features, the only answer is CIO. Jim (the programmer) really must understand accounting and I assume that is why he wrote it because of the void, it was very well conceived and really makes life easier for the user, you don't have to be an accountant to use it but it has the features if you are. Homebank is a very distant second. If you wanted to run a manufacturing or wholesale distribution then only the old school Easyledgers, Amiga Keep Trak, or Phasar are your options as they are true subledger driven chart of accounts with more controls and inventory. For a small business or home finance it is using a bazooka to take out an ant hill and slow to process and report. The old school software from the 80's are really locked down on features, they may function but it will be a hassle.

Seems like sloppy coding wasn't that big of a deal back in the day, even with very mature products, Amiback for example had major version releases and many updates in versions. Crazy that Piru had to spend all that time to identify the bad coding. I guess if it ran stable and didn't crash that was good enough.

Such is life.

[ Edited by matt3 25.07.2022 - 12:13 ]

@matt3

I 've copied (backed up) more than 100GB over the network using a combination of NetFS and MirrorCopy under a straight session. You can create some scripts for the latter to even run incremental "back ups" on demand if I recall correctly. Anyhow, I highly recommend this solution.

There are tools/scripts (such MUIWake, MirrorCopy and NetFS) which could be combined under a GUI and have a great back up solution. Hope one could contact the authors and work together closely to create something similar, imho.

Thanks for sharing Cool_amigaN.

I forked to Diavolo for MOS for now and keeping AmiBack on the 3000's. There still may be a longshot that AmiBack may run under MOS if the business owner of AmiBack can find a new/different version. Which will get me back on the same base.

Your idea seems to have some nice potential. Maybe it will bear fruit.

If you move it along let me know!

Quote:

Great news!

I tried running CheckItOut on a different PowerMac G5 and on a Powerbook G4 and it works perfectly.

So my 2.3 must have an issue with it, it has been getting flakey once in a while.

So no issues at all with it so far, thanks for the help everyone. Strange the 2.3 works with everything perfectly, but refuses to run the one program.

Once I get cooling sorted on the new G5, I will switch over to it...

What are the benefits of using a program over an internet based platform?

I was using Bokio, until they went behind a paywall for 2 or more money streams. Now I use Zoho Books. They automatically pull through any money movements and try to work out what they are. You can also do invoices from them.

So what benefits do the programs in the OP bring to the table?

My goal was to use an Amiga/MorphOS native accounting program. CheckItOut is best that the Amiga has for accounting. The benefits are that it gives real financial reporting (balance sheets and income statements), you can manage multiple accounts and easily report them how you want, a fast entry, good reconciliation, and a bunch of other things. If you have very simple home accounting needs something like Pretium might be fine. I might be willing to sell you Pretium for what I paid for it, I bought it a few months ago NIB if you were interested.

If homebank was stable (under MorphOS) it would be good also. I have tested over 10 accounting systems over the years, so I know what the Amiga has to offer in that department. Very happy to have it run well on MorphOS. It seems somewhat stable on AmigaOS.

Certainly web based solutions probably offer the same or more in features, but I wanted all my finances off the cloud and on my own systems. MorphOS is really impressive that you can actually run a business off of it, with high productivity.



Quote: