Jump to content











Photo
- - - - -

Experimental NTBOOTDD.SYS


  • Please log in to reply
45 replies to this topic

#1 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1,676 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 07 March 2011 - 11:05 PM

Here's an outdated screen-shot:
Attached File  ntbootdd.GIF   17.52KB   278 downloads

Hello, everyone!

I need your help, if you please. In order for this program to work with a variety of NTLdrs, it'd be great to continue to expand the list of supported NTLdrs, below. If you are interested in using this WvBootDD.Sys as an NTBootDD.Sys with your version of NTLdr, you can:
  • Download the WvBootDD.zip package: Attached File  WVBootDD.zip   22KB   18 downloads (version 0.0.1.9)
  • Use the contained WNTLdr.exe tool on your NTLdr
    
    wntldr.exe ntldr
    
    
  • If WNTLdr.exe says "Nothing found," then thanks for trying
  • Otherwise, take a look at the list below. If your results are not already in the list, then please post your results!
Here is the current list:

# S OS SP# Lang Found? String_________________________: Size_: MD5____________________________: File Version:

1 Y XP SP2 Eng- Found: 7B6D8AB599A57B4784A34D873C4A87D0 276144 44DE4B2FC1BF3F63F847FC6DFAAFF68A 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)

2 Y 03 SP1 Eng- Found: B840C1B30F4A6841A5B71FFE37C7F0E4 295536 EAAD72A0CBD33F63D4CDA5E933A5D6D8 5.2.3790.1830 (srv03_sp1_rtm.050324-1447)

3 Y XP SP2 Eng- Found: 70DDF0681786294FB31E7B4B32BDAFDE 250032 9EC920F4179D45AF3A6638A083D39C85 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)

4 Y XP ??? Eng- Found: 4AFA75F6972FAD4C9350A7AC33EE33F4 250048 C1B29B4E6EEA9510610DB2EC4D6DB160 5.1.2600.5512 (xpsp.080413-2111)

5 Y XP SP2 IT-- Found: 35857FDC63EBE74599311BAEB7F2D624 251072 E4564680AC4BC564F14793EA085C3523 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)

6 N XP ??? Eng- Found: 8BD7A02F7C98054C8F260BF64BB85638 233120 f56cdf28414a5d85197eee3c81b7ff59 5.1.2600.1123 2002-10-15

7 N XP ??? Eng- Found: 254F58C12453B444B13F526A106A38FE 233120 0bdf2f2e41c765735f6eca7d365b906c 5.1.2600.1319 2003-11-10

8 Y 03 SP2 Eng- Found: E5D4326ABA56F646B744C7EEAB765DE6 ?_____ ?_______________________________ 5.2.3790.3959 (srv03_sp2_rtm.070216-1710)

The S column indicates whether or not the NTLdr is supported.

This experimental NTBootDD.SYS is hard-coded to use a flat hard disk drive image called WIN.HDD in the same filesystem as NTLdr. The file does not need to be contiguous. The "hosting" filesystem can be FATXX, NTFS, ISO9660, or TFTP. A minimal hosting filesystem might contain:

NTLDR

BOOT.INI

NTDETECT.COM

WIN.HDD


This "driver" will [attempt to] present a virtual SCSI disk for booting from. Your BOOT.INI might look something like this:

[boot loader]

timeout=30

default=scsi(0)disk(0)rdisk(0)partition(1)WINDOWS



[operating systems]

scsi(0)disk(0)rdisk(0)partition(1)WINDOWS="Microsoft Windows XP Professional SCSI" /noexecute=optin /fastdetect /sos


This is just for the curious and doesn't have too much practical use just yet.

--- EDIT: November 16th, 2012 ----

Version 0.0.1.9 includes an initial cat command for displaying files on the system volume. Previous version downloaded 7 times. Thanks to Icecube for automating NTLdr discovery! And to Wonko the Sane for reporting an NTLdr version! :thumbsup:

--- EDIT: November 11th, 2012 ----

Second version downloaded 57 times. The new version still doesn't do too much. :) This version includes an .AVI video sample, a sample BOOT.INI, as well as the WNTLdr.exe tool for reporting NTLdr versions.

--- EDIT: 2011 ---

First version downloaded 95 times. Newer version addresses performance but doesn't pass any information to WinVBlock, so use is still limited. This version must be used with the NTLDR from an English Windows XP SP2 with MD5 hash: 9EC920F4179D45AF3A6638A083D39C85.

--- Outdated Notes ---
The NTBOOTDD.SYS file must be patched for every different version of NTLDR. The patch area for this version ranges from 0x12AC through 0x12CC. That is 8 x 4-byte addresses. You must patch the patch area with the following NTLDR functions' and objects' addresses, in this order:

BlPrint()

BlOpen()

BlRead()

AEOpen()

BlClose()

BlSeek()

AEBiosDisabled

BlFileTable

You can find these addresses for your version of NTLDR by using this procedure, or we can work together towards figuring out the details of your NTLDR. Otherwise, the attachment here is patched for a Windows XP Professional with Service Pack 2, English edition.

#2 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 07 March 2011 - 11:37 PM

A small (for the moment) step .... one giant leap for booting (tomorrow) :hi: ;)

:thumbup:
Wonko

#3 Nuno Brito

Nuno Brito

    Platinum Member

  • Team Reboot
  • 10,207 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 08 March 2011 - 08:31 AM

Very nice work.

I've edited your initial topic to present the screen shot as intended. After attaching a file to your post, there exists an option to insert the attachment at a position that you define.

I can help automating the recognition of the NTLDR and expected addresses at NTBOOTDD.SYS, at the end of the month I should have conditions to present a project intended to index the different versions of MS files and the sort.

#4 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7,771 posts

Posted 08 March 2011 - 10:23 AM

I think, i'm a little stupid at the moment. What is this driver good for? Now or in the future.

:hi:

#5 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 08 March 2011 - 11:14 AM

I think, i'm a little stupid at the moment. What is this driver good for? Now or in the future.

Me thinks that "in the immediate future", at least for the moment, I miss part of the "basics" needed to attempt using it.

Traditionally on NT systems the SCSI driver for an actual SCSI card was copied "verbatim" in the Root directory of the boot drive (together with NTLDR, NTDETECT.COM and BOOT.INI) and renamed to "NTBOOTDD.SYS".
If the BOOT.INI has INSTEAD of the nowadays common "multi(0)" entries a "scsi(0)" entry, it will use the NTBOOTDD.SYS to "hook" the SCSI drive(s) at boot time.

What I am currently missing is whether this driver needs to be also (as it was the case for the actual old SCSI drivers) installed to the system to be booted (via F6 or the like). :hi:

It's a few years that I try "pushing" the idea that NT/2K/XP/2003 based systems have this "inbuilt" provision to load drivers at boot up, with very little success in the community of actual driver programmers. :(

There was an attempt for a ramdisk driver loaded this way by Dietmar (that NEVER released it if not in a perfectly unuseful 32 Mb max size version) and one for USB drivers loaded this way by FreddyV (abandoned):
http://www.911cd.net...showtopic=20450
http://reboot.pro/3593/

The other idea it's years I try to promote is direct hard disk image drivers (to avoid excessive RAM usage).

This latter approach is now reality thank to Karyonix (firadisk) and Sha0 (winVblock) :worship: , this NTBOOTDD.SYS is another NICE step. ;)

But at least myself need some more details on it's usage, which I am confident Sha0 will soon post. :thumbup:

:cheers:
Wonko

#6 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1,676 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 08 March 2011 - 12:51 PM

...there exists an option to insert the attachment at a position that you define...

Thanks a lot, Nuno! I will look for this option next time.

I can help automating the recognition of the NTLDR and expected addresses at NTBOOTDD.SYS, at the end of the month I should have conditions to present a project intended to index the different versions of MS files and the sort.

That is most excellent! Since potentially every 2000/XP/2003 NTLDR language/service pack/update version could have different addresses, this automation could certainly help to auto-patch this NTBOOTDD.SYS appropriately.

But at least myself need some more details on it's usage, which I am confident Sha0 will soon post. :hi:

Indeed.

So there are potentially multiple uses:

In the problem that Vortex reported whereby Windows Server 2003 was working with neither Firadisk nor WinVBlock, it turned out that GRUB4DOS doesn't protect its INTerrupt 0x13 hook, so it gets obliterated at random by Windows processes during boot, depending on whether its memory happens to be overwritten or not. Without the INT 0x13 hook, the two aforementioned drivers cannot find the GRUB4DOS virtual disks without some new mechanism. Every time a new mechanism is introduced, things will get uglier, in my opinion. Some future version of this NTBOOTDD.SYS could find MEMDISK and GRUB4DOS parameters very early and then pass them on.

Additionally, NTBOOTDD.SYS has access to disks using INT 0x13, so it can scan disks and pass on information concerning which BIOS drive numbers (pre-kernel) correspond to which Windows disks (post-kernel). We want to know this so that we know which backing disks that G4D sector-mapped disks map to.

Another goal for a future version of this NTBOOTDD.SYS would be Microsoft .VHD support for all three VHD types: Fixed, dynamically expanding, differencing. There are still tons of XP computers out there in the world, and it might be nice to boot them from VHDs.
  • Base image VHD
  • Model-specific VHD difference from 1 (drivers, devices, kernel and HAL choice)
  • Computer-specific VHD difference from 2 (this computer's MAC addresses, computer name, Active Directory account, AD Group Policies)
  • Session-specific VHD difference from 3 (re-generated at every boot, thus discarding viruses, user profiles, cached AD credentials)


#7 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 08 March 2011 - 01:00 PM

Another goal for a future version of this NTBOOTDD.SYS would be Microsoft .VHD support for all three VHD types: Fixed, dynamically expanding, differencing. There are still tons of XP computers out there in the world, and it might be nice to boot them from VHDs.

  • Base image VHD
  • Model-specific VHD difference from 1 (drivers, devices, kernel and HAL choice)
  • Computer-specific VHD difference from 2 (this computer's MAC addresses, computer name, Active Directory account, AD Group Policies)
  • Session-specific VHD difference from 3 (re-generated at every boot, thus discarding viruses, user profiles, cached AD credentials)

I really really like the sound of it.... :hi:
I can't wait to see it all happen !! But no pressure, eh !!

#8 davlak

davlak

    Frequent Member

  • Advanced user
  • 224 posts
  •  
    Italy

Posted 08 March 2011 - 02:56 PM

don't know if interesting, when I was testing vboot 1.0 I noticed that the 2003.vhd where installed server 2003 on, had the NTBOOTDD.SYS in the root.
it worked really fine.

#9 maanu

maanu

    Gold Member

  • Advanced user
  • 1,125 posts
  •  
    Pakistan

Posted 08 March 2011 - 05:16 PM

is it younger brother of winvblock or a previously UNKNOWN elder brother ? just wondering...

in simpler words, how it can be used as companion of winvblock ?


congrats Shao, as being said by wonko, it is small step towards big achievement .

#10 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1,676 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 08 March 2011 - 05:44 PM

is it younger brother of winvblock or a previously UNKNOWN elder brother ? just wondering...

It is a "younger brother".

in simpler words, how it can be used as companion of winvblock ?

It'll most likely pass useful information to WinVBlock and Firadisk, but won't be used post-kernel. This is because an NTBOOTDD.SYS driver can only use the functions exported by SCSIPORT.SYS. Such a driver is a "SCSI Miniport Driver". WinVBlock is a "fuller" driver which uses HAL and NT kernel exports and implements its own SCSI request processing.

#11 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 08 March 2011 - 06:03 PM

It is a "younger brother".

It'll most likely pass useful information to WinVBlock and Firadisk, but won't be used post-kernel. This is because an NTBOOTDD.SYS driver can only use the functions exported by SCSIPORT.SYS. Such a driver is a "SCSI Miniport Driver". WinVBlock is a "fuller" driver which uses HAL and NT kernel exports and implements its own SCSI request processing.

Good. :)
Now can you post a few lines to make an example of it's usage, possibly additional to what already posted and answering this question?:

What I am currently missing is whether this driver needs to be also (as it was the case for the actual old SCSI drivers) installed to the system to be booted (via F6 or the like). :cheers:

and the following ones:
  • HOW is the XP in the HD image to be installed?
  • ANY particular requisite?
  • ANY particular Registry key or additional driver?
  • Or - at the moment - once the loading has started it will turn into "a suffusion of yellow" because another "hooking mechanism" or "subsequent needed element" is still missing/needs to be developed?
You know, like:

This is just for the curious and doesn't have too much practical use just yet.


:cheers:
Wonko

#12 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1,676 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 08 March 2011 - 07:07 PM

Good. :)
Now can you post a few lines to make an example of it's usage, possibly additional to what already posted

Nope. Because it currently can only provide the pre-kernel disk, but doesn't yet pass anything to WinVBlock or Firadisk.

and answering this question?:

What I am currently missing is whether this driver needs to be also (as it was the case for the actual old SCSI drivers) installed to the system to be booted (via F6 or the like). :cheers:

Since this driver should not be used post-kernel, the only "installation" required will be copying the file to the hosting filesystem and modifying BOOT.INI in that filesystem. But that won't help anything without a post-kernel driver, which itself will likely require installation of some sort, either via F6 or from a booted OS.

and the following ones:

1. HOW is the XP in the HD image to be installed?

A flat disk image with an OS installed to it can be produced by capturing a disk image with DD. To install directly to a disk image, we obviously do not require any files from the [empty] disk image, so we do not require pre-kernel support.

2. ANY particular requisite?

Just patching the patch area for a particular NTLDR. Or maybe you are asking about "installing the XP in the HD image." Another way to install XP to an HDD image is to use a VM product such as QEmu. Personally, I'd use DD.

3. ANY particular Registry key or additional driver?

One would likely want one of: WinVBlock, Firadisk.

4. Or - at the moment - once the loading has started it will turn into "a suffusion of yellow" because another "hooking mechanism" or "subsequent needed element" is still missing/needs to be developed?

Correct. Unless you are trying to boot a Windows which doesn't require a boot disk, such as if the NCLI was turned into a driver, or if you were doing a trick where Windows would continue its boot, post-kernel, from some other source disk. I've done this before: Boot from a SAN but then have no SAN driver in the OS image, so Windows finds and continues its boot from a USB disk attached to the computer, where the USB disk is identical to the SAN image... Faster than booting from USB.

#13 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 08 March 2011 - 07:33 PM

Good. :)
Now it is clear, I had understood rightly: at the moment we have only one of the pieces of the (two pieces) puzzle.
But still an exceptionally GOOD piece! :)

... or if you were doing a trick where Windows would continue its boot, post-kernel, from some other source disk. I've done this before: Boot from a SAN but then have no SAN driver in the OS image, so Windows finds and continues its boot from a USB disk attached to the computer, where the USB disk is identical to the SAN image... Faster than booting from USB.

Yep :ermm:, that would be a "dumbed down" XP Kansas City Shuffle, with the kicker image as big as the target....:cheers:

What I was wondering is:
  • HOW did the "good ol" SCSI drivers be "at the same time" "themselves" AND NTBOOTDD.SYS (once renamed)?
  • HOW did they hook or are hooked (or whatever) without modifying NTLDR?

Maybe in due time this NTBOOTDD.SYS can be "merged" with either WinVblock or firadisk, and have the latter drivers be able to behave as the "old" SCSI ones did. :unsure:

I presume that #2 is something "provided" by the BIOS extension of the card, so maybe it is possible to replicate this behaviour with some trick/additional feature of grub4dos? :cheers:
Or develop an alternative (more open minded) NTLDR? :ph34r:


:cheers:
Wonko

#14 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1,676 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 08 March 2011 - 09:30 PM

Yep :cheers:, that would be a "dumbed down" XP Kansas City Shuffle, with the kicker image as big as the target....:)

Well, not exactly. If the size of the "Kansas" disk image (the SAN, in my example) is reported to be the same size as the actual target and the MBRs match, that should be sufficient. The "Kansas" disk image need not actually be as large as the target; VHDs would be good at this kind of spoofing. :ph34r:

What I was wondering is:

  • HOW did the "good ol" SCSI drivers be "at the same time" "themselves" AND NTBOOTDD.SYS (once renamed)?
  • HOW did they hook or are hooked (or whatever) without modifying NTLDR?

Here are the functions that SCSI Miniport Drivers are supposed to be confined to.
  • Since the SCSI Port Library functions allow a driver to speak to hardware, that's sufficient for driving the hardware. A virtual disk driver for file-backed disks needs to speak to software, such as files on filesystems on partitions on disks. The SCSI Port Library doesn't export functions for speaking to the other software components in the OS which provide these things. There is no "open file" function, for example. So FOO.SYS can be installed by an F6 floppy originally, suggest that a scsi(x)... BOOT.INI ARC path is required and that it needs to be copied as an NTBOOTDD.SYS. It is then loaded once by NTLDR and then again once NTLDR finds it as a boot-start driver in the loaded SYSTEM hive. Does that make sense?
  • They don't need to do anything fancy like this experimental NTBOOTDD.SYS is doing. This driver needs the patch area because it uses functions which are not exported by NTLDR's pseudo-SCSIPORT.SYS, but which we happen to know that NTLDR has.

Maybe in due time this NTBOOTDD.SYS can be "merged" with either WinVblock or firadisk, and have the latter drivers be able to behave as the "old" SCSI ones did. :)

Unfortunately, nope. If you use Dependency Walker (Depends.exe) on a SCSI Miniport driver, you'll note only a dependency on SCSIPORT.SYS. If you run it on one of our fine drivers, you'll see dependencies on the HAL and kernel, instead. That's because we need file functions and memory functions and IRP handling and threads, etc. I'm afraid that this driver is confined to "helper" status.

I presume that #2 is something "provided" by the BIOS extension of the card, so maybe it is possible to replicate this behaviour with some trick/additional feature of grub4dos? :cheers:

An NTBOOTDD.SYS is supposed to use the SCSI Port Library functions to speak to hardware. But files aren't hardware. Obviously Gary Nebbett has already shown that a RAM disk [-only] SCSI Miniport driver is possible, but file-backed disks require talking to filesystems rather than hardware.

Or develop an alternative (more open minded) NTLDR? :ermm:

I'm not sure what you're suggesting, here. I was looking at the possibility of re-linking pieces of NTLDR (OSLOADER.EXE) so that it exports more than just the SCSIPORT.SYS functions, but one could never distribute such a thing.

#15 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1,568 posts
  •  
    American Samoa

Posted 08 March 2011 - 10:51 PM

Very interesting development. It'll might be easier to use jointly with WinVBlock for installing some less friendly OSes from image, as it matures. :cheers:

#16 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 09 March 2011 - 09:30 AM

I'm not sure what you're suggesting, here. I was looking at the possibility of re-linking pieces of NTLDR (OSLOADER.EXE) so that it exports more than just the SCSIPORT.SYS functions, but one could never distribute such a thing.

I was referring to a "brand new" LDR, let's call it "NGLDR" as per "Next Generation Loader", just like ReactOS wrote it's own FREELDR.
I perfectly know that it is a dream, due to the complexities and what not, but a man can dream :dubbio:.
There are traces - not confirmed or at least for which I was not able to find a definite understandable source of info - that FREELDR was able to boot a Server 2003 system.
http://reboot.pro/12157/
http://reboot.pro/12157/page__st__16


:cheers:
Wonko

#17 Icecube

Icecube

    Gold Member

  • Team Reboot
  • 1,051 posts
  •  
    Belgium

Posted 09 March 2011 - 09:41 AM

There are traces - not confirmed or at least for which I was not able to find a definite understandable source of info - that FREELDR was able to boot a Server 2003 system.

FreeLDR doesn't have NTFS support atm, so you can only boot from FAT/iso9660, which might be a bit annoying when you want to work with large image files.

#18 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 09 March 2011 - 10:09 AM

FreeLDR doesn't have NTFS support atm, so you can only boot from FAT/iso9660, which might be a bit annoying when you want to work with large image files.

Sure :dubbio:, I know, but personally I have NO problems whatsoever with FAT32, expecially if we are talking of smallish images, let's say typically below 1.5 Gb.
Can you confirm that FREELDR can work on FAT32 to boot XP or Windows 2003?
Can you post (not here) some documentation/tutorials/whatever about this feature?

:cheers:
Wonko

#19 Icecube

Icecube

    Gold Member

  • Team Reboot
  • 1,051 posts
  •  
    Belgium

Posted 09 March 2011 - 01:24 PM

freeldr.sys is multiboot compliant and can be loaded by grub4dos:
http://www.reactos.c...oader_from_GRUB

According to the SVN server with the ReactOS source code, NTFS seems to be supported by FreeLDR now:
http://svn.reactos.o...reeldr/freeldr/

Edit:
freeldr.sys is now in PE format, and can't be booted as multiboot image atm.
But it might be possible to make the PE version multiboot compliant:
http://ksrenevasan.b...nels-using.html
http://fanael.wordpr...boot-compliant/

#20 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7,771 posts

Posted 09 March 2011 - 01:53 PM

:( And what are you doing now, master Wonko, with your dream, now that it has become reality? :dubbio:

:cheers:

#21 Mitolo

Mitolo
  • Members
  • 1 posts
  •  
    United States

Posted 09 March 2011 - 07:28 PM

Thank :dubbio:

#22 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 09 March 2011 - 07:30 PM

@Icecube
Very good news about NTFS support :cheers: , still the actual capability to load XP or 2003 or both needs a confirmation of some kind. :dubbio:

:offtopic: And what are you doing now, master Wonko, with your dream, now that it has become reality? :unsure:

My dream was/is more ambitious than that :( and though as said this NTBOOTDD.SYS is a great achievement :worship: my dream is yet to become reality. :(

IF it is confirmed that FREELDR can actually load an XP (and possibly a 2K and a Server 2003), my dream is that INSTEAD of:

a hacked NTLDR + NTBOOTDD.SYS + WinVblock or Firadisk (in a new version that "connects" to the NTBOOTDD.SYS)

we can have:

non-hacked FREELDR + NTBOOTDD.SYS + WinVblock or Firadisk (in a new version that "connects" to the NTBOOTDD.SYS)

or anyway have "our own" loader :cheers: complete with source code, that could solve - in the hands of willing and talented programmers like karyonix and Sha0 :thumbup: - a number of problems, like the "Dietmar's modified NTDETECT.COM", the "Server 2003 SP1" files and/or the 512 Mb limitation for ramdisk, using the same loader for both a PE and a "full" XP/2003, etc.)

:cheers:
Wonko

#23 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7,771 posts

Posted 09 March 2011 - 08:01 PM

or anyway have "our own" loader :rolleyes: complete with source code, that could solve - in the hands of willing and talented programmers like karyonix and Sha0 :thumbup: - a number of problems, like the "Dietmar's modified NTDETECT.COM", the "Server 2003 SP1" files and/or the 512 Mb limitation for ramdisk, using the same loader for both a PE and a "full" XP/2003, etc.)

See, that is the part i don't get.
Why do you want a new solution, for problems which already have solutions? :cheers:
It's not like a free loader, would be the only thing stopping us, from distributing ready build PE1 CDs or opening a PE building business or whatever.

:cheers:

#24 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 09 March 2011 - 08:29 PM

See, that is the part i don't get.

Well :rolleyes:, there is no need for you to get it, it's my dream.

.... distributing ready build PE1 CDs or opening a PE building business or whatever.

Maybe that's your dream. :cheers:

:thumbup:
Wonko

#25 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1,676 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 11 March 2011 - 01:04 AM

Well, Wonko the Sane, your dream might or might not be possible. IceCube's and your post caused me to get ReacOS to see what was possible. Since I use git...:

cd /usr/src/

git svn clone svn://svn.reactos.org/reactos/trunk/reactos

...Wait for 10 hours...
Then I downloaded the ReactOS Build Environment for Unix (since I'm running a no-GUI Ubuntu under coLinux on Windows XP Professional SP2). I unzipped it to /usr/src/RosBE-Unix-1.5/, then:

cd /usr/src/RosBE-Unix-1.5/

./RosBE-Builder.sh

When that was finished building (an hour or a bit more), I did:

/usr/local/RosBE/RosBE.sh

cd /usr/src/reactos/

make freeldr

After all that, I learned that a [relatively] recent commit (the actual commit found by IceCube) actually means that FreeLoader (FreeLdr.sys) can now only be chain-loaded via a boot-sector. :thumbdown: I haven't yet gotten a boot-sector patched up to attempt loading XP with FreeLdr.

Anyway, there are two challenges to overcome using the NTBOOTDD.SYS strategy:
  • Even if it works and we can pass very nice information to WinVBlock or FiRaDisk, where should we pass this information? karyonix: Have you any thoughts? I'd thought about abusing the INT 0x13 vector and throwing an address in there, but that seems very ugly.
  • I haven't verified for absolute certain, but I believe that NTLDR only allows one file to be open at a time. What this means is that the version attached to the first post has to save NTLDR's file "table" (table of one?!), then open the HDD image file and work with it, then close it, then restore the file "table" so that whatever file NTLDR was working with is back the way it was. NTLDR loads the SYSTEM hive, HAL, kernel, drivers, fonts, etc. This save-and-restore process is very slow!
:)

--- EDIT ---

And the answer (right now) is: Nope. FreeLdr can come very close to loading XP, but XP dies. It can setup the environment enough that I can attach WinDbg and catch the crash, which is pretty impressive. Another item of interest is that FreeLdr doesn't invoke NTDETECT.COM, so it either includes its own counterpart, or skips it. The XP dies when it's about to invoke boot drivers; it's trying to read the Registry, but perhaps the Registry hasn't been placed where it's expected to be. :offtopic: