Hi both Eric and Wonko,
Real enthusiasts really help at it's best!
Nope, quite certainly not an AHCI-related error.
I know about related issues, the respective BIOS setting is usually
disabled on my other systems.
While Intel's AHCI specification rev. 1.0 was published in Feb 17, 2005
(according to
http://docplayer.net...i-itj-0901.html ,
Google's patents database
https://patents.goog...atent/US7464228
indicates different dates) and this Thinkpad T43 Model 1871 was
announced a couple of weeks later (it has in fact an Intel 915GM DDR2
RAM hub and uses a SATA-capable Intel 82801FBM ICH6 I/O controller, ref.
http://web.archive.o...pdf/ltwbook.pdf
p138), there's alas no SATA interface in this laptop - if so, I'd have
installed a SSD much earlier!
Never heard of AHCI register protocols running on Parallel ATA (who
knows?). Linux' boot.log doesn't know about AHCI, and I'd have got
into trouble during Warp 4.52 or Windows XP SP2 installation on the
same disk if such had been enabled (existent).
Microsoft's most probably well-known Knowledge Base article 324103
https://support.micr...-inaccessible-b
tells about a "not configured" boot controller or corrupted registry
entries. Yes, the configuration must be screwed up ...
Many thanks for indicating Dave Reynolds' QEMU 0.11.1 build for Windows,
Wonko! (Good news from Britain here;-) QEMU 0.11 was the first version
I played with on Linux, and the only version available for OS/2 (by
T. Ebisawa, "very experimental built"). Dave's Windows port is ingenious
(well, for some reason, "-help" doesn't display it's command syntax), it
even boots my HEXABOOT image with all six (merely historical) operating
systems out of the box:) The image was once in
http://torstenk.bpla...HEXABOOT.tar.xz, readme file in
http://torstenk.bpla...et/HEXABOOT.!!!
Starts with a simple [drive:][path]qemu.exe -hda [drive:][path]HEXABOOT.dd
Runs surprisingly fast, even HEXABOOT's OS/2 client (yes, Wonko, QEMU
is much more flexible than VBox, which requires virtualization support
in hardware for OS/2 - Intel VT/ AMD-V just doesn't exist in older CPUs
like this Pentium M). Only OS/2's multitasking cannot be activated, as
the BOS2SHL text mode task switcher relies on Alt-Esc to switch among
sessions, and there is no way to disable this odd hotkey for Windows
(I always use Alt-Tab here). The image actually uses OS Loader V5.10,
i.e. a good point to start with for XPCLI.
No, it wasn't VirtualBox but QEMU which exhibited problems with drive
geometries (VBox recognized any, when an adequate .vmdk file was
present) - anyway, it work's know!
I know about potential pitfalls with build environments: already in 1995
when compiling WinNT 3.51's sermouse.sys for a different [Trackball-]
orientation, a friend urged me to preserve a backup of this specific
Compiler/ DDK installation if I ever wanted to reproduce the build. -
Interesting fact that OSFMount is actually derived from ImDisk, thank's
for this info! (Means, by the way a compliment for Olof's work!) It's
just, this older Thinkpad is currently the only system in reach (others
stored temporarily), with 746 MB available on %SystemDrive% (QEMU
already stripped down to 12 MB for this), and I cannot afford to screw
up this means to the internet ... By contrast, XPCLI is worth to run
on real hardware, especially here.
Still unclear:
- What is the benefit (additional feature) of WinVBlock compared to
ImDisk or, let's say OSFMount? Is it just that it's drives appear in
Disk Manager, so that (probably) an image's GUID can be aligned with
registry settings, for proper drive letter assignments? Or GRUB4DOS-
related? While my Recovery-Linux on FAT drive C: (12 MB compressed
image, compared to only ten in Dietmar's initial XPCLI) actually
uses it, I prefer using other boot loaders (in this Mini-Linux,
GRUB is chain-loaded by NTLDR).
-
http://minixp.reboot.pro/=
http://mistyprojects.co.uk now?
- What on earth is this DcomLaunch-Service? While Misty lists it as a
requirement for SP2 and SP3 source files, I've no idea out of which
particular files and registry settings it is composed.
After streamlining the image a bit (wanted to keep at least an even
more trimmed-down FREEDOS and OS/2), I copied my current XPCLI tree
to it. Upon booting, still a "STOP: 0x0000007b" error. Sarcastically
spoken, nasty AHCI controllers appear to be everywhere (rather a config
issue, sure). Doesn't make much difference if on real hardware or in
QEMU - I am fed up! If I only had access to my WinXP SP1 CD (Dietmar's
original setup must have worked with this, as the tremendous feedback
proves). Just a matter of registry issue (due to SP2 files), I think -
tuning OS/2's CONFIG.SYS by hand with a text editor is much easier ...
Wonko, is "window in plain PE" to say "graphics mode"? I'd prefer pure
text mode (as on startup), if the console provides at least a 80x50
character matrix (OS/2 uses an 8x8 px font on an obviously built-in
640x480 px text mode, which gives a 80x60 characters screen - while
still far away from Linux' framebuffers, this does it for command line
tools). If I get you right, task switching relies however on a graphical
shell? In OS/2, there is a distinction between the PROTSHELL (protected
mode shell, usually Presentation Manager, but BOS2SHL.EXE for text mode
task switching, as in HEXABOOT) and the OS2_SHELL statement (usually
CMD.EXE, but can be replaced with File Commander, i.e. instead of opening
a command line, this file manager is started directly on new consoles).
The Registry's (usual) Winlogon=Explorer.exe corresponds rather to an
even third OS/2 variable, RUNWORKPLACE (usually the Workplace Shell,
but numerous tinyer replacements were published). Both refer however to
graphical environments, which I'd prefer not to use with XPCLI.
If someone by accident has made a backup of an initial Registry build
from scripts (preferably with SP2 source files), I'd be glad if this
could be published here, as well as the corresponding file list. (The
perspective to install a complete scripting environment on this laptop,
just to obtain a working WinXP "CONFIG.SYS" which I intend to customize
manually anyway is little encouraging. Hopefully not the last resort;-).
Special thanks and regards, :duff:
Torsten