623 replies to this topic

[karyonix]

Thanks, karyonix.

I should correct that the drive_map_table array begins at offset 0x20, not 0x100 + 0x20.

Example:
Read 4-byte data at physical address 0x0004C. The data there is 00 01 C0 9C.
That mean real INT13h handler is at segment:offset 9CC0:0100. That is physical address (segment<<4)+offset = 0x9cd00.
Data at 0x9cd00 is EB 3E 00 24 49 4E 54 31 33 53 46 47 52 55 42 34 44 4F 53 B8 16 00 F0 01 00 00 00 01 indicating that it's GRUB4DOS int13h handler.
GRUB4DOS's real int13h handler is at offset 0x100 byte from it's base address.
Its base address = 0x9cd00 - 0x100 = 0x9cc00
Its drive map table is at offset 0x20 from base address = 0x9cc00+0x20 = 0x9cc20 which is the same as 0x9cd00 - 0x100 + 0x200.
Is this correct?

[tinybit]

Its drive map table is at offset 0x20 from base address = 0x9cc00+0x20 = 0x9cc20

Right.

which is the same as 0x9cd00 - 0x100 + 0x200.

No. You added an extra 0. It should be:

0x9cc20=0x9cd00 - 0x100 + 0x20

The code begins at offset 0x100, but the data begins at offset 0.

With your example, the CS segment starts at 0x9cc00. But the leading 0x100 bytes are data. The code begins at offset 0x100, i.e., linear address 0x9cd00.

[tinybit]

I was only asking because I wanted to know if GRUB4DOS always prepended 63 sectors to a partition image. You said "usually", tinybit.

Accurately, a track is prepended. A track may be less than 63 sectors. You may look into the partition table and see where the first partition starts from.

Hopefully, your assembly doesn't change and that table stays where it is forever.

I have been off now for quite some time as far as a developer of grub4dos is concerned. But I think the data structure(s) in the int13 handler will keep long. The developers would take into account the compatibility issue.

I would like to adopt a different strategy for MEMDISK. I'd like MEMDISK to establish an "mBFT" resembling the "iBFT" for iSCSI and the "aBFT" for AoE. Once implemented, it might be nice if GRUB4DOS implemented it too, but that discussion can wait for another time. An "mBFT" would be an alternative to the current mechanism that karyonix suggested, and which GRUB4DOS currently implements.

I am sorry I cannot comment on those because those are out of my knowledge base. You may talk with the developer and others.

[cdob]

A ramdom idea:

What about RAM loaded ISO images?
Can a ramdisk driver detect this ramdisk too?
Can a ramdisk driver map the loaded ISO image to a cd-rom drive?

[Sha0]

That's actually part of my plan, cdob.

[Sha0]

*sigh*of*relief* At last, some of the more mysterious details of the early NT boot sequence. These were come across while continuing to work with WinAoE towards a generic-virtual-bus-with-disk-devices driver.

Restrictions on Miniport Drivers that Manage the Boot Drive:
http://msdn.microsof...y/aa508892.aspx

A relevant string in AIC78XX.SYS (and others which can be NTBOOTDD.SYS, including I2OMP.SYS):
ntldr=1

A sample which checks for usage from OSLOADER/NTLDR/SETUPLDR:
WINDDK\6001.18001\src\storage\miniport\i2o\i2omp.c

Other strings in AIC78XX.SYS which appear to have something to do with ScsiPortGetBusData(), and which look an awful lot like BOOT.INI/WINNT.SIF/TXTSETUP.SIF boot switches:
/INSTRUMENTATION
/POLL
/ULTRAOFF
...

A look at OSLOADER.EXE reveals that it implements the same functions as SCSIPORT.SYS. Read that as: Provides some of the same facilities to NTBOOTDD.SYS, including debug printing (yay).

--- DAMN IT, JUST LOST MY POST WITH A MYSTERY "BACK" CLICK *ARGH* --- Let me try to remember... *very*serious*gah*

For a while, I was trying to wrap my head around how the same driver for a fully booted Windows could provide block device services for NTLDR. It makes much more sense now: It checks if it's being used as NTBOOTDD.SYS, and behaves minimally, if needed. The check is on data passed by the caller of the driver's implementation of HwScsiFindAdapter(). Whether NTBOOTDD.SYS is discarded later for another instance of the loaded driver cannot be told in this post for lack of code/experiment.

Just for fun today, I printed output to the /NOGUIBOOT or /SOS Windows boot screen, you know, the one with the Windows version and CPU count on it. Since this is before even the Session Manager starts, it got me thinking about Alex Ionescu's TinyKRNL OS' Native CLI, and if it could be ported to be integrated with a driver, instead. Doing crazy things that early in the boot process is even before you stand a chance of a STOP 0x7B error; before the boot volume is accessed beyond NTLDR's work. It'd be neat to get a CLI so early on!

This is also something like the NT password hacking utility that used to float around as an NT setup F6 driver, and also something like offering the Recovery Console in that boot screen (somebody did that around here, didn't they?).

Speaking of early, it seems that there was once an anti-virus driver (or was it some other driver?) which you could see load during /SOS, and which would pause and prompt for a keystroke to do... Something... Has anyone seen a driver like this? I'm curious to see the means by which it accepts input. Trying to learn, here!

Development: Currently making a cleaner separation of the AoE parts from the bus and disk parts in WinAoE.

- Sha0

[karyonix]

I cannot find any ScsiPortxxx routine that can be used for mapping arbitrary physical address into usable virtual address.
We need ntoskrnl.exe for MmMapIoSpace. OS-independent SCSI miniport driver (NTBOOTDD.SYS) cannot use it.
You may try manipulating CR3, page directory, page tables directly -- but I don't know how to do that. Using kernel seems to be easier.

Fortunately, we don't really need NTBOOTDD.SYS.
Let NTLDR/OSLOADER use GRUB4DOS' Int13 handler to load kernel and boot drivers (including RAM disk driver). RAM disk driver can work after kernel started.

I am also trying to write a RAM disk driver.

[Sha0]

karyonix: You are quite right. I only passed this info along in order to share it; I doubt that it's useful to use anything other than INT 0x13 to access a RAM drive during the loading stage. It's simply a case of coming across something while working on something else, and the subsequent "Aha! Others should know!" - Sha0

[was_jaclaz]

Another attempt.

The SOURCE code of the OpenSource Virtualdisk driver:
http://sourceforge.n...ts/virtualdisk/

though still missing "something" for newish Windows versions:

Note that I developed it with KMDF 1.0 and tested on W2K and WXP-SP1 that
were *actual* at that time. We are in "Vista era" now. I got already notices
from virtualdisk project users, that virtual disks are not detected by Disk
Manager in latter Windows OS releases (WXP-SP2, W3K, ...), because newer
Windows Disk Manager requires support of some additional "features" from
discovered disk, during disk recognition and negotiation. Current
virtualdisk code does not support such additional Disk Manager requests and
consequentially negotiation fails.

may contain useful things.

jaclaz

[was_jaclaz]

Another "shot in the dark".

Maybe something here can be of use:
http://kobyk.wordpre...-boot-debugger/



jaclaz

[AeroXP]

*sigh*of*relief* At last, some of the more mysterious details of the early NT boot sequence. These were come across while continuing to work with WinAoE towards a generic-virtual-bus-with-disk-devices driver.

Restrictions on Miniport Drivers that Manage the Boot Drive:
http://msdn.microsof...y/aa508892.aspx

A relevant string in AIC78XX.SYS (and others which can be NTBOOTDD.SYS, including I2OMP.SYS):
ntldr=1

A sample which checks for usage from OSLOADER/NTLDR/SETUPLDR:
WINDDK\6001.18001\src\storage\miniport\i2o\i2omp.c

Other strings in AIC78XX.SYS which appear to have something to do with ScsiPortGetBusData(), and which look an awful lot like BOOT.INI/WINNT.SIF/TXTSETUP.SIF boot switches:
/INSTRUMENTATION
/POLL
/ULTRAOFF
...

A look at OSLOADER.EXE reveals that it implements the same functions as SCSIPORT.SYS. Read that as: Provides some of the same facilities to NTBOOTDD.SYS, including debug printing (yay).

--- DAMN IT, JUST LOST MY POST WITH A MYSTERY "BACK" CLICK *ARGH* --- Let me try to remember... *very*serious*gah*

For a while, I was trying to wrap my head around how the same driver for a fully booted Windows could provide block device services for NTLDR. It makes much more sense now: It checks if it's being used as NTBOOTDD.SYS, and behaves minimally, if needed. The check is on data passed by the caller of the driver's implementation of HwScsiFindAdapter(). Whether NTBOOTDD.SYS is discarded later for another instance of the loaded driver cannot be told in this post for lack of code/experiment.

Just for fun today, I printed output to the /NOGUIBOOT or /SOS Windows boot screen, you know, the one with the Windows version and CPU count on it. Since this is before even the Session Manager starts, it got me thinking about Alex Ionescu's TinyKRNL OS' Native CLI, and if it could be ported to be integrated with a driver, instead. Doing crazy things that early in the boot process is even before you stand a chance of a STOP 0x7B error; before the boot volume is accessed beyond NTLDR's work. It'd be neat to get a CLI so early on!

This is also something like the NT password hacking utility that used to float around as an NT setup F6 driver, and also something like offering the Recovery Console in that boot screen (somebody did that around here, didn't they?).

Speaking of early, it seems that there was once an anti-virus driver (or was it some other driver?) which you could see load during /SOS, and which would pause and prompt for a keystroke to do... Something... Has anyone seen a driver like this? I'm curious to see the means by which it accepts input. Trying to learn, here!

Development: Currently making a cleaner separation of the AoE parts from the bus and disk parts in WinAoE.

- AndyTim

Smss is loaded after Ntoskrnl finishes Phase0 initialization (Inits Ob, Ps, Power, Ex, Hal, etc.)

Heads up: ROS Fastfat is 75% compatible with Windows NT. NT does boot with it!

[was_jaclaz]

Another JFYI:
http://www.boot-land...?showtopic=8468



jaclaz

[joakim]

Does that driver show disks up in Device Manager? If so, and you choose View -> Devices by connection, does it show the disk as attached to anything special in particular?

This is what it looks like Device Manager;



Joakim

[xpert-reactos]

Hi folks!

ReactOS people are keen of a driver for ISO emulation too. Today we do a workaround and used hdd-images for memdisk...

I made a video.
PXE-boot with memdisk:

[was_jaclaz]

Nice to have on the board someone familiar with React-OS.

I suspect that React-OS has more undocumented things that may be useful than any other OS project around.

Another direction that is IMHO worth the attention of a programmer is the ReactOS FREELDR, that has been reported to be able to boot "normally" Server 2003.

AND:
http://www.boot-land...?...c=4207&st=7

I made a video.

Can't we have instead (or additionally ) a howto/tutorial or however some details/data/docs?



jaclaz

[xpert-reactos]

Nice to have on the board someone familiar with React-OS.

I suspect that React-OS has more undocumented things that may be useful than any other OS project around.

[....]

Can't we have instead (or additionally ) a howto/tutorial or however some details/data/docs?



jaclaz

its memdisk with a hdd-image.

[was_jaclaz]

its memdisk with a hdd-image.

Well, yes , but what is the actual React-OS driver that "takes command" once memdisk is "killed" in the "real-mode" ->"protected-mode" shift?

jaclaz

[xpert-reactos]

Well, yes , but what is the actual React-OS driver that "takes command" once memdisk is "killed" in the "real-mode" ->"protected-mode" shift?

jaclaz

append harddisk initrd=bootimages/ros-img-live-cd

Memdisk does not get killed, or it does not matter.

but not working with ISO :-(

[was_jaclaz]

append harddisk initrd=bootimages/ros-img-live-cd

Memdisk does not get killed, or it does not matter.

but not working with ISO :-(

did you try with the newish/latest release of ISOLINUX/MEMDISK, "APPEND iso", see here :
http://www.boot-land...?...ic=8258&hl=

jaclaz

[xpert-reactos]

did you try with the newish/latest release of ISOLINUX/MEMDISK, "APPEND iso", see here :
http://www.boot-land...?...ic=8258&hl=

jaclaz

Yes, I tried.

[Sha0]

I've really got to get around to completing that MEMDISK-ISO... There are a few little bits left; just gotta DO THEM.

Speaking of completing... The trick is that there isn't (yet) an open-source Windows driver to pick up the MEMDISK. Once I finish deriving from WinAoE, that should help. I plan on supporting virtual ODD (optical disc drives) as well, so a Windows PE .ISO loaded with MEMDISK would also work.

As for your video, xpert-reactos, it appears (and would make sense) that the ReactOS has a driver for using a MEMDISK, unless we couldn't see that a RAM disk was loaded by FreeLDR in the background, effectively using twice as much RAM. Very nice, anyway!

xpert-reactos: What's the advantage to using an .ISO versus an HDD image in your case? Ease of creation or something? Were you hoping that a live CD would simply load? Whoever made the RAM disk driver for ReactOS could likely support using the RAM disk as a virtual ODD instead of as a virtual HDD. If you can find out who that person is, I'd be happy to have a discussion with them.

I wonder if this new RAM disk driver I'm working on would work in ReactOS... Has anyone tried an AoE-boot of ReactOS using WinAoE? If so, and met with success, that would be a good sign.

- Sha0

[xpert-reactos]

[..]

xpert-reactos: What's the advantage to using an .ISO versus an HDD image in your case? Ease of creation or something? Were you hoping that a live CD would simply load? Whoever made the RAM disk driver for ReactOS could likely support using the RAM disk as a virtual ODD instead of as a virtual HDD. If you can find out who that person is, I'd be happy to have a discussion with them.

[...]
- AndyTim

There is a Live-CD ISO of ReactOS. Making a Fat32-Image is fun for linux geeks only and not possible without easy steps under Windows.
btw. how to mount a Fat32-image under Windows with commandline tools (open source) ?

[Brito]

how to mount a Fat32-image under Windows with commandline tools (open source) ?

Imdisk: http://en.wikipedia.org/wiki/ImDisk

It's supported by the developer himself here at boot land:
http://www.boot-land...hp?showforum=59

[xpert-reactos]

but you need admin permissions and an installed driver...thats bad.

[Brito]

but you need admin permissions and an installed driver...thats bad.

Why is this a disadvantage?

We're all admins around here..


Nevertheless, I'd recommend talking with Erwan, he's working on software that might be adjusted to what you need without admin permissions but I still doubt you'd be able to mount anything without them.

http://www.boot-land...?showtopic=8480

If it was my code, I'd do a program to run and load the image. Then, this program would remain active until someone called another instance of the program with instructions regarding what to do next.

For example.

myapp /mount c:\testdrive.hdd /title test

then

myapp /copy c:\windows\system32\*.exe /test

myapp /unmount /title test

This is a possible route for this challenge.