Recent changes to bugs

#97 Sharing files through My Computer breaks things if long filenames used (can't empty trash)

Why_I_Game — Tue, 13 Aug 2024 05:13:21 -0000

I just managed to work around my bug and delete the files!

I had already rebooted multiple times, but for some reason after I shutdown and switched to my previous 7.5.3 system disk, I was then able to empty the 3 broken files from the Trash Can. I have no idea what changed to allow the files to be deleted from the Trash?

The only differences between them:

MacOS 7.5.3 with only HyperCard added -- couldn't delete
MacOS 7.5.3 from a premade hard disk with tons of apps and add-ons -- could delete

However, I think it was just because of rebooting a bunch of times, and not because of switching system disks. So if anyone else is having the same issue, try rebooting Basilisk II a few times, or switch to a different system disk (and back again), and as soon as it boots up attempt to empty the Trash Can.

If a dev could look into the code that handles importing files from My Computer under Windows, that would be great.

#97 Sharing files through My Computer breaks things if long filenames used (can't empty trash)

Why_I_Game — Tue, 13 Aug 2024 04:56:10 -0000

Also, why is this Bug Report showing up as a Feature Request?

The only options to choose when submitting the bug report were "Feature_Request" or "Not_A_Bug".

#97 Sharing files through My Computer breaks things if long filenames used (can't empty trash)

Why_I_Game — Tue, 13 Aug 2024 04:51:23 -0000

The broken filenames are 31 characters long.

I have no idea about Mac internals. Is the max filename length 30 characters? 31 chars? 32? 25?

Sharing files through My Computer breaks things if long filenames used (can't empty trash)

Why_I_Game — Tue, 13 Aug 2024 04:46:11 -0000

When you use the Basilisk II option to share a disk, and try to drag-and-drop a filename that is longer than the MacOS 7.5.3 max filename length, the files become strangely inaccessible.

I had 4 photographs in my shared Z: drive, when I dragged them onto my Mac Desktop the filenames were truncated, but the files could no longer be accessed, renamed, or dragged to the Trash (when trying to drag them from my Desktop into the Trash, it kept saying the files did not exist). I also tried dragging them from the Desktop back into the shared Z: drive, but that also said the files did not exist.

After I rebooted Basilisk II, I was able to drag them into the Trash, but then my Trash can became permanently broken -- the progress bar when emptying freezes part way, it can't access the files to delete them. I also can't drag the files out of the Trash can to put them back on the Desktop. Also, the Disk First Aid app does not find any issues with the disk, so there's no way for me to fix the issue, thus it has permanently corrupted my disk in Mac OS in Basilisk II (unless I stop using the Trash can).

Is there any way to delete these files that the Mac OS 7 thinks does not exist?

It may be an issue that the character limit that is being truncated to during the import, is off-by-one character, then it would end up with a filename that is 1-too-many characters and inaccessible -- but I don't actually know anything about filename limitations on MacOS in-general, or on MacOS 7.5.3 specifically.

This reminds me of my MS-DOS days, where I would use a hex editor to rename a directory name to all lowercase letters (which were impossible filenames for DOS, which can only use uppercase), making the folders inaccessible until I unlocked them again by hex editing the names back to uppercase. It would confuse people that they couldn't go in the folder, saying NOT FOUND.

Attached a screenshot of the 3 broken long filenames in my Trash can, which cannot be deleted, along with the output of the disk check, and the output of "File > Get Info" for one of the broken files.

Support grabbing keyboard in windowed mode (patch)

Solra Bizna — Mon, 16 Apr 2012 05:19:34 -0000

Support already exists for grabbing the mouse in windowed mode by pressing Control-F5. This patch adds support for grabbing the keyboard by pressing Control-F6.
This is useful to me because I have a real Macintosh keyboard and prefer to use the real Command key as the emulated Command key, but I also use the Command key for hotkeys in my window manager. I spent an entire day failing to find a way to tell my window manager to stop intercepting Command key presses meant for Basilisk II, and five minutes making this patch.
Unlike with mouse grabbing, this patch does not provide an indication in the titlebar that the keyboard has been grabbed. I actually do want to leave the mouse ungrabbed when I grab the keyboard, but it may cause problems for most people; for instance, using the mouse to focus another window without ungrabbing first leaves the keyboard in a grabbed state. I can resubmit, if necessary, with any or all of these issues fixed.

Basilisk/SheepShaver doesn't link under clang

Madd the Sane — Tue, 08 Nov 2011 00:20:21 -0000

It seems that the slirp code that Basilisk II/SheepShaver uses isn't properly set up for Clang: in Clang, inline methods must be explicitly stated to be either extern or statics. The functions in slirp.h are only defined inline, causing linking errors. My patch fixes it and makes it link just fine under Clang (with --disable-jit set, unfortunately).

[PATCH] Let Compose key act as Option

Mark Schreiber — Sun, 16 Oct 2011 08:47:26 -0000

Currently, Sheepshaver is rigged up to have Alt act as Command and Meta act as Option. Unfortunately, most current Linux boxes don't have anything bound to Meta. However, some people do have some key bound to Compose/Multi Key, and since that is currently unused, it makes sense to permit it to map to Option; this patch does so.

[PATCH] : Get autoreconf running on Ubuntu 10.10

Mark Schreiber — Tue, 01 Mar 2011 10:21:03 -0000

I've attached three patches to get autoreconf on Basilisk II running without errors or warnings on Ubuntu 10.10.

First, AC_PROG_CC runs too late. If AC_PROG_CC shows up after the arch test in configure.ac, it causes something to go wrong in autoconf (at least on my box). Configure then fails to detect the .o suffix for compiled .c files correctly when AC_PROG_CC actually does run, and causes numerous other later tests involving C compilation to fail, including should-always-work ones for standard C headers.

Second, AM_PATH_GTK is undefined. AM_PATH_GTK was formerly defined in the gtk 1 development package, but Ubuntu 10.10 no longer provides a gtk 1 development header. I was a bit unsure about the right way to go about solving this; I've not much experience with automake. Finally, I decided to, on systems lacking a real AM_PATH_GTK, define AM_PATH_GTK to be a do-nothing macro that always executes as if AM_PATH_GTK had found no GTK 1 packages on the system and warn the user. This means that if a configure file is built on a system lacking the gtk 1 development headers, that configure file, when run on any subsequent system, even one with GTK 1 headers, will not be able to detect the headers. However, it also means that boxes without gtk1 can continue to run autoconf on the Basilisk II configure.ac.

Third, autoconf complains about the fact that AC_CACHE_CHECK is used improperly when testing for -fno-strict-aliasing support. This macro is apparently supposed to execute a particular command and take no actions with side-effects based on it other than setting a single variable. According to the Autoconf manual, this is a common error. This also appears to me to happen in other invocations of AC_CACHE_CHECK in configure.ac, but this is the only one that autoconf seems to complain about.

Mac OS 8.1, THINK Pascal: round() truncates iso rounding

Tue, 01 Dec 2009 14:39:55 -0000

Example: round(4.7) = 4 iso 5.
This can most easily be seen in the Observe window
VERSIONS:
Mac OS X v. 10.6.2
Emulating Mac OS 8.1
Basilisk II v. 1.0 (2009-10-04); BasiliskIIGUI v. 1.0
THINK Pascal v. 4.0.2
Does not depend on BIIGUI "Enable JIT Compiler" status nor on "Compile FPU Instruction" status
Does not depend on which SANE lib is used (SANELib.lib or SANELib881.lib)
Does not depend on Compile Options (Elems881 can be TRUE or FALSE; Code Generation 68881/68882 can be checked or unchecked)
Occurs whether compiled or interactive
Does not depend on whether the BasiliskII.app is launched or BasiliskII is started from the BasiliskIIGUI.app

Crashes when I use Disk Copy

Jesse — Thu, 02 Jul 2009 20:52:52 -0000

The application crashes when I try to mount something with Disk Copy. When It does crash, it gives this output in the terminal:
VOSF acceleration is not profitable on this platform, disabling it
Caught SIGSEGV at address 0x71ac61b6 [IP=0x7808c15d]
D0: 61ac6100 D1: 000000c4 D2: 00000010 D3: 03f66261
D4: 00000aa8 D5: 00000000 D6: 09b4cf14 D7: dddd0000
A0: 00000bb8 A1: 03f68bfe A2: 61ac61aa A3: 03f68d14
A4: 03f68d10 A5: 03f6b5e8 A6: 03f68b88 A7: 03f68b7c
USP=00000000 ISP=03f68b7c MSP=00000000 VBR=00000000
T=00 S=1 M=0 X=1 N=0 Z=1 V=0 C=0 IMASK=0
FP0: 9.22337e+18 FP1: 0 FP2: nan FP3: nan
FP4: nan FP5: nan FP6: nan FP7: nan
N=0 Z=0 I=0 NAN=0
001402fa: 302a 000c b043 6608 1d7c MOVE.W (A2,$000c) == $61ac61b6,D0
next PC: 001402fe