Recent posts

#21
Software / Re: Programmatically Controlli...
Last post by marvin - Mar 31, 2026, 12:19 PM
Hi @tygre , NeXTstep apps announce by themselves which types of files they can open.

In this screenshot you see an example for Edit .app, which can open many different file-types.

Screenshot_2026-03-27_10-21-21.png

In my tests with Emacs .app it seems like the app does not link to text-files, which should be the correct type for a file named "Makefile".

As far as I know (NeXTstep 3.3), the file-types have to be added in the app's ProjectBuilder project and are compiled in.

I remember to have "hacked" in a file-type to some application in the 1990s. But do not know any more, if I had simply the sources and ProjectBuilder files, or did it with hex-editor and binaries only.

Is it useful, that you can hold Command-key together with drag&drop the file onto the Emacs app's icon to open it there?
#22
Virtualization / Re: Newbie question: how to ge...
Last post by Rhetorica - Mar 31, 2026, 05:45 AM
Attached.
#23
Virtualization / Re: Newbie question: how to ge...
Last post by andreas_g - Mar 31, 2026, 05:38 AM
Quote from: Rhetorica on Mar 31, 2026, 01:13 AMThe verdict: movement feels extremely slow and sluggish but is at least smooth so long as the linear speed isn't increased past 2 or so. Looking through the values specified in dlgMouse.c, I'm astonished at how slow all the presets are—these are basically unusable in my environment.

This is weird. Can you post your configuration file?
#24
Virtualization / Re: Newbie question: how to ge...
Last post by Rhetorica - Mar 31, 2026, 01:13 AM
Applying that patch to r1789-softfloat definitely seems to give a more solid basis for comparison. The verdict: movement feels extremely slow and sluggish but is at least smooth so long as the linear speed isn't increased past 2 or so. Looking through the values specified in dlgMouse.c, I'm astonished at how slow all the presets are—these are basically unusable in my environment. Unfortunately, usable linear speeds get very hard to control very quickly because of low time resolution and uneven application of the NeXT mouse acceleration; there's zero consideration for smoothing in their algorithm and it shows. I'm definitely putting GKMouseScaler back in; will report on the results next time.

Clockspeed shown on the emulator's status bar still fluctuates wildly when moving the cursor vs. dragging a window, with similar values to what I mentioned previously.

Is there any way the mouse polling rate can be increased? My native builds of Previous seem to be really struggling with this compared to x86 NEXTSTEP under VirtualBox or infinitemac WASM Previous.
#25
Virtualization / Re: Newbie question: how to ge...
Last post by andreas_g - Mar 30, 2026, 06:06 PM
Does the appended patch improve anything?

mouse_patch1.diff
#26
Virtualization / Re: Newbie question: how to ge...
Last post by andreas_g - Mar 30, 2026, 07:30 AM
So it was just a header issue. Your system has nanosleep, but for some reason the header with its definition was not included with MinGW. I will fix that in the repository later today.

What speed setting are you using for Previous? 40 MHz with variable speed mode or something custom?

Did you lock the cursor to the window for testing? This is all very strange. I will simplify the configuration with one single set of values for both locked and unlocked mode. I will post here as soon as it is in the repository.
#27
Virtualization / Re: Newbie question: how to ge...
Last post by Rhetorica - Mar 30, 2026, 06:58 AM
@andreas_g: The patch above worked to produce a functioning SDL2 build, but the resulting binary is getting very bad performance; moving the mouse around causes performance to dip from 40 MHz down to 30±3 MHz. Oddly, dragging a window causes the speed to shoot up to 60 MHz ??? — naïvely, I assume this is because of the absence of nanosleep. The mouse in this SDL2 build moves very slowly no matter how much I thrash the cursor around, and regardless of what I set the locked mouse speeds to.

I removed GKMouseScaler because my configuration with it was meant to eliminate mouse acceleration and I wanted to make sure I was not encountering any artifacts caused by it interacting with any changes you may have made to mouse motion handling. However that VM was still very slow, so I abandoned that install entirely for testing purposes and switched to a version of NS3.3 that had never had anything like it installed.
#28
Off Topic / Sick Windows Tricks
Last post by Rhetorica - Mar 30, 2026, 06:43 AM
Borrowing a subtitle from Nathan Lineback's impeccable "Misc Windows Screenshots" series, this is a thread documenting the ongoing and sometimes disturbing efforts made in recent years to get Windows and Windows NT running on every conceivable piece of hardware:

 - andrew-hoffman/WDMHDA: a new HD audio driver for Windows 98SE and Me
 - Wack0/maciNTosh: bootloader to allow PowerPC Windows NT to run on G3 and G4 Macs
 - Wack0/entii-for-workcubes: because that wasn't dire enough, a port of PowerPC Windows NT to the Nintendo GameCube and Nintendo Wii
 - PluMGMK/vbesvga.drv: modern generic SVGA driver for Windows 3.1

Action Retro and Michael MJD briefly covered maciNTosh here and here, respectively, but by far the most accomplished YouTuber in this freak-show space is O(_)mores, who regularly showcases feats like booting Windows 3.1 off NVMe by using SATA mode, and even got Rhapsody DR2 working on an Intel i7 in late 2024 with an impressive array of working devices by carefully choosing hardware based on what chipsets and drivers could be made to meet in the middle. (@ptek, take notes!)

I am sure this dark saga of absolute necromancy will continue...
#29
Virtualization / Re: Newbie question: how to ge...
Last post by andreas_g - Mar 30, 2026, 06:21 AM
First on the compilation issue:
Does it help to replace this part in sdlhost.c
#if HAVE_NANOSLEEP
#include <errno.h>
#ifdef __MINGW32__
#include <unistd.h>
#else
#include <sys/time.h>
#endif
#endif
#include "host.h"

with this one
#if HAVE_NANOSLEEP
#include <errno.h>
#include <sys/time.h>
#endif
#include "host.h"
?

Why did you have to uninstall GKMouseScaler? Did it stop working properly with the latest changes?

Do you think there should be a setting to make the cursor even slower in the guest system or are the issues caused by other things than excessive speed?
#30
Virtualization / Re: Newbie question: how to ge...
Last post by Rhetorica - Mar 30, 2026, 01:34 AM
@andreas_g The SDL2 build failed for me because of missing support for nanosleep at sdlhost.c:121:23. I haven't tried making an SDL2 build in a while, so it's not too surprising this flew under the radar. I've updated my build scripts to let me select a branch at checkout so this will be easier to keep up to date in the future, should that be desired.

Windows has its own (deranged, overly complex) method of implementing tiny delays using media timers. Here is a polyfill for MSVC. The SDL3 build (branch-filesharing) works as expected... (once I uninstalled GKMouseScaler, anyway.)

As for performance... due to rounding and precision loss, there is some very strange behavior when moving the mouse at slow speeds. Drawing a circle is hardly possible: it clamps to following straight X or Y lines. Speeding up helps somewhat:

spirals.png

(top left: moving mouse slowly, bottom right: moving mouse faster.)

spirals-2.png
left: spiral drawn in Draw.app, Previous filesharing r1789, with slowest possible cursor settings
right: spiral drawn in Microsoft Paint, Windows 10, with same raw mouse input DPI on host

Quality is highly dependent on guest system workload. Mouse behavior on my heavily customized OS4.2 install is a fair bit worse than the same on a virgin NS3.3; in particular, even when drawing tight circles very slowly, the cursor sometimes jumps around 15-20 px diagonally instead of sticking to its vertical and horizontal troughs.

In general I'd say this is an improvement. infinitemac is still a lot better for me in terms of performance than MinGW64+SDL3, probably because it is able to maintain a much higher framerate. I am sure the Mac builds are also a great deal more optimized than the ones produced by my toolchain.