Should we really crack IBrowse 2.4???

[wawrzon]

voyager has a nice clean, simple and appealing gui, that on the plus side. but its so buggy underneath, i dont even know if it pays to open its sources. i have recently played a little with aweb, both under aros68k and os3.1 as this is the simplest working browser i know working on  both, and must correct my previous opinion about it. it doesnt look very funky, but considering the circumstances it is quite fast, stable and accurate even under plain amiga chipset. if it was possible to plug in css into it i could become much better usable nowadays.

edit: the problem is, its open source but i dont know where to look for them. likely they are kept hostage by big gun who apparently was the last who worked with it, and rescued it from lost repository or something the like.

[desiv]

To execute 68k code you dont need an emulator

Interesting statement there.  I think we're just in semantics now..
So, let's leave out the "custom chips."
Are all of the 68k opcodes supported on the PPC?
If so, then I agree...

If not, what does the OS do when an app issues a command using an opcode for a 68k CPU that isn't supported on the PPC?

If it translates it, even on the fly, then (IMHO) it's emulating the 68k CPU from the programs perspective.

Now, I have to say that I don't think in any way that it's a bad thing.
I love emulation.  I love virtual machines.

It sounds like MorphOS is doing "emulation right" in my opinion.
It's using it only when it needs to.

desiv
p.s.  Java is an interesting case.  Most VMs are (again, IMHO) emulators.  Java is, in a way, an emulator..  But, it's not emulating a pre-existing system.  It's emulating a generic "virtual machine" that was created just for the purpose of Java...  Of course, you could say that, since the platform didn't exist, it's not "emulating" anything..  That's a toughy..

[desiv]

edit: the problem is, its open source but i dont know where to look for them.

http://www.yvonrozijn.nl/aweb/index.html

desiv

[matthey]

@wawrzon
The latest AmigaOS 4 version of AWeb APL 3.5.10 from Andy Broad includes the sources to compile for AmigaOS 3.x. It's available on OS4Depot.

http://os4depot.net/index.php?function=showfile&file=network/browser/aweb.lha

I tried to compile it with GCC 3.4.0 but the complicated make script file had problems. I used to get older versions of AWeb APL to compile most of the way through in AmigaOS 3.x. Let me know if you can figure out how to fix the compile problems. I might have to help out if you get it fixed up to compiling again .

[itix]

voyager has a nice clean, simple and appealing gui, that on the plus side. but its so buggy underneath, i dont even know if it pays to open its sources. i have recently played a little with aweb, both under aros68k and os3.1 as this is the simplest working browser i know working on  both, and must correct my previous opinion about it. it doesnt look very funky, but considering the circumstances it is quite fast, stable and accurate even under plain amiga chipset. if it was possible to plug in css into it i could become much better usable nowadays.

edit: the problem is, its open source but i dont know where to look for them. likely they are kept hostage by big gun who apparently was the last who worked with it, and rescued it from lost repository or something the like.

Paid Voyager releases are actually very stable. It is those free evaluation versions which were from yesteryears having annoying crash bugs. Not very good strategy to get customers, though.

The biggest downside in Voyager is that it is using lot of private MUI calls. Getting it running on AROS (Zune) require lot of in depth knowledge about MUI. On OS3 it of course is not problem.

However, who is going to continue development of those browsers? AROS, MorphOS and OS4 users have got access to better browsers with HTML5, CSS, (limited) flash, Javascript, Unicode support and many more. Old Amiga browsers have their own quite efficient engines tailored for Amiga and I still like IBrowse very much for its efficiency. But unless someone is going to work on it 24/7 their feature set is frozen to year 1999 forever.

[wawrzon]

okay matt, i will see if anything s left stuck from way back. i have devcpp setup here, ll try to revive it and come back to you.

desiv: yesss.. you and the mos boys are stuck in semantics. it doesnt pay to discuss it, whether it is emulation or not. does it?

[wawrzon]

Paid Voyager releases are actually very stable. It is those free evaluation versions which were from yesteryears having annoying crash bugs. Not very good strategy to get customers, though.

ohh. i see. i know only the eval versions. i stand corrected.

The biggest downside in Voyager is that it is using lot of private MUI calls. Getting it running on AROS (Zune) require lot of in depth knowledge about MUI. On OS3 it of course is not problem.

talking about aros, this is actually an advantage if voyager would get open sourced. zune has to be fixed also up to the private mui classes. thats what currently prevents it from running ibrowse. so if a tool using private non documented mui features has been open sources, fixing zune might become much easier i suppose. you are actually meking me hot about voyager.

itix, do you have any link to the developers? olaf schoenweiss has proven to be very effective in gathering contributions for his aros68k distibution, perhaps he can get involved. i think it would be an advantage not only for aros but at least for 68k amiga users to have voyager open as pfs3 was.

[itix]

Interesting statement there.  I think we're just in semantics now..
So, let's leave out the "custom chips."
Are all of the 68k opcodes supported on the PPC?
If so, then I agree...

If not, what does the OS do when an app issues a command using an opcode for a 68k CPU that isn't supported on the PPC?

If it translates it, even on the fly, then (IMHO) it's emulating the 68k CPU from the programs perspective.

It depends on from what perspective you are looking at it. I would call it a virtual 68k processor. 68k emulator or translator in MorphOS is not emulating any specific 68k CPU. It announces itself as 68060 CPU but it supports almost full range of (non-MMU) instructions from 68000 to 68060 including those not available on the real 68060 CPU. FPU instructions can generate slightly different results due to differences in 68k and PPC FPU and it also extends the original instruction set with its own set using trap instructions.

The programs never see the difference so from programs perspective it is emulating 68k CPU. From the operating system point of view there is no 68k CPU. There is only dynamic 68k translator reading a 68k op-code stream.

[desiv]

The programs never see the difference so from programs perspective it is emulating 68k CPU. From the operating system point of view there is no 68k CPU. There is only dynamic 68k translator reading a 68k op-code stream.

Yeah, that's what I was thinking...  

And I think that's incredibly awesome..  ;-)
Very nicely done...

desiv

[itix]

ohh. i see. i know only the eval versions. i stand corrected.

talking about aros, this is actually an advantage if voyager would get open sourced. zune has to be fixed also up to the private mui classes. thats what currently prevents it from running ibrowse. so if a tool using private non documented mui features has been open sources, fixing zune might become much easier i suppose. you are actually meking me hot about voyager.

itix, do you have any link to the developers? olaf schoenweiss has proven to be very effective in gathering contributions for his aros68k distibution, perhaps he can get involved. i think it would be an advantage not only for aros but at least for 68k amiga users to have voyager open as pfs3 was.

Try contacting Zapek (David Gerber). Most likely the answer is no (and most likely there are other factors involved) but you can try. You dont get a 2nd chance -- be careful what you write to him.

[danbeaver]

Wow!

A lot of sharing here.  I don't know whether to cry or rejoice.

Y'all please contact the developers/owners (if you think it will help).

1) If you can sleep at night with a key file that you could not pay for, then use it.  If you use a key file you WOULD not pay for, then you are not a nice person.

2) Opinions (semantics) are like anal orifices, most of us have them (barring anal agenesis and ostomies), and some of us are them.

[chris]

Try contacting Zapek (David Gerber). Most likely the answer is no (and most likely there are other factors involved) but you can try. You dont get a 2nd chance -- be careful what you write to him.

"Be careful" is an understatement - IIRC he is (or was) very anti-OS3.5 and 3.9.  I hate to think his thoughts on OS4!  Things used to get quite, um, heated on the Microdot-II mailing list if you dared mention that something didn't work on OS3.5, with the fault being attributed quickly to the "pseudo-OS" (or whatever he called it) and no chance of it being fixed in MD2 unless you could prove it didn't work on OS3.1 either.

Actually I still use Microdot-II. It has an annoying bug I discovered recently, which I'd like to get fixed.  Maybe if Zapek is amenable to open-sourcing Voyager I'll have a go at getting the source for MD2.

[wawrzon]

very anti-OS3.5 and 3.9. I hate to think his thoughts on OS4!

encouraging to hear. he might actually have had some point..

[kickstart]

ADMINS: I know this post is a provocation, but please read the full post, before deleting it...

Hello Amiga-Community,

now we have the same situation like with MiamiDX. On the one side we have a very, very good product, on the other side the programmers are no more interested in selling it. :-(

Now it is more than 1 year gone and it is still not possible to buy IBrowse 2.4 anywhere!!!!!!!!!!!!

I am writing this post because in my german amiga-forum more than 30 users are willing to buy it, but no reaction from the programmers.

Andreas Magerl (AmigaFuture) and many other people tried to get in touch with the IBrowse programmers, to sell IBrowse 2.4 again with no result :-(

I am really asking me whats going on in the brain from the programmers? There are so many people willing to buy this product without any possibility.

That is the reason why I asked this provocation question about cracking IBrowse 2.4. It seems they are no more interested in a legal product.

Maybe someone from the IBrowse team can comment this? Why are you not answering the emails? Why are you no more interested to sell IBrowse 2.4?

If you have a crack or a keyfile use it, worry about the future of ibrowse at this times seems a bit crazy.

[ChaosLord]

FPU instructions can generate slightly different results due to differences in 68k and PPC FPU

Is the same thing true with WinUAE, UAE, etc?

I am wondering how careful I must be when using floats.

[takemehomegrandma]

Interesting statement there.  I think we're just in semantics now..

Could be. Or perhaps rather different views on definitions of the concepts "emulation" vs "translation"?

Are all of the 68k opcodes supported on the PPC?

:confused:

Of course not. And there is no need for that...

If not, what does the OS do when an app issues a command using an opcode for a 68k CPU that isn't supported on the PPC?

AFAIK no 68k opcodes is ever being executed. If that would have been the case, it would indeed have been through emulation, that would be the only way; by emulating the 68k CPU. Which AFAIK isn't what MorphOS is doing at all.

If it translates it, even on the fly, then (IMHO) it's emulating the 68k CPU from the programs perspective.

Programs (or "opcode streams" if you prefer) are de-facto rewritten, either dynamically while running, or before being started, through JIT. If a 68k Amiga program would ask which "68k CPU" it's running on, I'm sure it would be presented as 68060 (although in practice there is a mixture of numerous instruction sets), just like Itix said.

Two funny things about this though:

• There is no 68k CPU available in a MorphOS system, not even "virtual" (I don't share Itix definition there at all, my view of emulated/"virtual CPU" is in post #230, and had it been a "virtual 68k CPU" in the system in addition to the physical PPC CPU, it would mean that in the manner/context Amiga 68k apps is being executed on MorphOS, we would have a de-facto mutli-CPU system (which isn't really possible in an Amiga context, unless done in a PowerUP or AMP kind of way). And it's not like that on MorphOS, where all resources are shared, the sheduler is the same, etc. But maybe it's a matter of semantics as you said...? )
   
  
• The code actually doing the probing, will (at the moment it is being executed by the PPC CPU) be all PPC code. Which is kind of ironic, isn't it? It's being PPC without being "aware" of it (or indeed needing to care about it). Reconstructed. Native. And *that* is "the programs perspective"!
  

I love emulation.  I love virtual machines.

Well, have fun with UAE then. On MorphOS the Amiga 68k apps are being run natively on the OS (as PPC code), which in turn runs fully native on the hardware. No virtual machine. No "emulation layer". No 68k CPU in the system, neither physical nor virtual.

It sounds like MorphOS is doing "emulation right" in my opinion.
It's using it only when it needs to.

Exactly, it has UAE as an option to emulate a 68k Amiga!

:p