Jump to content











Photo
* * - - - 1 votes

XPSP1 with full commandline and NTFS below 10 MB


  • Please log in to reply
288 replies to this topic

#276 betrand

betrand

    Frequent Member

  • Advanced user
  • 467 posts
  •  
    France

Posted 19 November 2014 - 03:57 PM

Does format.exe work in XPCLI/Minixp?

I tried formatting an Imdisk ramdisk, and got

Format doesn't support fat/fat32/ntfs. (or similar)

Using XPCLI along with Windows XP SP2 dlls referenced in path.

 

I do not remember having this problem in the past.



#277 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 19 November 2014 - 05:42 PM

Does format.exe work in XPCLI/Minixp?

I tried formatting an Imdisk ramdisk, and got

Format doesn't support fat/fat32/ntfs. (or similar)

Using XPCLI along with Windows XP SP2 dlls referenced in path.

 

I do not remember having this problem in the past.

 

i used format.exe with success but i vaguely remember you need to have some extra dll in system32 (ufat.dll, etc).



#278 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 19 November 2014 - 07:44 PM

OWWWW, come on:
http://reboot.pro/to...10-mb/?p=152007
http://reboot.pro/to...e-5#entry152016
http://reboot.pro/to...icoxp/?p=151303

:duff:
Wonko

#279 betrand

betrand

    Frequent Member

  • Advanced user
  • 467 posts
  •  
    France

Posted 19 November 2014 - 08:48 PM

 Thanks both,

that's what I suspected. I was only the dll "it" said was missing.

In the past I probably was using "against" an installed XP (using its dlls).

OWWWW, come on:
 

 Working on other stuff at the moment, didn't take time to look through the topics. ;)

Will add  mentioned dlls.

 

 

:cheers:



#280 Cyrix James

Cyrix James
  • Members
  • 1 posts
  •  
    India

Posted 22 November 2014 - 02:56 AM

Thanks for the superb mini os



#281 TorstenK

TorstenK
  • Members
  • 4 posts
  •  
    Germany

Posted 14 December 2019 - 08:50 PM

Hi Dietmar, Jaclaz, Ilko and all project contributors of the first hour!

I am stunned and amazed that it *is* possible to create a stripped-down
Windows XP for command line boot, I didn't imagine that it's possible!

Twenty years ago, I had played with an early alpha version of PetrOS by
Peter Tattam (to my knowledge, his system based on a microkernel capable
to execute Win32 binaries never really gained maturity).

There are howtos how to create a 32-bit-DOS aka "XDOS" from Windows 98,
which provides Long File-Name access (didn't find an advantage compared
to Henrik Haftmann's DOSLFN driver; in my experiments, neither Win32-
compatibility nor network access were achieved - I had hoped that it's
requester would provide access to LFN files on NETBIOS networks, as
pure DOS requesters only "see" 8+3 files). Digital Research's DR-DOS
multitasker (based on an advanced EMM386.EXE with special switch) is
heavily outdated, it's API is mostly incompatible with programs using
DOS Extenders, crashes are current.

The HX DOS Extender by Japheth is the most promising approach for DOS,
I've compiled a set of Win32 command line tools which run in this
environment, HX even executes my favourite command shell, Brian Havard's
File Commander/ Windows! (Accessing NTFS volumes by means of Paragon's
NDOS driver is however risky.) I stuck with this, and a commandline
OS/2 for maintenance purposes (with a set of tools, it takes 15 MB on
FAT drive C: and provides real multitasking as well an network access).

Dietmar's commandline Windows XP reminds me of this Mini-OS/2, which
however lacks (reliable) access to NTFS volumes or Linux drives (Matt
Wu's Ext2Fsd for WinNT5.x and up works fine!). And, according to
Jaclaz' infos, it is possible to get CHKDSK running in XPCLI, i.e.
would provide an option to fix LFN issues on FAT[|32] drives without
fireing up the full GUI (DOS SCANDISK aborts on such errors). I once
compiled a 40 MB disk image with a set of five DOS flavors, text mode
OS/2 and a set of utilities, for virtual environments like QEMU or
VirtualBox. I named it "HEXABOOT" (if someone want's to look for it) -
and I would probably have included XPCLI if I had known of it before.

Currently, however, my XPCLI installation based on WinXP SP2 files and
the small WINLOGON.EXE replacement from feature pack SP2 (differs in
size from the version in Dietmar's original approach, i.e. 24384 Bytes,
timestamp 2006-10-26 here). As I intend to use it from FAT16 drive C:,
I added FASTFAT.SYS and respective registry entries (as well as the
mouclass/ cdfs/ cdrom stuff), according to Jaclaz' instructions from
January 7, 2008.

I hope my additions to Dietmar's original SYSTEM registry file (size
524288 bytes, timestamp 2008-01-02 22:37) - I just learned to load it
as a structure (into the HKLM tree) with REGEDIT, import customized
.REG files into this \HKLM\Dietmar subtree and finally to remove it
from WinXP GUI's registry so that Dietmar's SYSTEM file was properly
written to disk. (Didn't know before that it's at all possible to
manipulate external binary registry files this way.)

Anyway, my XPCLI won't boot from drive C: (NTLDR already there, for
FreeDOS & other DOSses, Mini-OS/2 and Linux, recently happened to add
WinXP GUI as well;-). About 15 drivers are properly loaded (BOOT.INI
switches "/fastdetect /sos /noguiboot" present), the a BSOD and
immediate reboot. Too fast to determine the last successfully loaded
driver. Worse: BOOT.INI's "/bootlog" switch has no effect, i.e. no
%SystemRoot%\Ntbtlog.txt is written (neither "/safeboot:minimal",
should probably disable "/fastdetect" and add "/crashdebug", hoping
it may slow down these very fast crashes). Adding STORPROP.DLL
(referenced in Dietmar's registry) didn't help, neither.

WinXP SP2 files were reported to work as XPCLI.
Did anyone get it working on real hardware, or did all enthusiasts
use it in virtual environments (from compressed NTFS images) only?
I'd really like to proceed with this - suggestions very welcome!

Best regards, Torsten

#282 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 15 December 2019 - 09:13 AM

Hi Torstenk. :)

 

To some of your questions:

1) no, NTFS compressed drive is not "needed", it was a (nice BTW) "complication" Dietmar added to "squeeze" the size to a minimum.

2) try adding the usual key to (hopefully) avoid the reboot on BSOD: 

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl]
"AutoReboot"=dword:00000000

This said, forget about the (rudimental, half-@§§ed, etc.) building methods talked about here and switch to a more "proper" (though not perfect or foolproof) building methods by Misty:

http://mistyprojects...niXP/index.html

 

As you will see there, a few additional files are needed if SP2 or SP3 are used as "source":

http://mistyprojects...les/project.htm

 

You will need some initial patience while you get familiar with the Winbuilder, but believe me the building procedure is really simplified and gives you a "surely" working base (that you can later modify integrate manually).

 

And - bear with me - these projects (both the one here and Misty's evolution) are on the "highly experimental" side, so you MUST build the project, test it in QEMU and only once it works as you wish in QEMU try using it on "real" hardware.

 

:duff:

Wonko



#283 TorstenK

TorstenK
  • Members
  • 4 posts
  •  
    Germany

Posted 15 December 2019 - 10:16 PM

Many thanks for your hints, Wonko!

At first, apologies for having submitted a message containing several
typos and two omissions (I was too impatient to proof-read, but just
took the draft). A corrected version is attached - if a kind forum
administrator might please replace my original text with this one.
(Cannot do this myself, as corretions are not possible in this forum;
the file is TorstenK_entry213581_20191214.zip\RebootPro_Forum01.msg.)

Yes, turning off the AutoReboot-flag in
HKLM\ControlSet001\Control\CrashControl disables reboot on BSOD.
Anyway (as observed previously within several trials), it only reveals
a "STOP: 0x0000007B" message. As my Thinkpad T43 lacks a reset button,
it has to be switched off which stops it's harddisk, so AutoReboot=1
might be a better choice. The last successfully loaded drivers were
C:\WINDOWS\SYSTEM32\DRIVERS\FASTFAT.SYS
C:\WINDOWS\SYSTEM32\DRIVERS\KSECDD.SYS
C:\WINDOWS\SYSTEM32\DRIVERS\CDFS.SYS
C:\WINDOWS\SYSTEM32\DRIVERS\NTFS.SYS

Thanks for the links! Misty's original message "MiniXP" from April 25,
2012 21:08 http://reboot.pro/topic/16765-minixp/(referenced to in
http://mistyprojects...iXP/index.html)mentions a
project's homepage on http://minixp.reboot.pro/. This domain is still
there, but reports "404 Not Found". Has all content now moved to
http://mistyprojects.co.uk? (If so, a corrected link would be helpful.)

While I was impressed seeing a PE Builder's script (with customizations
by german c't magazine) perfectly creating an image file for a Boot-CD
with WinXP SP1 source files in Dec 2007, I'm not a friend of scripts.
For a minimal system, copying files manually (and to add optional files
later) seems to give better control. I did so with my Mini-OS/2 but, to
be honest, this started as well from some kind of "script", i.e. a list
of required files for different targets (CLI, GUI etc.) within an
executable, BOOTOS2.EXE, written by an IBM employee. It copies a minimal
set of necessary files for the respective targets (including different
OS/2 versions) only, and doesn't require a script environment.

BTW, BOOTOS2 comes with a tiny PROTSHELL replacement (BOS2SHL.EXE) which
acts as a task switcher in both CLI and GUI environments (multitasking
is provided by the kernel, I think), wheras XPCLI seems to require the
GUI when task switching capabilities are desired (?).

For WinXP SP2 support, I added iphlpapi.dll, msvcp60.dll, xpsp2res.dll
and rpcss.dll (hoping this alone fullfills the requirement "DcomLaunch
service"?) with a total size of 3887 KB, as well as (probably
unceccessary) %SystemRoot%\inf\biosinfo.pnf, %SystemRoot%\inf\INFCACHE.1
and %SystemRoot%\system32\CatRoot2\dberr.txt

Results: none, i.e. the system still ends up with a BOSD.
I noticed that Dietmar's original registry contains superflous entries
(Misty mentions this), but with the more streamlined one in Jaclaz'
XPcli_build.zip 189447 bytes 2008-01-20 attached to his message #48
from 2008-01-20 15:46, my current CPCLI doesn't boot, neither.
As a brute force approach, I added all remaining 1070 DLL files (196 MB)
from my WinXP SP2's %SystemRoot%\system32 dir. Results: same as above.
Hmm.

I played with Stefan Weil's QEMU builds for Windows two years ago.
Unfortunately, recent QEMU versions no longer run in WinXP, as support
for it was dropped in the used Cygwin library in 2016 (Stefan had tried
to add two auxiliary DLLs to overcome this, but failed).
There was a serious issue with all QEMU versions which kept my hand-made
"NextStep 3.3 with VESA support" (i.e. with Openstep 4.0 kernel and
drivers, but with NextStep's well-known outfit) image from booting.
(Stefan recommended to notify QEMU' developers, but I never did.)
And, finally, due to it's limited disk geometry detection, QEMU won't
boot the HEXABOOT disk image which has an OS/2-compatible disk layout.
I preferred VirtualBox for further testing these days.

The MiniXP Project Scripts page mentions both Olof Lagerkvist's ImDisk
Virtual Disk Driver 2.0.10 from Nov 25, 2018 and Shan Miller's older
WinVBlock virtual and RAM disk driver from 2009/ 2010.
For both purposes, I'm currently using a commercial, but free solution
from PassMark. OSFMount 1.5.1015 from Feb 7, 2014 still runs in WinXP,
ref. https://www.osforens...t_v1.5.1015.exe
(OSFMount disks don't appear in Disk Manager and cannot be loaded from
GRUB - I merely use it to mount dd dumps, in particular those where Bo
Branten's Filedisk fails, and ISO images - but I'm familiar with it's
straightforward command line interface;-).

Well, I may finally have to become familiar with the scripting stuff.
Actually, there may however just be one nasty little thing keeping my
setup from booting which is, alas so hard to trace down ...

Regards and - as before - suggestions always welcome
Torsten

P.S.: just noticed that I cannot attach files, so my
yesterday's message remains in it's "draft" state.

#284 ericgl

ericgl

    Frequent Member

  • Expert
  • 340 posts
  •  
    Israel

Posted 16 December 2019 - 08:14 AM

TorstenK

If I recall correctly, when you see the STOP 7B BSOD, that usually means that the SATA interface setting in the BIOS is different than what is set in the Windows registry and/or file system.

If you have it set as AHCI, make sure that WinXP is set to AHCI as well. Then is should boot normally.

Hope this helps.



#285 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 16 December 2019 - 09:30 AM

The 0x0000007b plainly means "inaccessible boot device".

And usually this happens on hardware that has SATA (or AHCI) boot disk, but more generally it means that a needed driver to access the boot disk is missing or misconfigured.

So either you set the BIOS to "IDE emulation mode" (or similar) or you need the specific driver properly "installed".

 

About the using of scripts (Winbuilder ot others) the point I was trying to make was that they are a (relatively) easy way to have a "surely working" build that you can use even only as a "reference" or "base" to be manually customized.

 

About Qemu, again bear with me, forget anything else and - specifically for this project - use the (old and discontinued) Qemu Manager that you can still get from here:

https://web.archive....mu_manager.html

https://web.archive....etupqemuk70.exe

at the time, all the tests I made were on this specific platform that BTW is easy to use and - limited to what it can do - exposes a "more compatible" virtual hardware than Virtualbox.

Any geometry detection issue within Virtualbox you may have experienced can usually be if not solved/worked around using grub4dos as bootmgr

 

Finally, it is entirely possible - particularly for someone that is interested in working manually, to "install" a SATA/AHCI driver in an "offline" XP (full) build, so I dont see why it shouldn't be possible also in a limited, small build, see here for a detailed howto:

https://msfn.org/boa...#comment-884409

http://forums.pcper....talling-Windows

 

Now to (some) of your questions/doubts.

1) the XP needs a "shell", which can be cmd.exe alright, and you can start more than one program from the cmd.exe, more or less it behaves like a "windowed cmd prompt", window in a plain PE,  and it is the actual shell in all derivations of this project and in the miniXP, from it launching  minimal shell like Blackbox is optional (but usually convenient).

2) OFSMount is actually originally derived from IMDISK, but here we are getting into a philosophical matter :w00t:, if someone tells you that to make - say - tea, you need hot water and tea leaves, and that you have to heat the water until boiling point and then you put the water into a teapot with the tea leaves, keeping them in for (still say) 2 1/2 minutes before tasting it, you do that.

If you keep the water boiling for half an hour, you use a pan instead of the teapot, use laurel leaves instead of tea, you keep them in the teapot pan for 21 seconds, what you will be drinking will be "a cupful of liquid that was almost, but not quite, entirely unlike tea". ;)

Namely OFSmount might (but not necessarily can) be a 1:1 replacement for IMDISK but SURELY it cannot be a replacement for WinVblock, so be nice, and use Imdisk and Winvblock EXACTLY as per instructions, there will be time later to make changes, replace components, etc..

 

The idea (mine at least) is that first you need to be able to have a working build with EXACTLY the same methoids/components/whatever as per the previous experiences (or in this case the scripts and their requirements) and once (and only once) you have that, you can start adding variations, make tests (crazy or not), etc.

 

:duff:

Wonko 



#286 TorstenK

TorstenK
  • Members
  • 4 posts
  •  
    Germany

Posted 17 December 2019 - 03:04 PM

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

#287 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 18 December 2019 - 09:02 AM

Again some - not all - answers, and the usual grumpy remarks.

 

XP is "natively" or by design a "graphics" OS.

The only parts of it that is "pure text" are the initial part of the setup and the recovery console.

 

Both XPCLI and *any* PE (Preinstallation Environment), like the original MS WinPE and BartPE and most Winbuilder projects to build one, can have a command line window as main "shell" but it remains a window.

 

DcomLaunch is a subsystem that was added in the dependencies in SP2 of quite a few "basic" programs (like diskpart) see (related):

https://msfn.org/boa...art-ris-bartpe/

 

I can guarantee you that my original, half-@§§ed building method here:

http://reboot.pro/to...-10-mb/?p=27822

1) works

2) specifically works with XP SP1 sources
3) specifically works in Qemu Manager

 

USE a self standing image (and NOT your Freedos/OS/2/whatever mixup) for the intitial tests.

 

Otherwise use the miniXp project you have been pointed to, the "building environment" you have to install is all self contained in a single directory it takes NO time to "install" it and NO time to delete it.

 

Winvblock can have the XP boot from an image (as well as Firadisk and - more recently - SVBUS).

 

As you might know (or if you didn't now you do) I am notoriously an old, grumpy bastard :w00t:, but little can irk me as much as people coming here asking for advice/support (because they are failing at the whatever they are trying to do with their methods) and then after having been given proven to be working methods/tools/approach insist on doing something else from what was adviced to them.

 

Here - at least for the "basic" builds it is not a matter of experimenting, it is a matter of replicating what tens or hundreds of other people already managed to do by simply §@ç#ing following EXACTLY the advice, using the provided tools and resources EXACTLY as they are, without introducing changes of ANY kind.

 

Again, once a build works and can be recreated in no time in case of accidental corruption, then - and only then - it will be time for further experiments.

 

Now you have two possible ways to make such a build:

1) my half-@§§ed batch building system <- which sucks, I know because I wrote it, but that works and can produce a working XPCLI

or:

2) misty's minixp project <- which has more features, it is easier, it is more tested with SP1, SP2 and SP3

 

What (the heck) are you waiting for?

Just §@ç#ing build an XPCLI with the one or the other following the instructions!

 

:duff:

Wonko



#288 TorstenK

TorstenK
  • Members
  • 4 posts
  •  
    Germany

Posted 19 December 2019 - 08:57 AM

Hi Wonko,

yes, I had applied the instructions in
http://reboot.pro/to...ge-2#entry27822
(by Jaclaz, on 20 Jan 2008, not by you?!).
Should have stressed more clearly that I've access to WinXP SP2 source
files only (didn't want to start with a greek version ...).

As proper installation of the DcomLaunch-Service revealed no results -
the MiniXP project site's files page
http://mistyprojects...es/filelist.htmcould mention
"* DcomLaunch - Service (rpcss.dll, svchost.exe and respective registry
entries)" as a requirement for SP2 and SP3 source files, which would be
clearer, and, BTW, QEMU 0.11.1's console "screendump " command
creates incomplete screenshots (the bitmap file only shows the first
line of the client window) - I tried the script machinery.

Proceedings less encouraging (WinBuilder's keyboard support incomplete):
"The File '\system32\prodspec.ini is missing" message when %SystemRoot%
is selected as %SourceDir%, an obscure "The archive was created with a
different version of ZLBArchive (v0)", then "The File
'\WINDOWS\System32\dmutil.dll is missing' (file well present in
:\I386\sp2.cab, as well as in %SystemRoot%\system32\dmutil.dll)
and "The archive appears to be corrupted.".

Instead of examining scripts, I discovered freshly generated registry
files and some MiniXP binaries in one of WinBuilder's subdirectories.
After manually copying them into my image, for the very first time, the
system started. (Graphical boot screens everywhere, even in Linux, as
if all OSses wanted to hide what's actually happening during the boot
process.) Worth to note: MiniXP's script extracted the normal hal.dll
from the source CD-ROM, whereas WinXP GUI's installation procedure took
halaacpi.dll on this machine. And it seems, that namely an absent
lsass.exe (not necessarily only this) causes "STOP: 0x0000007b" errors.

After terminating it's GUI init screen, MiniXP opens a full screen
command prompt. Some oddities: it starts in %SystemRoot%\system32, not
in the drive's root dir (from Explorer.exe, I prefer to launch it with
"cmd.exe /k cd \"), and I had to copy kbdgr.dll to kbdus.dll to obtain
a german keyboard layout. Search paths have to be added manually, clear.
Shutdown.exe doesn't execute. The GUI screen says that Windows runs in
"Safe mode", which is probably normal. But File Commander/ Windows
works, really good news!

"Windows NT 'by design' a 'graphic environment'? Unix' X Window System
and OS/2's Presentation Manager are such environments, sure. Both with
underlying command processor interface, however. VMS' not very user-
friendly command prompt on my VAX (at least, "dir" works;-) - where
Helen Custer and David Cutler started Windows NT's development - shows
that at least here an initial text console had been present. Yes, both
setup's initial screens and the recovery console run in pure text mode
(both certainly on top of ntoskrnl.exe, what else?). Microsoft must
have disabled it in subsequent builts, or just nobody hasn't yet
established a path to disable the initial GUI. OS/2' setup routine has
an option to open a command line upon boot (by pressing F3, which
"aborts", but doesn't reboot as Windows NT does).

You suggested to use a "self standing image". I'm using multiple-boot
options for more than 25 years now, with at least some OSses residing
on the same partitions (e.g. OS/2 and Windows NT, both on HPFS, or
several Windows NT 4.0's on NTFS, the second one as a recovery system,
the third with an installed Netware Requester). Why should these -
once started from an virtual image - begin to negatively influence each
other? While the 40 MB HEXABOOT.dd image usually holds six operating
systems (or flavors) at a time, MiniXP's by script-collected files took
so much space - about twice as Dietmar's initial approach did - that I
had in fact to delete anything else, however. Hard to strip down again,
with all those undesired registry entries and dependencies, I'll probably
try to obtain SP1 source files in order to reproduce Dietmar's work.

I always acknowledge other people's performances. Exigences (or just
requirements) may however vary. If someone really wanted to start a
HTTPD (by Japheth) in plain DOS, HEXABOOT is worth testing :-) -
I'm not that familiar with numerous registry entries. Could someone
perhaps tell me how to disable this ridiculous "not enough free space
on Ramdisk" message? And, for the GUI, how to enable the traditional
text logoff screen, which remembers the last-selected option (e.g.
"restart")? The new icon box shuts down when just "Enter" is pressed.

Thanks for all advices to get at last but not least something working!

Regards, Torsten

#289 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 19 December 2019 - 05:12 PM

So you are making progress, good.   :)

 

My half-@§§ed building system was only tested by me on "Gold" and SP1 sources, it is entirely possible that it will fail with SP2, though there are a couple of reports that it does work on SP2 too, so it is porbably an issue with source. 

 

Cannot say the reason why of the errors in the miniXP script, probably a combination of your running XP (German?) and keyboard (also German) and possibly also the actual XP you are extracting the files from (as well German?) AFAIK all tests have always been made with the "plain" English sources (even if my environment is localized - Italian - I also always used English source files), BUT you evidently built from an installed system or from an \I386 directory, and these check for prodspec.ini:

http://mistyprojects...ions.htm#source

 

Try re-running the script from an "untouched" CD/DVD/ISO. :unsure: I can confirm that -at least on English sources - a PRODSPEC.INI is present in \I386, maybe the German has different contents that are mis-parsed by the script.

 

Or try editing the Winbuilder script to by-pass the check, by commenting:

http://www.paraglide.../wbscripts.html

the relevant "Halt" lines, they are in core.script (in \Projects\MiniXP_scripts\Core\ ), in sections:

[CD_SOURCE_CHECK]

[LOCAL_SOURCE_CHECK]

[I386_SOURCE_CHECK] 

 

BTW the sp2_and_sp3.script contains the settings for DCOMLaunch Service.

 

The need to add a German (or more generally a "local")  keyboard driver is/was expected. 

The "Safe mode" is NOT "normal", your build is still somehow "defective". :(

 

I lost you on EXACTLY what you tried from EXACTLY which sources and whether you tested the whole stuff in Qemu Manager which is where I did my tests at the time (NOT the underlying Qemu 0.11 build, the actual Qemu Manager GUI tool, if it makes any difference :unsure: ).

 

BTW, as a side note, for some reasons the Author discontinued Qemu Manager and archive.org has not any saved file related to updates, but I do have a Qemu 0.13 (compiled for Qemu Manager) see here:

http://reboot.pro/to...pdates-in-qemu/

I just reuploaded a fresh copy of that and added the link to post #6, just in case:

http://reboot.pro/to...-qemu/?p=200174

 

 

 

The shutdown issue is re-known, see here:

http://reboot.pro/to...ge-3#entry31659

at the time I tried like tens of similar "shutdown"  command line tools, and all of them but the one in bblean had either issues or required so many dependencies/other subsystem that it wasn't worth it. (but that was of course within Qemu Manager and with the "non-ACPI" HAL).

 

There MUST be *somewhere* a valid shutdown tool, but I stopped my researches/experiments once I found that the BBLean was a convenient shell/environment.

 

:duff:

Wonko






2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users