Jump to content











Photo
* * - - - 1 votes

XPSP1 with full commandline and NTFS below 10 MB


  • Please log in to reply
279 replies to this topic

#101 misty

misty

    Silver Member

  • Developer
  • 933 posts
  •  
    United Kingdom

Posted 27 March 2012 - 09:35 AM

@everyone
I really like the concept of this project - thanks for all of the hard work.

I spent some time with XPCLI a few weeks ago and sadly couldn't get anything working. After noticing a few subtle (note the heavy use of irony) references to XPCLI by Wonko the Sane I've been enticed back here for another try. These subtle references include -

http://reboot.pro/16...221#entry151221
http://reboot.pro/16...160#entry151160
http://reboot.pro/16...075#entry151075
http://reboot.pro/10...5823#entry95823

Anyway, it seems like my previous attempts (and initial (re)attempts) were hindered by using a cr@p disk image when testing in QEMU. That will teach me for applying my lazy philosophy of "here's one I made earlier" :frusty: . I'll investigate the disk image later - it was working when used for other stuff (although I suspect this is due more to my usage with grub4dos mapping and grub4dos's ability to directly chainload ntldr/bootmgr).

Anyway, I've dumped QEMU and booted from a physical hard disk instead. It's working - yippee! I'm getting there, but still have some work to do. I'll play around for a week or so and then report back with my observations/questions.

@wonko
As you appear to have become the bearer of the torch for this project, I was wondering if you could answer a few questions -
  • What progress been made?
  • What are the goals of this project?
  • What needs to be done to move this project forward?
  • What can I do to help (bearing in mind my limited abilities - particular when working with such a small (?limited) base)?

Regards,

Misty

#102 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 27 March 2012 - 07:17 PM

1. Not much progress, though I have a few ideas and some additional notes (never made public).
JFYI, the relevant posts are listed here:
http://reboot.pro/6996/page__st__26

If you have issues creating a valid disk image with MBRbatch,you can use the "simplified" version here:
http://reboot.pro/9033/
Please get the "fixed" version 0.08
http://reboot.pro/9033/page__st__36
(possibly you are suffering from the missing disk signature)

2. "Tentative* goals are stated here:
http://reboot.pro/3717/page__st__31

3. Basically TWO things:
  • finding the way to have most "basic" parts of a Windows XP working (which involves dependecies and Registry settings set-up in "modular" packages or directories - I can expand on this approach I have devised/used)
  • substituting Minlogon with either a "full" Winlogon (not really a good idea as it will add several Mbytes, but possible) find/write a substitute for Minlogon (like re-arranging if possible code from ReactOS) THis is IMHO the "real" roadblock, but it is some time that I try asking the programmers (or self-declared ones) on the board and I cannot find one interested :(
4. Once you have setup a suitable test system (please let us NOT fork, this means Qemu+Qemumanager, a 2Gb and a 100 Mb NTFS formatted image and XP "Gold" (no SP) English installed to the "big" one and used as source of the XPCLI - I can give you details if interested) start adopting an "app" (or a "subsystem") and have it working (on this I can give you some hints and provide the data for the - very few - apps I already have working).

The Rules of the game are simple (actually only two):
  • starting from a "bare minimum" base (that can be in any case "expanded" in case of need, i.e. this "bare minimum" is "negotiable") you add one app (and one only) and all it's depencies in a separate folder, including (if needed) .reg files and regsvr32 commands.
  • Only in EXCEPTIONAL cases you add anything to \System32\ (and you document this addition by adding a \system32\ subfolder to your app folder containng the .dll/whatever that needs to be aded to \System32\

Each single app (it's folder) should be able to be added by itself to the build and work.
This way we create (initially) a large number of duplicates, but we know for sure the exact dependencies of each and every app/tool, and we can later replace these duplicates with "hard links" (to reduce the size).

What do you think of this?

:cheers:
Wonko

#103 misty

misty

    Silver Member

  • Developer
  • 933 posts
  •  
    United Kingdom

Posted 28 March 2012 - 07:13 AM

@Wonko
Thanks for the response. I'll read through the given links (and link to links :P ) later. I'm not actually sure whether I have a Windows XP gold source, which will obviously hinder my efforts.

I particularly liked the rules of the game -

The Rules of the game are simple (actually only two):

  • starting from a "bare minimum" base (that can be in any case "expanded" in case of need, i.e. this "bare minimum" is "negotiable") you add one app (and one only) and all it's depencies in a separate folder, including (if needed) .reg files and regsvr32 commands.
  • Only in EXCEPTIONAL cases you add anything to \System32\ (and you document this addition by adding a \system32\ subfolder to your app folder containng the .dll/whatever that needs to be aded to \System32\

Each single app (it's folder) should be able to be added by itself to the build and work.
This way we create (initially) a large number of duplicates, but we know for sure the exact dependencies of each and every app/tool, and we can later replace these duplicates with "hard links" (to reduce the size).

Thanks again,

Regards,

Misty

#104 Dietmar

Dietmar

    Frequent Member

  • Advanced user
  • 150 posts
  •  
    Afghanistan

Posted 28 March 2012 - 08:19 AM

Hi, I just build up some years ago
XPSP1 with full commandline and NTFS below 10 MB

from comparing Windows embedded with real XPSP1.
Because I know, that there exist a real embedded XPSP1, I think it should be possible. And voila, it works.
My big problem was, that the registry of XPSP1 cant be produced with bits and bytes from zero. So, I used existing XPSP1 registry, with nearly nothing installed and stripped it down.
This project has much more power than recogniced until now. I think, it is possible to integrate Internet Explorer 9 in it,
greetings Dietmar

#105 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 28 March 2012 - 08:52 AM

HI Dietmar, long time, nosee/no hear.
Hope everything is OK. :)

My big problem was, that the registry of XPSP1 cant be produced with bits and bytes from zero. So, I used existing XPSP1 registry, with nearly nothing installed and stripped it down.

BUT things have changed since your original tests:
http://reboot.pro/11212/
http://reboot.pro/11312/

This project has much more power than recogniced until now. I think, it is possible to integrate Internet Explorer 9 in it,
greetings Dietmar

Exactly. :thumbsup:
Problem is finding kids wanting to play this game. :w00t:

@misty
The using of an XP "Gold" is simply because it is the most "clean" source, with the least WinSXS complications (and the binaries are - generally speaking - smaller in size).
We can "raise the base standard" to XP SP2 if you want, I would try avoiding SP3 because it introduces quite a number of changes.


:cheers:
Wonko

#106 TheHive

TheHive

    Platinum Member

  • .script developer
  • 4162 posts

Posted 28 March 2012 - 09:12 AM

Glad to hear from you Dietmar.

#107 misty

misty

    Silver Member

  • Developer
  • 933 posts
  •  
    United Kingdom

Posted 28 March 2012 - 09:45 PM

@misty
The using of an XP "Gold" is simply because it is the most "clean" source, with the least WinSXS complications (and the binaries are - generally speaking - smaller in size).
We can "raise the base standard" to XP SP2 if you want, I would try avoiding SP3 because it introduces quite a number of changes.

@wonko
I'm a bit busy at work for the next few days. I'm hoping to find an XP "Gold" disk in my attic - moved house about 18 months ago and still haven't unpacked. Will get back to you if I need to "raise the base standard". I have access to an XP SP1 (Home - OEM (non-branded)) iso file if this helps.

Regards,

Misty

#108 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 29 March 2012 - 08:37 AM

I have access to an XP SP1 (Home - OEM (non-branded)) iso file if this helps.

That should do as well, the differences between Home and Pro should be in a bunch of files we won't use anyway.

:cheers:
Wonko

#109 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 31 March 2012 - 09:24 AM

I did a few new tests with XP SP2 source and - as expected - there are a few issues, nothing that cannot be eventually solved, but Dependency Walker (which is obviously a "main development tool") has some quirks when used with SP2 sources.

The good news are that I found a couple of issues that had been nagging me, and I have now the "standard" Regedit (and Registrar Lite) working in the build.
Too bad that NTregedit wasn't updated to connect to the offline registry. :(
And Taskmanager finally works.

:cheers:
Wonko

#110 misty

misty

    Silver Member

  • Developer
  • 933 posts
  •  
    United Kingdom

Posted 31 March 2012 - 10:42 AM

The good news are that I found a couple of issues that had been nagging me, and I have now the "standard" Regedit (and Registrar Lite) working in the build....And Taskmanager finally works.

@Wonko
Good news indeed. Well done :good:

I've not had much time to play due to existing commitments, but have managed to find a Gold source in one of the many boxes in my attic - I wasn't even sure if I had one.

I'm way for the weekend and will look forward to getting started next week. It remains to be seen whether I'll be able to make any kind of contribution though.

Regards,

Misty

#111 misty

misty

    Silver Member

  • Developer
  • 933 posts
  •  
    United Kingdom

Posted 03 April 2012 - 10:11 AM

@everyone
It came as no great surprise to myself that I haven't been able to do anything (yet?) with this project due to my lack of skills/knowledge.

I tried adding a43 file manager - Application Error - The application failed to initialize properly (0xc0000142).... I'd added the main dependencies to the folder containing a43. Also tried adding them to the system32 directory but still received the same error.

I also tried adding Drive Snapshot - one of my favourite drive imaging applications. The application failed to start and the command prompt stalled until closed.


@Wonko
It would be interesting to know how you managed to get the standard regedit working. As you previously pointed out elsewhere in this thread - the more that is added the less actually needs adding for additional applications. I like the very modular approach you are advocating with new applications being self contained if possible. It would not however surprise me to find that a43 and snapshot worked with the same changes required to get regedit working.

Just out of natural curiosity I tried building the diskpart build that Dietmar posted (attached to post #17 - here).
  • a43 and snapshot both worked out of the box with this build. I suspect this is due more to the additional registry entries than the drivers he added.
  • The diskpart build seems to contain a lot of unnecessary registry entries and I'm lost at the moment in terms of isolating which entries enabled a43 and snapshot to work.
  • I'm also lost when it comes to adding diskpart to the base build.
Dietmar did a fantastic job with adding diskpart - the diskpart build is only 26.6MB on my system (WIndows folder only - uncompressed). By contrast the base build (post #48 - here) is 25.6MB - although shell32.dll accounts for a large portion of that and seems to be required for bblean and swisnife. Shame Dietmar didn't document the additional steps required to get it working.

Regards,

Misty

#112 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 03 April 2012 - 06:20 PM

Well, yes the "fork" is explained (sort of) here:
http://reboot.pro/3717/page__st__31
Maybe we could further reduce the XPCLIBR to XPCLIRBR (Reduced Base) with ONLY command lne support (and thus removing blackbox, and *any* GUI tool).

I cannot right now swear by it (I may have added some other files in %SystemRoot%\System32\ ), but to have Regedit working I have a folder \XPCLIBR\Apps\Regedit\ with these contents:
  • authz.dll
  • clb.dll
  • REGEDIT.EXE
  • SystemRoot
  • ulib.dll
and, additionally you need in %SystemRoot%\WinSxS\ :
  • x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.0.0_x-ww_1382d70a
For being (no offence intended) a "newbie" to his kind of things, you had an exceptional success :thumbsup: if you managed to have both Snapshot and a43 working :worship:.

For Task Manager I have:
  • iphlpapi.dll
  • msacm32.dll
  • rtutils.dll
  • secur32.dll
  • setupapi.dll
  • shell32.dll
  • shimeng.dll
  • tapi32.dll
  • taskmgr.exe
  • utildll.dll
  • uxtheme.dll
  • vdmdbg.dll
  • winmm.dll
  • winsta.dll
  • ws2help.dll
  • ws2_32.dll
  • wtsapi32.dll

As a general rule, the error:

Application Error - The application failed to initialize properly (0xc0000142)

means (translated from MSish ;)):

This stoopid app tried to access some stoopid settings in the stoopid Registry and it isn't there :w00t:.


When you find this error, the best thing that you can do is to trace the app in a "full" system with Regmon, and get from it the Registry keys that the app uses...
Same goes for finding the WinSxS dependencies, easiest is to treace the app in Depends.exe on a "full" system with the option to show "full paths".
OT :ph34r:, but not much ;), something that could be of use (cannot say exactly HOW, but I feel like it could be):
http://support.micro...kb/102889/en-us
http://www.911cd.net...showtopic=20208

:cheers:
Wonko

#113 misty

misty

    Silver Member

  • Developer
  • 933 posts
  •  
    United Kingdom

Posted 04 April 2012 - 05:26 PM

For being (no offence intended) a "newbie" to his kind of things, you had an exceptional success :thumbsup: if you managed to have both Snapshot and a43 working :worship:.

@Wonko
I've only managed to get them working with Dietmar's Diskpart build (his second set of files - which I believe you referred to as the No Limits build). With it's additional registry entries (and files) the work was really already done for me. The challenge will be getting them to work in the Base build created from Dietmar's first set of files (and your batch files/instructions).

Thanks for the hints on getting regedit working. I added the following files to my regedit directory (SystemRoot subfolder was not required) -
  • authz.dll
  • clb.dll
  • regedit.exe
  • ulib.dll
I also needed to add/create the following -
\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.0.0_x-ww_1382d70a directory, with following file -
  • comctl32.dll
\WINDOWS\WinSxS\Manifests\ directory, with following files -
  • x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.0.0_x-ww_1382d70a.cat
  • x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.0.0_x-ww_1382d70a.Manifest
These three files were copied from a full windows installation. I'm not sure if it's possible to extract them from a source CD. Also these files/paths might be specific to SP0 - if the build has been created from a different service pack source then the paths may be different.

Will check Taskmgr over the next few days and report back.

I have had to install XP gold to my netbook. I tried creating a QEMU installation, however I gave up after three hours of no progress.

I don't think this will cause any problems in terms of trouble shooting as I've not added any drivers and will keep the installation just for tracing dependencies. It's a multiboot system so it's not needed for any other work.

Regards,

Misty

#114 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 04 April 2012 - 07:22 PM

Thanks for the hints on getting regedit working. I added the following files to my regedit directory (SystemRoot subfolder was not required) -

My bad. :(
The SystemRoot folder in my build is a "container" for the files that need to be in "%SystemRoot%" i.e. in this case the WInSXS assemblies (which yes, do include the .cat and .manifest of course, sorry for having been not clear).

These three files were copied from a full windows installation. I'm not sure if it's possible to extract them from a source CD. Also these files/paths might be specific to SP0 - if the build has been created from a different service pack source then the paths may be different.

No, a given WinSXS assembly is exactly the same, no matter the ServicePack installed, the issue may be if you use an app or a .dll from a SP.
The files can be extracted allright, though some post processing is needed.
Check your SP0 source, look in:
I386ASMS6000MSFTWINDOWSCOMMONCONTROLS
You will find in it:
  • COMCTL32.DLL <- this is the actual winSXS dll
  • CONTROLS.CAT <- this is the catalog that will be renamed to x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.0.0_x-ww_1382d70a.cat
  • CONTROLS.MAN <- this is the manifest that will be renamed as x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.0.0_x-ww_1382d70a.Manifest

Most of the mind-boggingly stoopid filename is actually inside the .man:
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

  <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df">

  <file name="comctl32.dll" hash="4f02ff771050b8657e289d75f19163fe2ab02600" hashalg="SHA1">

The underscores are separators:
  • x86=(processorArchitecture="x86"
  • Microsoft.Windows.Common-Controls=(name="Microsoft.Windows.Common-Controls")
  • 6595b64144ccf1df=(publicKeyToken="6595b64144ccf1df")
  • 6.0.0.0=(version="6.0.0.0")
  • x-ww=???
  • 1382d70a=??? =it is some kind of hash or checksum
The last two items must be found, but I hope that someone has documented this I'll have to look at it.

Mind you, one can still use "brute-force" (example):
http://reboot.pro/in...&attach_id=2197


(the example above coming more or less by the same guys
that http://reboot.pro/3717/page__st__53 :whistling: )

I have had to install XP gold to my netbook. I tried creating a QEMU installation, however I gave up after three hours of no progress.

Well, as long as we don't go for "portable" installs it may be OK, otherwise it is essential - as I see it - to use EXACTLY the same machine for development.
Now, be nice, get Qemu Manager 7.0:
http://www.davereyn.co.uk/download.htm
and try again installing XP, on a "normal" machine (on a netbook it may be slower) you are well within the "original" 45 minutes.

:cheers:
Wonko

#115 misty

misty

    Silver Member

  • Developer
  • 933 posts
  •  
    United Kingdom

Posted 05 April 2012 - 10:38 AM

@Wonko
Thanks as ever for the useful information. I sure am learning a lot about dependencies and the registry.

No, a given WinSXS assembly is exactly the same, no matter the ServicePack installed, the issue may be if you use an app or a .dll from a SP.

Yes, this is (kind of) what I meant. I was thinking ahead. Whilst at the moment the agreed source is XP Gold (build 5.1.2600.0) - others may well use a different source which will require different WinSxS directories (and possibly files) if a different version of regedit is used. Just out of curiosity I tried using COMCTL32.DLL file version 5.82.2600.0 (from Gold source - size 544 KB) and file version 6.0.2600.0 (from WinSxS directory on installed XP Gold - size 899 KB). Regedit appeared to work with either version.

...it is essential - as I see it - to use EXACTLY the same machine for development.... Now, be nice, get Qemu Manager 7.0

Done. I used Qemu Manager 7.0 on my desktop. Not ideal as this machine does not promote a decent working environment - it's bloody cold in the study (a grand term for a box sized spare bedroom) and there's no internet connection up there.

Whilst I agree that it is useful to use exactly the same machine for development I don't see that it makes much difference when tracing dependencies. I have the required QEMU install now anyway. Just out of curiosity, do you advocate the use of exactly the same settings on the VM - e.g. no network, no soundcard, same RAM, etc?

...try again installing XP, on a "normal" machine (on a netbook it may be slower)...

You are the master of understatements. 'it may be slower' translated to three plus hours on the netbook (with an estimated (by the installer) 32 minutes remaining) before I threw in the towel and installed to a physical partition on the netbook.

Regards,

Misty

#116 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 05 April 2012 - 11:40 AM

Yes, this is (kind of) what I meant. I was thinking ahead. Whilst at the moment the agreed source is XP Gold (build 5.1.2600.0) - others may well use a different source which will require different WinSxS directories (and possibly files) if a different version of regedit is used. Just out of curiosity I tried using COMCTL32.DLL file version 5.82.2600.0 (from Gold source - size 544 KB) and file version 6.0.2600.0 (from WinSxS directory on installed XP Gold - size 899 KB). Regedit appeared to work with either version.

No.
Meaning that this not the point I was trying to make.

What you reported is a (nice BTW) experiment, but it is a potentially very risky one. :ph34r:
I haven't checked specifically the differences between the 5.82.2600.0 and the 6.0.2600.0 version of COMCTL32.DLL but if the good MS guys linked it to the 6.0.2600.0 it is possible that there is a reason for this :dubbio:.

If you try tracing with depends.exe on a SP2 installed machine, you will see how:
The "Gold" Regedit.exe has a dependency through WinSXS toc:windowswinsxsx86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.2600.2180_x-ww_a84f1ff9COMCTL32.DLL
The "Sp1" and "Sp1a" Regedit.exe has to c:windowswinsxsx86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.2600.2180_x-ww_a84f1ff9COMCTL32.DLL
The "Sp2" Regedit.exe has to c:windowswinsxsx86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.2600.2180_x-ww_a84f1ff9COMCTL32.DLL
The "Sp3" Regedit.exe has to c:windowswinsxsx86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.2600.2180_x-ww_a84f1ff9COMCTL32.DLL

If you check the WinSXS directory on a XP SP2 install, you wiil see how you most probably you have both:
  • x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.0.0_x-ww_1382d70a
  • x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2180_x-ww_a84f1ff9
And if you check the actual SP ASMS, you will find:
"Gold" version="6.0.0.0"
SP1 version="6.0.10.0"
SP1A version="6.0.10.0"
SP2 version="6.0.2600.2180"
SP3 version="6.0.2600.5512"

In simple words, it's a bl**dy mess!

Whilst I agree that it is useful to use exactly the same machine for development I don't see that it makes much difference when tracing dependencies. I have the required QEMU install now anyway. Just out of curiosity, do you advocate the use of exactly the same settings on the VM - e.g. no network, no soundcard, same RAM, etc?

Yes and no.
Until we are within a few "base" requirements ("Standard PC", "PCI bus", "IDE disk", "Ps2 mouse and keyboard", "Standard VGA") there won't be problems that I can foresee, when (and if) we will start to work on either "portability" or "network connections", things will become more complex, I presume, and having a "common hardware" to cross-test info will be desirable.

:cheers:
Wonko

#117 misty

misty

    Silver Member

  • Developer
  • 933 posts
  •  
    United Kingdom

Posted 07 April 2012 - 11:27 AM

@Wonko
Some progress at last! I managed to get format working by adding the following dependencies to either \Windows\System32\ or a subfolder -
  • cfgmgr32.dll
  • format.com
  • ifsutil.dll
  • setupapi.dll
  • ufat.dll
  • ulib.dll
  • untfs.dll
This should be verified by someone else if possible just to rule out my accidently having added other stuff to the registry or %SystemRoot%.

I tried using Regmon to trace registry access, however it nearly drove me mad. I can't believe just how many entries are checked by various programs. It this case it wasn't required anyway!

Regards,

Misty

#118 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 07 April 2012 - 01:06 PM

@Wonko
Some progress at last! I managed to get format working by adding the following dependencies to either \Windows\System32\ or a subfolder -

  • cfgmgr32.dll
  • format.com
  • ifsutil.dll
  • setupapi.dll
  • ufat.dll
  • ulib.dll
  • untfs.dll
This should be verified by someone else if possible just to rule out my accidently having added other stuff to the registry or %SystemRoot%.

Already verified :thumbsup:.
See here:
http://reboot.pro/15252/page__st__16
Of course adding to the above mentioned list one or the other (or both) of:
  • ufat.dll
  • untfs.dll
is needed depending on which filesystem(s) you want to format.

In the usual approach to highlight the interconnectedness of all things :smiling9:, I am mixing together XPCLIBR with PicoXP:
http://reboot.pro/15252/
and Pre-PE:
http://reboot.pro/12339/
and some results are interesting (on my machine the Qemu thingy boots in around 10 seconds with NTLDR instead of the around 15 with SETUPLDR.BIN, 5 seconds are seemingly not that much, but they represent 1/3 of the whole time :w00t:).

With the SYSTEM hive I managed to make (at least on the "standard hardware" mentioned) I can boot the PicoXP on HD (\minint) both with it's own SETUPLDR.BIN approach AND with the "normal" NTLDR approach (the cabbed files need to be de-cabbed to work with NTLDR).

Through this approach I managed to get the list of files needed to have the "original" Winlogon working in XPCLIBR:
  • ADVAPI32.DLL
  • AUTHZ.DLL
  • CRYPT32.DLL
  • GDI32.DLL
  • IMAGEHLP.DLL
  • KERNEL32.DLL
  • MSASN1.DLL
  • MSVCRT.DLL
  • NDDEAPI.DLL
  • NETAPI32.DLL
  • NTDLL.DLL
  • PROFMAP.DLL
  • PSAPI.DLL
  • REGAPI.DLL
  • RPCRT4.DLL
  • SECUR32.DLL
  • SETUPAPI.DLL
  • USER32.DLL
  • USERENV.DLL
  • VERSION.DLL
  • WINLOGON.EXE
  • WINSTA.DLL
  • WINTRUST.DLL
  • WS2_32.DLL
  • WS2HELP.DLL

I have not a "definite" answer about the Registry settings needed, but I am attaching a copy of my current PicoXP registry files, so that you can have a look at them. :)


If we manage to get the right Registry entries, the XPCLI (at the cost of some 3 Mb addition to size) will become buildable without the need for the XPe minlogon :yahoo:, thus possibly :dubbio: increasing the number of interested peeps.



:cheers:
Wonko

Attached Files



#119 misty

misty

    Silver Member

  • Developer
  • 933 posts
  •  
    United Kingdom

Posted 07 April 2012 - 11:01 PM

Already verified :thumbsup:.
See here:
http://reboot.pro/15252/page__st__16
Of course adding to the above mentioned list one or the other (or both) of:

  • ufat.dll
  • untfs.dll
is needed depending on which filesystem(s) you want to format.


@Wonko
Of course, shame I couldn't find this information anywhere. It took a lot of playing around to stumble upon the required files.

Getting format working was essential for me as I haven't got access to the required Swissknife files - CompuApps appear to have removed the necessary files and have replaced them with a paid version. Due to the age of this project a number of links are now dead. This is one of the main reasons I've been playing around with Dietmar's second set of files.

I finally got around to testing Task Manager following your post here. I have only tested it with Dietmar's second set of files (the ones with DiskPart support). I don't know if the additional registry entries Dietmar added to this build are to blame however I needed to add a number of additional files, including -
  • activeds.dll
  • adsldpc.dll
  • crypt32.dll
  • dhcpcsvc.dll
  • mprapi.dll
  • netman.dll
  • rasapi32.dll
  • rasman.dll
  • wmi.dll
  • wzcsvc.dll
Plus the same WinSxS dependencies required for Regedit.

Some more notes that may be of interest. The second set of files appeared to work ok, on the whole, with XP Gold, SP1, SP2 and SP3 sources. Diskpart does not work if either SP2 or SP3 sources are used, however everything else appears fine. The only file that needs to be added if using SP2 or SP3 is msvcp60.dll. I have no idea why DiskPart is now broken.

Regedit, Task Manager, A43 and Format all appeared to work just as well irrespective of the source files.

I have attached a Winbuilder project I put together for the second set of files. Feedback is welcome - just remember it is my first (and quite possibly my last) project. There's a readme file in the download.

Regards,

Misty

p.s. Will check out the registry and information from your last post when I get some time - learning about winbuilder scripting has been draining to say the least.

Edit - Attachment removed. See post #131 (here) for the latest version of the project.

#120 misty

misty

    Silver Member

  • Developer
  • 933 posts
  •  
    United Kingdom

Posted 08 April 2012 - 08:11 AM

@everyone
I've been playing around some more with the second set of files Dietmar posted and have the following programs working (note, any references to WinSxS dependencies refers to the same WinSxS dependencies discussed here, here and here) -
  • a43 (file manager) - dependancies include; shell32.dll, winmm.dll.
  • Agent Ransack - dependancies include; oledlg.dll, shell32.dll.
  • bcdedit - no dependancies identified.
  • beeblebrox - dependancies include; shell32.dll
  • dd for Windows - dependancies include; apphelp.dll, ntvdm.exe, shell32.dll, wow32.dll.
  • DriveImageXML (version 2.13) - dependancies include; apphelp.dll, crypt32.dll, lz32.dll, ntvdm.exe, shell32.dll, urlmon.dll, wininet.dll, winmm.dll, wow32.dll.
  • eraser - dependancies include; WinSxS, crypt32.dll, oledlg.dll, shell32.dll.
  • Everest (Diagnostic) - dependancies include; WinSxS, shell32.dll, winmm.dll.
  • ImageX - no dependancies identified.
  • Notepad - dependancies include; WinSxS, shell32.dll.
  • NT Password Edit - dependancies include; WinSxS, shell32.dll.
  • Opera (v 9.26) - dependancies include; WinSxS, shell32.dll, winmm.dll.
  • PTEdit32 - no dependancies identified;
  • Recuva - dependancies include; WinSxS, crypt32.dll, shell32.dll, wininet.dll.
  • Tinyhexer - dependancies include; shell32.dll.
  • Wincontig - dependancies include; shell32.dll
In my brief tests I noticed that most of the applications that displayed the following error required WinSxS dependencies -

This application failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Once the WinSxS dependencies were added in these cases, the remaining dependencies were identified when running the program and added one by one - e.g. a dialog box displayed an error message listing the missing file, this file was added and the program was restarted and the next missing file was identifed and added until the application started.

The above applications were not fully tested - in some cases they were merely opened. I tested them on a physical drive - not QEMU.

Have fun,

Regards,

Misty

#121 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 08 April 2012 - 09:28 AM

Very good work. :)

About Swissknife (or more generally when looking for "gone" files) always have a try with the Wayback Machine ;):
http://archive.org/index.php
http://web.archive.o.../swissknife.htm
http://web.archive.o...nife-BartPE.exe

:cheers:
Wonko

P.S.: I had a quick look (without actually running it) to your Winbuilder .script, and - though of course it is very simple - I find (again) how you did an exceptional work as your first project/.script :thumbsup: :worship:

BUT (isn't there always a "but" :ph34r:) - with all due respect - it is just *another* Winbuilder .script :(.
It *may* be a good way to re-create from scratch a XPCLI, but it is - IMHO - an already taken path.

At least my idea was different, I was thinking about a "self-creating" kind of thingy, i.e. something that, once created in it's most basic form (through Winbuilder, batch, *whatever* method), could be expandable "from inside".

As an example, take the most basic XPCLI, the one from original post by Dietmar, with added just cdfs, fastfat and mouse.
It can boot, and if you add to it REG.EXE, it can manage it's Registry allright.
Now, in theory (knowing HOW to do it, i.e. which files are needed and which Registry settings) you can add to it virtually *anything*, be it the blackbox shell, DN, a43, etc., etc...

What I find the - no offence intended :) - "wrong" paradigm of Winbuilder (and more generally of *any* builder, including BartPE and wimb's nice thingies, but also MS own "XP Embedded" and "nlite" and more generally *any* "builder" and *any* PE) is the following, you:
EITHER
  • take for good what someone else has decided to include in the build
OR
  • spend lots of time checking checkboxes, adding things, removing others
THEN
  • you press a BIG GREEN (please read as BLUE ;)) button and by sheer magic (and after some short or longish time) the result is ready.
At this point you try the build, and there is always something that you forgot, missed or misconfigured, and you re-build (and again and again :ph34r:)

Compare the above approach to a "normal" NT/2K/XP install:
  • you get the very "basic" tools (or at least what MS consider basic tools, which include some nonsense like Paint - too simple to be of any practical use - and some nonsense like IE - too complex and bloatful to be even taken into consderation seriously)
  • then you add (when you need it) whatever program you find useful/you find handy and little by little you create a system exactly the way you want it.
I.e. you never re-build your thingy from scratch, you just add your personal preferred tools to it, and if you by chance forget one you simply add it.

I envision XPCLI as something as a very, very, very basic "platform" to which a number of simple apps can be added (if and when the user wants to).

BTW, and OT but not much, some good news from Terabyte:
http://reboot.pro/3722/

#122 misty

misty

    Silver Member

  • Developer
  • 933 posts
  •  
    United Kingdom

Posted 08 April 2012 - 09:34 PM

@Wonko
Thanks for the links to swissknife.

P.S.: I had a quick look (without actually running it) to your Winbuilder .script, and - though of course it is very simple - I find (again) how you did an exceptional work as your first project/.script

Thanks.

BUT (isn't there always a "but") - with all due respect - it is just *another* Winbuilder .script. It *may* be a good way to re-create from scratch a XPCLI, but it is - IMHO - an already taken path.

At least my idea was different, I was thinking about a "self-creating" kind of thingy, i.e. something that, once created in it's most basic form (through Winbuilder, batch, *whatever* method), could be expandable "from inside".

I agree with your concept, however I disagree with the suggestion that this project doesn't meet (or can't be adapted to meet) this goal. The project is intended to allow the creation of Dietmar's core files. Additionally it has the added bonus (in my opinion) of allowing us to add other features/applications/programs as their dependencies are (painstakingly) discovered. In no way does it stop us from building the core files - albeit using the second set of files as the core.

Now that I have a bit more experience with the Winbuilder scripting syntax I can easily adapt this project to create Dietmar's first set of files - given the time to do so.

Now, in theory (knowing HOW to do it, i.e. which files are needed and which Registry settings) you can add to it virtually *anything*, be it the blackbox shell, DN, a43, etc., etc...

Again, I wholeheartedly agree with you. The project does just that - at build time. The hard work is actually in discovering the dependencies for each application. Once the dependencies are discovered then an application can easily be scripted to be added at build time (by re-running the project) or can be added to an installed XPCLI - either offline or whilst it is running. It's actually easier to script something to be added at runtime than at build time - using batch files for example. The hard work is in tracing the dependencies.

...you never re-build your thingy from scratch, you just add your personal preferred tools to it, and if you by chance forget one you simply add it.

No problem - once the dependencies are traced. I have no idea if installers will work at this point, however a batch script can easily be created for each program that needs to be added - essentially creating a custom installer.

The beauty of this modular approach you have been promoting is the ability to adapt it to add stuff at build, runtime or offline as preferred.

I would actually prefer to be able to start from a smaller core - using Dietmar first set of files for example. Unfortunately I've not got the skills to trace the dependencies when such a limited core is used. That's the other reason I have been playing with the second set of files - it's far easier to get an application running under the second file set.

It's also far easier to port stuff from the first set of files to the second than to port it from the second to the first. The answer lies in the registry hives - where though?.

Regards,

Misty

#123 misty

misty

    Silver Member

  • Developer
  • 933 posts
  •  
    United Kingdom

Posted 09 April 2012 - 12:57 AM

@Wonko
Having taken on board your comments I have uploaded a new version of the Winbuilder project I mentioned here. Following is from the updated README.HTM included in the new download -

In addition to adding source files to the %TargetDir%\WINDOWS directory, the application scripts included with this project (see Project Scripts section) will also add a set of their source files and dependencies to a subdirectory in the %TargetDir%\INSTALLERS directory. A batch script will also be created that can be used to install the required files in an existing XPCLI - Diskpart Build - these batch files must be executed within the XPCLI - Diskpart Build you want to add/install them to.

The batch installers depend on xcopy.exe. The examples so far are simple scripts that copy the required files to the %systemroot% directory. Support for adding registry entries can be added if required as newer application scripts are developed.

Regards,

Misty

Edit - Attachment removed. See post #131 (here) for the latest version of the project.

#124 TheHive

TheHive

    Platinum Member

  • .script developer
  • 4162 posts

Posted 09 April 2012 - 04:55 AM

test result Windows XP Pro SP0

FileCopy - Failed to copy [%BaseDir%ROOTWINDOWSsystem32wzcsvc.dll] to: [%BaseDir%ROOTINSTALLERSTASKMGRSystemRootsystem32wzcsvc.dll]: The system cannot find the file specified.


Is it suppose to create a bootable iso?

#125 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 09 April 2012 - 07:43 AM

@Misty
Sure :).
The point is only that we can make a "diff" allright between Dietmar's first set and second set.
If you prefer you started from "step 2" whilst I am advocating to start from "step 1", not that big a difference, but I would like to have the "finest granularity" possible.

Just as an example (and please don't take it as a critic :)) even in the small build you already have a "logical fallacy" :w00t: :ph34r:, you get the fastfat.sys in "Core":

Expand,"%SourceDir%\I386\dxgthk.sy_","%TargetDir%\WINDOWS\system32\Drivers"

BUT you add the Registry entry in "Recommended":

RegWrite,HKLM,0x4,_XPCLI_SYSTEM\ControlSet001\Services\Fastfat,Type,2
RegWrite,HKLM,0x4,_XPCLI_SYSTEM\ControlSet001\Services\Fastfat,Start,0
RegWrite,HKLM,0x4,_XPCLI_SYSTEM\ControlSet001\Services\Fastfat,ErrorControl,1
RegWrite,HKLM,0x1,_XPCLI_SYSTEM\ControlSet001\Services\Fastfat,Group,"Boot file system"


In any case, again very good work :thumbsup:

Is it suppose to create a bootable iso?

No, it is supposed to build a small HD image.

In "Task Manager" .script:

Echo,"Extracting wzcsvc.dll from DRIVER.CAB..."
If,Not,ExistFile,"%TargetDir%\WINDOWS\system32\wzcsvc.dll",ShellExecute,Hide,%Tools%\7z.exe,"e %SourceDir%\I386\DRIVER.CAB -y -o%TargetDir%\WINDOWS\system32 wzcsvc.dll"
Echo,"Creating WinSxS directories..."
....
FileCopy,"%TargetDir%\WINDOWS\system32\wzcsvc.dll","%TargetDir%\INSTALLERS\TASKMGR\SystemRoot\system32"


Try NOT checking the Task Manager .script. (at first sight there is a missing space after the -o in the 7z command :unsure:).

@misty
http://ss64.com/nt/extract.html
;)


:cheers:
Wonko




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users