We need an iBrowse replacement for 68k!!!

[chris]

First, make sure you are using the 3.9 NDK as Novacoder suggests. Next, you might try these fixed NDK 3.9 includes:

http://www.heywheel.com/matthey/Amiga/fixed-includes-ndk39.lha

They are from the dead AWeb web site. AWeb uses ClassACT/Reaction also and these were probably fixed by Andy Broad (broadblues).

Unfortunately they appear to be no better than the ones I was using

[chris]

Maybe it's just an OS 3.x bug that's been fixed for OS 4.

Either that or you are meant to use those OS functions differently for OS 3.x

I don't think so - I've used ReAction on OS3 before and it's no different.  This is the first time I've tried from GCC though, however it only seems to be certain things not working.

Debugging GCC 68k code can be painful, I always use old-school log messages (very tedious!)

Me too.  This bit isn't crashing though, it's just displaying a tiny empty window, so it's either the NewObject call erroring or LAYOUT_AddImage not adding the object.  I suspect the former but need some more logging to be sure - and a window created entirely out of macros is always a pain as it is technically all on one line.

[chris]

Making Ibrowse good enough to buy stuff and view homepages more correctly would be enough IMO.

That involves ripping out the entire layout engine and starting again with CSS integration.  If you read Andy Broad's comments on this wrt AWeb, it will involve replacing the engine with something like Webkit, in which case all you've got is another Webkit-based browser, which is not much different from OWB/Odyssey.  Obviously I don't know the internals of iBrowse, but I strongly suspect these comments apply there too - otherwise they'd have done it by now (especially as it is a commercial product so there is an incentive to update it to modern standards).  They *could* rewrite from scratch but that will take time and they will end up with something not too dissimilar to NetSurf.

Either way, open sourcing it isn't going to help anybody.  If back-porting something already existing on Amiga-like platforms isn't happening, then updating an old browser (much more work) isn't going to either.

[chris]

I've spotted a typo (of no real consequence) in images/bitmap.h:
#ifndef REACTRION_REACTION_H

It's definitely my BitMap object which isn't being created, so I'm missing something:
(2.551870) amiga/gui.c ami_gui_splash_open 5189: WindowBase = 0x5be15860
(2.642908) amiga/gui.c ami_gui_splash_open 5190: WindowObject = 0x539a7ba4
(2.712036) amiga/gui.c ami_gui_splash_open 5191: BitMapBase = 0x579b52c0
(2.784028) amiga/gui.c ami_gui_splash_open 5192: BitMapObject = 0x000000

The creation code is this:

Code: [Select]

struct Screen *wbscreen = LockPubScreen("Workbench");
BitMapObject,
BITMAP_SourceFile, "PROGDIR:Resources/splash.png",
BITMAP_Screen, wbscreen,
BITMAP_Precision, PRECISION_IMAGE,
#ifndef __amigaos4__
BITMAP_Width, 400,
BITMAP_Height, 250,
#endif
BitMapEnd,

[chris]

Have you tried converting splash.png to splash.iff? Maybe the OS3 version of bitmap.image can only handle iff.

Yes, no change.  Snoopy isn't even showing that the file is being attempted to be opened - it's like the tag values are completely wrong or something.

[chris]

Code: [Select]


BitMapObject,


This should really be:

Code: [Select]


myImage = BitMapObject,


It is already.  I chopped the interesting (broken) bit out of my window creation macro.

reaction_macros.h defines:

Code: [Select]


#define BitMapObject        NewObject( BITMAP_GetClass(), NULL


This would expand to:

Code: [Select]


myImage = NewObject( BITMAP_GetClass(), NULL,


I've since modified (replaced) these macros to use a class pointer which is fetched once, as this is better from the OS4 side of things.  It hasn't made any difference, so I don't think that's the problem.

Next, your:

Code: [Select]


BitMapEnd,


should probably be:

Code: [Select]


BitMapEnd;


This is purely because I cut that code out of a longer window definition.

I spotted a potential problem in the reaction_macros.h include file.

Code: [Select]


#ifndef End
#define End                 TAG_END)
#endif


This is after the first use of "End". I moved this before the first use of "End" as well as converting some tabs to spaces where it would help consistency and readability. Let me know if this modified reaction_macros.h causes any problems:

http://www.heywheel.com/matthey/Amiga/reaction_macros.h

It's a longshot that this would be the problem but reaction_macros.h should be better this way if I didn't mess something up .

I'll try with that later (and with exactly the same tags as the example, as per Nova's suggestion above).  I'll also dump the tag values as that's my current suspicion, although I don't see how they can be messed up unless they are being treated as char or something.

[chris]

I'll try with that later (and with exactly the same tags as the example, as per Nova's suggestion above).  I'll also dump the tag values as that's my current suspicion, although I don't see how they can be messed up unless they are being treated as char or something.

None of that worked, I'm still getting a NULL pointer returned from NewObject.
I checked the tag value for BITMAP_SourceFile and it is correct (85019001).

I'm out of ideas.

[chris]

This might be stupid suggestion, but maybe there is something wrong in your Reaction installation? Other words, them problem is not in code? Has you tried Aweb or some other proggies wich uses Reaction?

Yes, loads. I'm running the 68k code I'm compiling under OS4, and if I try on an OS3.5 install (which runs AWeb fine) I'm getting exactly the same thing. It's related to the build environment, not the execution environment.

[chris]

Typically I've just built that ClassAct bitmap example myself and the sodding thing works.  Now to figure out what's different between that and the other example code I added a bitmap object to previously.

@Chris
Is it possible to archive your AmigaOS 3 build with needed relative directory structure so I could make a single NetSurf assign and try it?

Just the NetSurf archive?  Sure, easily done.
http://homepage.ntlworld.com/cdyoung/tmp/netsurf_os3.lha

There's no icon unless you install it, but you can run it from the command line.
If you use "netsurf -v" it will chuck out some debug.

[chris]

this archive must be somehow os4 specific.. i couldnt decompress it properly neither under win or amiga..

It was compressed with Linux LhA. You can extract using xadmaster's LhA client, unfortunately the LhA command line tool doesn't support the compression mode used.

[chris]

splash.png displays fine with my datatypes using Multiview. I don't see anything wrong with the path. Chris has it nice and simply set up so everything is PROGDIR: relative.

Edit: There are no MuForce/MuGuardianAngel problems with the splash screen but there are some after which should be fixed. NetSurf runs and exits without crashing when I am using MuForce. The links below are the complete MuForce/MuGuardianAngel output and the Netsuf debug output.

http://www.heywheel.com/matthey/Amiga/NetSurf_MuHits.txt
http://www.heywheel.com/matthey/Amiga/NetSurf_debug.txt

It looks like GCCFindHit should locate most of the problems in the source .

Looks like some NULL pointer accesses and some odd memory alignment problem. (edit: see below)

[chris]

I've just tried building with -O0 in case it was optimisation screwing it up but it seems to have made no difference whatsoever.

Scratch that, it helps if I don't immediately overwrite the flags I've just saved.  I'm amazed nobody suggested this.



Getting somewhere

[chris]

It looks like GCCFindHit should locate most of the problems in the source .

I can't get gccfindhit to work here

(I tried both versions on Aminet and I built my own out of a piece of string and some slightly newer source code I found)

[chris]

I've debugged it and it does look like a compiler problem.

* My particular tag list for NewObjectA() ends up being:
*
* A2-> 0x85019001,0x09f9bebc or BITMAP_SourceFile,""
*      0x09939c2a,0x00000000 or unitialized data on stack,TAG_END
*
* However, all the tags after the first are unitialized data on the stack .

Well, that explains why it doesn't work.  Something must be screwed up with GCC's optimisation in the version I'm using.  I'll have to try to get 4.5.4 working, but since I have a no optimisation workaround, and that's probably better for debugging, it can wait.

I'll see if I can find you the source functions. Symbols loaded for NetSurf with BDebug but line debug for sources didn't seem to work. It's usually the line debug type info that gives the source location but I don't know about STABS.

That would be very useful, I guess it needs a different -g option.

I've managed to get it as far as opening up the main browser window, but it's crashy crashy crashy and never loads the page.  I've uploaded a new build in the same place if you want to try it under real OS3 (still testing under OS4 here as it's easier).  I have noticed that you probably need to create a directory called "Users" in the NetSurf directory, as NetSurf itself never creates it (I was using CreateDirTree under OS4 but simply translated that to CreateDir for OS3 - so it misses this directory.  Something to fix later.)

Some line numbers for Enforcer hits would be incredibly useful now, as I don't have a clue where to start looking to get this working further, beyond fixing the font code which I'm pretty sure is making it assert.

[chris]

GCCFindHit did not work for me either so I assume that it doesn't have the debug info it needs. It should say in the docs for GCCFindHit how it needs to be compiled. I have used GCCFindHit before with success.

GccFindHit understands the stabs from the aout format encapsulated in
the debug hunk of the AmigaOS executable, so it will work as long as
ld outputs its debug information this way.

Utter gibberish.  However I have found another mention that compiling with simply -g is all it needs, so I'll try that.

The first hit (byte read from 0) comes from the locale.library patch of Stricmp() in the utility.library. This is called from the asl.library which is called from NetSurf in ami_file_req_init() of amiga/file.c. The problem occurs in the second AllocAslRequest(). It looks like D0=ASL_FileRequest=0 which is correct and A0 points at the tag list which is:

Code: [Select]


A0-> 0x8008002c,0x00000001 or ASLFR_DoSaveMode,TRUE
        0x8008003c,0x00000001 or ASLFR_RejectIcons,TRUE
        0x80080009,0x00000000 or ASLFR_InitialDrawer,NULL
        0x00000000 or TAG_DONE


The code does move your nsopt_charp to the tag list:

Code: [Select]


   move.l _nsoptions,a0
   move.l ($73c,a0),(-8,a5)


I believe GCC is creating the tags correctly here but a NULL pointer is moved to the data for the ASLFR_InitialDrawer tag item.

Yes, that option will be NULL by default.  This should be easy to fix.

Wtih the second archive, I'm still getting the ami_file_req_init() byte read from address 0 as described above. I then get to the screen mode requestor. I've tried a 32 bit little endian and big endian screen mode which both opened and some of the visuals were displayed before the system froze. MuForce recorded a long read from 0x12 buried (probably several functions) deep in intutition.library. This is going to be tricky to debug.

If you can track it down that will be really helpful.  Make sure it isn't just an assertion though - they usually result in everything freezing.  NetSurf will show "assertion failed" in the debug output if it is.

[chris]

It looks like the freeze is from intuition.library OffMenu()

Ah!  That would make sense as the window doesn't have any menus attached at the moment.

Should be fixed now along with the ASLFR_InitialDrawer hit, thanks.