In the interview with The Aros Show Sonic said about Os4Emu:

| Instead of saying "Wow, they need our apps, it's good",
| they started to implement anti-os4emu protection. The
| project was closed under these conditions.

http://arosshow.blogspot.com/2007/03/hello-pavel-thank-you-for-doing.html

is this true?

Quote:

I hope not. But it sounds so irrational that it could very well be.

Well the anti-os4emu part is true, at least according to the
changelog

http://amigazeux.net/os4emu/hist.php

but this is the first time I heard that this made itix stop the development.

Why stopping the development ? IIRC a screen grab of OS4Emu 2.0 was shown some time ago.

Itix can confirm if the development is stopped or not.

Development is not stopped although I considered stopping it. New OS4 programs have OS4Emu check built-in (it is integrated to their new startup code) but my yet unreleased OS4Emu remedies this.

Anti OS4Emu code in apps? Now thats just childish! Do thes people hope to get the platform moving? OS4Emu is only a win win for both side. It lets us have more apps and gives the OS4 developers more users. Lame indeed!

Quote:

You must be pre-april fooling :)

The more they spend on paranoia instead of development, the more they will lag behind... It's a win-win situation for us. Keep it up!

Quote:

lol

Quote:

Nice to hear and I guess you will gain some new 'friends' by this...

Quote:

How is it implemented? The protection, that is.

I'm interested to know if it is the choice of the app. developer to turn this on for a build, if it's a short block that they put into main(), or whether it's been crufted into the compiler or SDK somehow.

I'd like to think I could credit Hyperion with being professional enough not to take such a childish measure.

[ Edited by nine on 2007/3/26 10:55 ]

@nine

It is part of newlib startup code. It just compares ExecBase pointer (passed as 3rd parameter to _main()) to AbsExecBase pointer. If they dont match startup code quits silently. This works against current OS4Emu release because fake ExecBase is passed to _main().

There is no option to turn it off but this code is only part of OS4 SDK available to beta testers. OTOH old newlib startup code had OS4Emu check but it was easier to fix because it relied on OS calls.

It will be interesting to see if startup code changes to the final SDK.

CLIB2 startup code doesnt have such checks and it would be useless since CLIB2 is open source project.

Quote:

Wow. Hyperion just went down in my estimation. Unless there's a really good reason for it.

[EDIT: removed part about newlib not being shared library, it is]

newlib is open source as well, isn't it? I think it's the BSD-licensed libc for embedded systems from Red Hat. http://sources.redhat.com/newlib/

[ Edited by nine on 2007/3/26 15:34 ]

I guess the good reason is that they have to eat and are banking on sales of os4/hardware for a little income? more people using os4emu, less sales i guess? which would be understandable.

if however it's some sort of childish rivalry game, then it truely is childish.

Quote:
In any case, this is something, that should be left for programmers themselves to decide. It's sort of weird how that kind of stuff ends up in also (for example) GPL ports. Not that there aren't people, who did such OS checking GPL ports in the past.

Just curious, how hard would it be to remove such check from an OS4 exe? Few NOP's or JMP at right place might (or might not) do wonders. As it wouldn't be THAT much of an issue, if author at least had a choice about that...

[ Edited by Jupp3 on 2007/3/26 21:15 ]

@nine

Newlib.library itself is not problem. OS4Emu includes replacement for it. It is just startup code used in every newlib based program. It opens newlib.library, runs con/destructors and calls main().

I looked into BSD source code but newlib.library in OS4Emu is really libnix in disguise.

Quote:

Without PPC assembly skills not possible at all. Real startup code is called indirectly and address is stored in variable so checking just branch instruction is not enough.

Itix do you have any plans to release the next version any time soon? It sound like it would be a nice update. Though I havent seen any new OS4 apps that I would want to run that we dont have a native version of on MorphOS latly.

Heh.. this is pretty comical. BTW. is there any OS4 program which anyone uses somehow regularly with OS4Emu? At least I don't use any... just have tried couple for curiosity. Vice was the only one I've started more than one time, but now there's good MOS port of it too, so it got obsolete :)

Demo's are the main things i've used it for.

Is there more than one demo (Zero by Universe) which work with it? :)

Quote:

True, but it is an anti-competitive measure to prevent software from working on another operating system. Microsoft have been battered around the head for such behaviour.

Quote:

This is what I'm afraid of, and what I hoped Hyperion would rise above.

Quote:

Knowing very little about how the OS4 SDK builds these binaries, how is the code linked into the beginning of the executable? Is an object taken out of a newlib static archive and linked in, or is it part of the crt1.o object?

I am using it quite often for the OS4 port of unrar because all MOS, WarpOS and 68k ports of unrar I tried did suck, causing system freezes or were only able to unpack one archive and then did not work anymore until I rebooted. After rebooting they worked again, but just for one single archive, so I had to reboot again... but the OS4 port works quite perfect.

Some time ago I used to use Mencoder OS4 port with os4emu until Fab released a more recent MOS port.

Quote:
Tried this one?