I have seen the GTK preference UI. It is part of why I've pondered doing some UI work in Basilisk.

Any user that feels comfortable taking text output and running it on the command line can probably manage creating their own disk images. The idea with a UI is to do all that for them, which we should be able to do using zip.js or node.js. We could even roll in a basic perl or python interpreter (or LUA), that can use its sys library to generate and place a null file without user interaction.

Or we could just go the UME route, and leave it to platform-dependent front ends, and integrate only the configuration into an SDL interface, with command line flags to set things that way as well from the front end UI.

Blank files are easy: just make a empty file filled with null bytes.

There is no need for zip files as javascript can generate null bytes. (see: in-browser decryption/downloading of files like MEGA)

The zip files would be for if we wanted to provide pre-formatted images instead of prompting the user to format on boot.

Guys, before we discuss the implementation details.

Should we go for
a. HTML
b. maintain GTK
c. do something more fancy as DLudwig255 suggests

Besides the direction, what's more important is to find someone actually who are able to and willing to commit.

Although HTML looks easy, I have zero experience in writing a HTML form that can save a file locally (without server download). It is quite different from write a PHP from server and generate a dynamic HTML to client.

_________________
There is an App for that!
https://github.com/rickyzhang82

I've always avoided GTK when possible, even on GNOME WM. HTML5 has the benefit that it will likely stay the same for years to come and present native widgets on all platforms. node.js makes the job much easier, as it handles all the file management and presents a simple C-like interface.

That said, I'm not going to be able to commit to either developing it nor maintaining it, just providing guidance, so it's probably best to go with whatever solution is preferred by whomever is willing to do that.

Prerelease 6 is now out, with more bug fixes.

Here's what's new:

More bug-fixes!

• fixed issue #5: OSX fullscreen does not recognize mouse-clicks, if cursor is at very top of screen
• fixed issue #19: on OS X, display can slide around if initial clicks are near top of screen
• fixed issue #21: Win32: resizing a window does not stretch screen

Win32 and OS X downloads at https://github.com/davidludwig/macemu/releases

Please report bugs at https://github.com/davidludwig/macemu/issues

Pre-release 7 is now out. To note, I've changed how I name the Git/Github tags for these, and now prefix them with "SDL2-".

Here's what's new:

• MacOSX: enabled VOSF
• performance tweaks (in SDL2 texture and surface management code)
• fixed multiple mouse-grabbing bugs
• added an "sdlrender" preference, which can force the use of a specific, SDL2, rendering backend, such as "software" or "opengl". Setting to nothing, or to "auto", will let SDL2 choose.
• lots of Autotools fixes, including the ability to use either SDL1 or SDL2. SDL2 will be used, if both are available. To force the use of SDL1, pass --with-sdl1 to the configure script.

Win32 and OS X binaries are available at http://github.com/davidludwig/macemu/releases

Awesome, this build looks great. Many thanks for your work.

@DLudwig255, thank you again for this work. I downloaded your code and finally figured out that I needed to include SDL2 in the "External" folder, and was able to build successfully under High Sierra.

One question: as far as I can tell, the --config <filename> option doesn't seem to work, at least not for me. I have a self-contained BasiliskII setup that uses a bash script to launch the executable with a --config parameter. When I copy your unix executable into that setup, it launches, but it opens the disk (and the other configurations) from the hidden prefs file in my user folder, not the prefs file specified in the bash script.

Am I doing something wrong here? Or is there an easy fix in your code?

Thank you again for this terrific work.

Thanks for this build ! I love the way it's possible to have it running fullscreen on a OS X space of is own.
Is network implemented ? Also it doesn't seems to like foreign keyboards (French here), even though my .basilisk_ii_prefs file point to the keycode file.

I need to chime-in as well: Great work, thank you!

Do you intent to also integrate optional TUN/TAP functionality on the network side?
Would be great to be able to connect to external AppleShares and capable printers.

Let me know if you need helping hands on the testing side. J

David Ludwig, thank you for the executable version for OSX 64, High Sierra compatible.
I hope that this project can go on very far.
Bye

I cannot make it boot, not even to the blinking floppy disk screen. It just opens a blank screen, and it closes.
Here are the contents of the log file:

What is the problem? Is it my ROM, or i am not noticing of something obvious? Also, i think that a readme explaining the contents of the prefs file would be nice. I am having a hard time figuring everything out!

_________________
Compact Macs will rule supreme for all eternity!

Does the 'normal' version of Basilisk run OK on your system?

https://www.emaculation.com/doku.php/ba ... _osx_setup

I would suggest as a first step to establish a stable BasiliskII system, based on the instructions provided in the link above.

Along with it, you will find BasiliskII_GUI, a user interface dealing with the preferences file.

If all is up-and-running, replace the version of BasiliskII with the one from David Ludwig.
Hint: You may need to rename the file.

About your ROM-File: It could be a broken one. But if you follow the instructions, there is a good chance to find a good one.

Good Luck and happy hackin'!

I am finding that since the macOS 10.13.3 update, if the "Unix" shared folder is enabled, Basilisk II crashes during boot. If I turn that feature off, everything works. So perhaps you should try disabling the shared folder and see if that solves your issue.

_________________
There's no earthly way of knowing, which direction we are going, for the rowers keep on rowing, and they're certainly not showing any signs that they are slowing.

I've seen a number of similar reports to that -- I wonder if BII doesn't like APFS or is taking some sort of shortcut that APFS doesn't understand?

No problems with BasiliskII and APFS and the Unix folder here...

afpfs-ng-OSX could be used as workaround here. I therefore chose "General Macintosh Emulation" as the category to place a related poll: https://www.emaculation.com/forum/viewtopic.php?f=1&t=9588.

adespoton is talking about APFS, not AFS, for the Unix share.

I know. But if the Unix share doesn't work anymore, one could share a folder from within Basilisk II via AFP and connect to it from the host.

I'm aware the files would reside within the Basilisk II disk image and not on the host side anymore. But it would still ease file exchange.

The nice thing about it, assuming attributes transfer and resource fork handling can be sorted out, is that it's emulator-agnostic. So it'll work everywhere that supports TCP/IP. Unfortunately, this doesn't include Mini vMac which only supports LocalTalk. But hey... maybe Paul could do something to provide AFP support via the app instead of setting up an entire SLiRP stack

Or hope for MaddTheSane to get CAP working at some point in the future. He forked it and it seems he made the libs compile earlier this month: https://github.com/MaddTheSane/CAP/tree/madds.

Nice... if he can get CAP working, that would finally tie my ecosystem together!

I don't think it's APFS, since it was working with me with APFS earlier. It started crashing at about the time I installed the 10.13.3 update, although I don't know whether that's correlation or causation.

_________________
There's no earthly way of knowing, which direction we are going, for the rowers keep on rowing, and they're certainly not showing any signs that they are slowing.