[hatari-devel] Execution history debugger command

Eero Tamminen eerot at users.berlios.de
Thu Jun 2 01:15:20 CEST 2011


Hi,

On torstai 02 kesäkuu 2011, Nicolas Pomarède wrote:
> > As a principle, I don't run/use things at home or work for which I
> > cannot get source code for (like Flashplayer), except in (open source)
> > emulators.

And another thing is that I want some kind of signing for them (like there's
for binary packages coming from distribution repositories)...  Otherwise
in theory somebody could just have replaced them in the intervening years,
if that www-site was cracked in the meanwhile, or some malicious
intermediate http-proxy could be giving wrong binaries.


> > (Wine isn't an emulator.  It provides Win32 API and emulates some
> > things, but the x86 code it runs directly.)
> 
> Well, then as a principle, I'm afraid I can't help you there. I'm not
> asking you to install some commercial program, we're just talking about
> a very good ST emulator that many people still consider superior to
> Hatari because of its nice UI.
> It won't install viruses, just test it for one hour and remove if after
> that if you prefer.

Before running it, does your version have same checksums as the version
I just downloaded:
$ md5sum Steem.exe steemupdate.exe unzipd32.dll 
7d89731bd2bade75cf973ccd308ed50f  Steem.exe
259d0340504a80fdcb2371367c3e704f  steemupdate.exe
aaddb5561976f09c2d002d8ebc78d54d  unzipd32.dll
?


>>> Regarding the UI toolkit, I don't think QT would be such a bad choice ;
>>> at least it's really supported on Windows/Linux/OS X
>>
>> Supported significantly better than Gtk that's used by the current
>> (remote) GUI?
>
> Clearly, yes. Trolltech/Nokia put a lot of work to ensure good 
> experience on all those 3 OSes.

Potentially true.  Has somebody on the list tested this both on OSX &
Windows? :-)


[...]
> Well, I think it's obviously easier to install QT than to install
> QT+python. Less dependencies for the user, he doesn't necessarily needs
> python,

With the all-in-one installer, there aren't any extra deps, everything
needed should be installed in one go, from one place.


[...]
> > If it's built into Hatari, I think it should be done with SDL[1].  This
> > limits the "UI" to the size of the Hatari screen (SDL provides just one
> > "framebuffer" as far as I know) which would complicate things because
> > Hatari window size changes often on Falcon emulation.
> > 
> > [1] While embedding Hatari SDL stuff to OSX UI is already working I
> > think adding Qt to that mix would be a bad idea.

I mean, I have some doubts about it working.  Has somebody successfully
mixed C++ Qt & Objective-C Cocoa widgets in same program and succefully
built & run it?


> Having SDL for the UI has the advantage of always being able to have all
> the settings on screen, even in fullscreen mode.
> 
> But doing a debugger limited to the size of the SDL screen is too
> limited. Today, it's already complicated to add some options to the UI
> by taking care of the SDL window's size. At best we would have the same
> number of characters as in Monst, which is really limited considering
> most monitors go beyond 1280x1024.

While the SDL debugger UI would be bound by the Hatari screen size, it
doesn't mean that the output would have to be scaled like the Atari screen
is.  Adding --desktop option support for ST mode too and running in
fullscreen would guarantee largest possible resolution.

 
> I think we could have the usual SDL UI for running Hatari and for
> example a QT UI with external/resizable/movable windows for the debugger.
> 
> > As a separate program the UI could be any size and the size could be
> > fixed at startup.  Instead of separate windows, it could have e.g.
> > separate screens which are switched using e.g. function keys.
> 
> I prefer having separate windows than many screens, because it implies
> you can have only one screen at a time, which is often a limitation if
> you want to have several hexa/asm dump visible at the same time to
> compare them.

If Hatari would be running at e.g. 1280x1024, you could fit several hex/asm
dumps on same screen...  How many of them you typically and at maximum would
want to compare at the same time ?

(With single window approach it might be possible to offer the same
UI both with SDL & ncurses.  SDL can look nicer whereas ncurses on
console would support copy/paste.)


	 - Eero



More information about the hatari-devel mailing list