hi all

i need to implement booting XPE remotely (PXE/RPL) without local disk.
remote boot service is not acceptable because it eats up too much of memory.
any idea or direction is appreciated.

Nick

You are kidding right?

1a. Add more memory.
1b. Reduce image size.
2. Give up on this idea.
3. Spend months creating your own driver.
4. Find some other way probably unknown to me.

If you want hypothetical approach to number 3.

Make SDI that will contain only drivers and your driver. This need to
contain files that are loaded before volume C: is mounted.

Your driver need to communicate with your server and to expose virtual disk
device. Or maybe even better you should expose partition C: forced export
(without mount and anything else).
In first case you should be able to create virtual disk device.
In second case you will have virtual volume that is not mounted.
You could go even so far that you could store information's back to server,
so you would not need to use EWF either.

In case that this is possible, what would happen is you loose connection to
server for few moments during read or write, your device would crash, is
this what you really want?


Regards,
Slobodan






"zx1620" <(E-Mail Removed)> wrote in message
news:#(E-Mail Removed)...
> hi all
>
> i need to implement booting XPE remotely (PXE/RPL) without local disk.
> remote boot service is not acceptable because it eats up too much of
memory.
> any idea or direction is appreciated.
>
> Nick
>
>

thx, Slobodan!

>3. Spend months creating your own driver.
i'd like this one. a good chance to get into the system.

>This need to contain files that are loaded before volume C: is mounted
i know that this is the key to the success, if this issue gets passed,
the left things may be easier. but now, i have no idea on how to get this
done.

>what would happen is you loose connection to server for few moments during
read or write, your device would crash
sorry, are you sure about that?

Nick


"Slobodan Brcin" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> You are kidding right?
>
> 1a. Add more memory.
> 1b. Reduce image size.
> 2. Give up on this idea.
> 3. Spend months creating your own driver.
> 4. Find some other way probably unknown to me.
>
> If you want hypothetical approach to number 3.
>
> Make SDI that will contain only drivers and your driver. This need to
> contain files that are loaded before volume C: is mounted.
>
> Your driver need to communicate with your server and to expose virtual
disk
> device. Or maybe even better you should expose partition C: forced export
> (without mount and anything else).
> In first case you should be able to create virtual disk device.
> In second case you will have virtual volume that is not mounted.
> You could go even so far that you could store information's back to
server,
> so you would not need to use EWF either.
>
> In case that this is possible, what would happen is you loose connection
to
> server for few moments during read or write, your device would crash, is
> this what you really want?
>
>
> Regards,
> Slobodan
>
>
>
>
>
>
> "zx1620" <(E-Mail Removed)> wrote in message
> news:#(E-Mail Removed)...
> > hi all
> >
> > i need to implement booting XPE remotely (PXE/RPL) without local
disk.
> > remote boot service is not acceptable because it eats up too much of
> memory.
> > any idea or direction is appreciated.
> >
> > Nick
> >
> >
>
>

Nick,

I think that I overestimated the problem, this should not be so hard to do.

1. You should make only one SDI image with bootable disk image.
2. Use DDK example of ramdisk and modify it with following adjustments.
- You should use NDIS (it is easy) for accessing network, or there are third
party socket support for drivers (I prefer NDIS it is cleaner).
- You create virtual disk, not volume.
- For all read request directed to your disk you should read requested info
from SDI file stored on server.
- For all write request RAM EWF should protect you from getting this type of
request.
- If you loose connection with server and you have read request pending then
you could block your device and wait until connection is reestablished (very
bad).

Process of boot:
1. BIOS map your disk from SDI file, and makes it accessible trough int 13.
2. ntldr. start booting device using int 13 like on local HDD.
3. When all required OS drivers are loaded (including your driver) system
will try to continue boot from partition and logical volume.
- Since your driver is loaded and it represents only disk device in your
system. XPe will continue boot process trough your driver.


I don't know if this is enough but it should cover most of the problems.

Regards,
Slobodan




"zx1620" <(E-Mail Removed)> wrote in message
news:#9dnA$(E-Mail Removed)...
> thx, Slobodan!
>
> >3. Spend months creating your own driver.
> i'd like this one. a good chance to get into the system.
>
> >This need to contain files that are loaded before volume C: is mounted
> i know that this is the key to the success, if this issue gets passed,
> the left things may be easier. but now, i have no idea on how to get this
> done.
>
> >what would happen is you loose connection to server for few moments
during
> read or write, your device would crash
> sorry, are you sure about that?
>
> Nick
>
>
> "Slobodan Brcin" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > You are kidding right?
> >
> > 1a. Add more memory.
> > 1b. Reduce image size.
> > 2. Give up on this idea.
> > 3. Spend months creating your own driver.
> > 4. Find some other way probably unknown to me.
> >
> > If you want hypothetical approach to number 3.
> >
> > Make SDI that will contain only drivers and your driver. This need to
> > contain files that are loaded before volume C: is mounted.
> >
> > Your driver need to communicate with your server and to expose virtual
> disk
> > device. Or maybe even better you should expose partition C: forced
export
> > (without mount and anything else).
> > In first case you should be able to create virtual disk device.
> > In second case you will have virtual volume that is not mounted.
> > You could go even so far that you could store information's back to
> server,
> > so you would not need to use EWF either.
> >
> > In case that this is possible, what would happen is you loose connection
> to
> > server for few moments during read or write, your device would crash, is
> > this what you really want?
> >
> >
> > Regards,
> > Slobodan
> >
> >
> >
> >
> >
> >
> > "zx1620" <(E-Mail Removed)> wrote in message
> > news:#(E-Mail Removed)...
> > > hi all
> > >
> > > i need to implement booting XPE remotely (PXE/RPL) without local
> disk.
> > > remote boot service is not acceptable because it eats up too much of
> > memory.
> > > any idea or direction is appreciated.
> > >
> > > Nick
> > >
> > >
> >
> >
>
>

Slobodan
thanks a lot!
you give out most useful information i need. so what i should do is:
1. create a NDIS-Disk driver that does following work:
FS IO <--> NDISDISK <--> Remote Server
what's the best solution at server side? a virtual disk, right?

2. provide a bootable SDI image of mini-footprint and a target image(virtual
disk on server).
WAO!!!! no need to care about pxe .
component of windows ram disk is also not used anymore.


3. get NDISDISK loaded in a proper way so it could be recognized as the only
disk in system.
is there any special thing to pay attention at this point?

4. all things are working in my way

Regards

Nick

"Slobodan Brcin" <(E-Mail Removed)> wrote in message
news:#(E-Mail Removed)...
> Nick,
>
> I think that I overestimated the problem, this should not be so hard to
do.
>
> 1. You should make only one SDI image with bootable disk image.
> 2. Use DDK example of ramdisk and modify it with following adjustments.
> - You should use NDIS (it is easy) for accessing network, or there are
third
> party socket support for drivers (I prefer NDIS it is cleaner).
> - You create virtual disk, not volume.
> - For all read request directed to your disk you should read requested
info
> from SDI file stored on server.
> - For all write request RAM EWF should protect you from getting this type
of
> request.
> - If you loose connection with server and you have read request pending
then
> you could block your device and wait until connection is reestablished
(very
> bad).
>
> Process of boot:
> 1. BIOS map your disk from SDI file, and makes it accessible trough int
13.
> 2. ntldr. start booting device using int 13 like on local HDD.
> 3. When all required OS drivers are loaded (including your driver) system
> will try to continue boot from partition and logical volume.
> - Since your driver is loaded and it represents only disk device in your
> system. XPe will continue boot process trough your driver.
>
>
> I don't know if this is enough but it should cover most of the problems.
>
> Regards,
> Slobodan
>
>
>
>
> "zx1620" <(E-Mail Removed)> wrote in message
> news:#9dnA$(E-Mail Removed)...
> > thx, Slobodan!
> >
> > >3. Spend months creating your own driver.
> > i'd like this one. a good chance to get into the system.
> >
> > >This need to contain files that are loaded before volume C: is mounted
> > i know that this is the key to the success, if this issue gets
passed,
> > the left things may be easier. but now, i have no idea on how to get
this
> > done.
> >
> > >what would happen is you loose connection to server for few moments
> during
> > read or write, your device would crash
> > sorry, are you sure about that?
> >
> > Nick
> >
> >
> > "Slobodan Brcin" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> > > You are kidding right?
> > >
> > > 1a. Add more memory.
> > > 1b. Reduce image size.
> > > 2. Give up on this idea.
> > > 3. Spend months creating your own driver.
> > > 4. Find some other way probably unknown to me.
> > >
> > > If you want hypothetical approach to number 3.
> > >
> > > Make SDI that will contain only drivers and your driver. This need to
> > > contain files that are loaded before volume C: is mounted.
> > >
> > > Your driver need to communicate with your server and to expose virtual
> > disk
> > > device. Or maybe even better you should expose partition C: forced
> export
> > > (without mount and anything else).
> > > In first case you should be able to create virtual disk device.
> > > In second case you will have virtual volume that is not mounted.
> > > You could go even so far that you could store information's back to
> > server,
> > > so you would not need to use EWF either.
> > >
> > > In case that this is possible, what would happen is you loose
connection
> > to
> > > server for few moments during read or write, your device would crash,
is
> > > this what you really want?
> > >
> > >
> > > Regards,
> > > Slobodan
> > >
> > >
> > >
> > >
> > >
> > >
> > > "zx1620" <(E-Mail Removed)> wrote in message
> > > news:#(E-Mail Removed)...
> > > > hi all
> > > >
> > > > i need to implement booting XPE remotely (PXE/RPL) without local
> > disk.
> > > > remote boot service is not acceptable because it eats up too much of
> > > memory.
> > > > any idea or direction is appreciated.
> > > >
> > > > Nick
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Nick,


You never said do you need info made on client to be persistent after
reboot. But as you draw connections I concluded that you want to use server
to store information that are made on client.
If you don't want to store changed info on server then you should use RAM
EWF on client side.
Something like: FS <=> EWF <= Partition <= NDISDISK <=...= Remote Server
(Your app or driver that will serve required image data.)
This requires you to have SDI file and DiskImage file on your server.
I use < and > for disk data direction.

Also there is alternate solution for two way communication:

FS <=> NDISVolume <=...=> Remote Server (Your app or driver.)
Client side driver could be derived directly from ramdisk sample from DDK in
previous case you would need to simulate storage device.
On server side you must have SDI file with content of XPe partition one file
for all clients. It will be used during the boot and for data read.
Also you will need one file per each client that will persistently contain
changes made to volume on client side.
When you give read request from client first you will try to read info from
this file (associated to client), and if requested info is not found in it
then you will send info that you read from SDI file.
Basically this would be simulation of Disk based overlay from EWF, but it
would happen on server side.
You must create program on server side that will handle all this requests.

Third and probably the most compact solution if you only need to read data
from server would be:
FS<=> Integrated_RAMEWF_NDIS_Volume <=..= Remote server (no application
needed).

1. You would need to integrate functionality similar to RAM EWF.
2. You need to expose volume C: this you should be able easily to create
using ramdisk sample.
3. You should use NDIS and make support for TFTP so you can read info from
same SDI file that you used for initial boot.

This is the most compact solution and probably easiest to accomplish. You
have to maintain only one file on server side. No need for extra support on
server side.


Your choice.


Regards,
Slobodan







"zx1620" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Slobodan
> thanks a lot!
> you give out most useful information i need. so what i should do is:
> 1. create a NDIS-Disk driver that does following work:
> FS IO <--> NDISDISK <--> Remote Server
> what's the best solution at server side? a virtual disk, right?
>
> 2. provide a bootable SDI image of mini-footprint and a target
image(virtual
> disk on server).
> WAO!!!! no need to care about pxe .
> component of windows ram disk is also not used anymore.
>
>
> 3. get NDISDISK loaded in a proper way so it could be recognized as the
only
> disk in system.
> is there any special thing to pay attention at this point?
>
> 4. all things are working in my way
>
> Regards
>
> Nick
>
> "Slobodan Brcin" <(E-Mail Removed)> wrote in message
> news:#(E-Mail Removed)...
> > Nick,
> >
> > I think that I overestimated the problem, this should not be so hard to
> do.
> >
> > 1. You should make only one SDI image with bootable disk image.
> > 2. Use DDK example of ramdisk and modify it with following adjustments.
> > - You should use NDIS (it is easy) for accessing network, or there are
> third
> > party socket support for drivers (I prefer NDIS it is cleaner).
> > - You create virtual disk, not volume.
> > - For all read request directed to your disk you should read requested
> info
> > from SDI file stored on server.
> > - For all write request RAM EWF should protect you from getting this
type
> of
> > request.
> > - If you loose connection with server and you have read request pending
> then
> > you could block your device and wait until connection is reestablished
> (very
> > bad).
> >
> > Process of boot:
> > 1. BIOS map your disk from SDI file, and makes it accessible trough int
> 13.
> > 2. ntldr. start booting device using int 13 like on local HDD.
> > 3. When all required OS drivers are loaded (including your driver)
system
> > will try to continue boot from partition and logical volume.
> > - Since your driver is loaded and it represents only disk device in your
> > system. XPe will continue boot process trough your driver.
> >
> >
> > I don't know if this is enough but it should cover most of the problems.
> >
> > Regards,
> > Slobodan
> >
> >
> >
> >
> > "zx1620" <(E-Mail Removed)> wrote in message
> > news:#9dnA$(E-Mail Removed)...
> > > thx, Slobodan!
> > >
> > > >3. Spend months creating your own driver.
> > > i'd like this one. a good chance to get into the system.
> > >
> > > >This need to contain files that are loaded before volume C: is
mounted
> > > i know that this is the key to the success, if this issue gets
> passed,
> > > the left things may be easier. but now, i have no idea on how to get
> this
> > > done.
> > >
> > > >what would happen is you loose connection to server for few moments
> > during
> > > read or write, your device would crash
> > > sorry, are you sure about that?
> > >
> > > Nick
> > >
> > >
> > > "Slobodan Brcin" <(E-Mail Removed)> wrote in message
> > > news:(E-Mail Removed)...
> > > > You are kidding right?
> > > >
> > > > 1a. Add more memory.
> > > > 1b. Reduce image size.
> > > > 2. Give up on this idea.
> > > > 3. Spend months creating your own driver.
> > > > 4. Find some other way probably unknown to me.
> > > >
> > > > If you want hypothetical approach to number 3.
> > > >
> > > > Make SDI that will contain only drivers and your driver. This need
to
> > > > contain files that are loaded before volume C: is mounted.
> > > >
> > > > Your driver need to communicate with your server and to expose
virtual
> > > disk
> > > > device. Or maybe even better you should expose partition C: forced
> > export
> > > > (without mount and anything else).
> > > > In first case you should be able to create virtual disk device.
> > > > In second case you will have virtual volume that is not mounted.
> > > > You could go even so far that you could store information's back to
> > > server,
> > > > so you would not need to use EWF either.
> > > >
> > > > In case that this is possible, what would happen is you loose
> connection
> > > to
> > > > server for few moments during read or write, your device would
crash,
> is
> > > > this what you really want?
> > > >
> > > >
> > > > Regards,
> > > > Slobodan
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > "zx1620" <(E-Mail Removed)> wrote in message
> > > > news:#(E-Mail Removed)...
> > > > > hi all
> > > > >
> > > > > i need to implement booting XPE remotely (PXE/RPL) without
local
> > > disk.
> > > > > remote boot service is not acceptable because it eats up too much
of
> > > > memory.
> > > > > any idea or direction is appreciated.
> > > > >
> > > > > Nick
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

I was carried away with my last post, but in my first post I stated with a
reason why boot SDI file must be small.
Since ntldr will load whole sdi file to memory, it should be as small as
possible.
And it appear that you will need to have at least one file besides this SDI
file.

But you can still use TFTP to fetch data from server, without additional
need for server side application.


There might be probably another way so you can use only one SDI, but this
you will need to investigate.

1. To persuade ntldr using the PXE or (custom ASM int 13 handler that will
simulate local disk) so ntldr. would think that it is loading from HDD.
2. To check complete PXE TFTP specification and to see what support is
offered by these recommendations.

Regards,
Slobodan



"Slobodan Brcin" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Nick,
>
>
> You never said do you need info made on client to be persistent after
> reboot. But as you draw connections I concluded that you want to use
server
> to store information that are made on client.
> If you don't want to store changed info on server then you should use RAM
> EWF on client side.
> Something like: FS <=> EWF <= Partition <= NDISDISK <=...= Remote Server
> (Your app or driver that will serve required image data.)
> This requires you to have SDI file and DiskImage file on your server.
> I use < and > for disk data direction.
>
> Also there is alternate solution for two way communication:
>
> FS <=> NDISVolume <=...=> Remote Server (Your app or driver.)
> Client side driver could be derived directly from ramdisk sample from DDK
in
> previous case you would need to simulate storage device.
> On server side you must have SDI file with content of XPe partition one
file
> for all clients. It will be used during the boot and for data read.
> Also you will need one file per each client that will persistently contain
> changes made to volume on client side.
> When you give read request from client first you will try to read info
from
> this file (associated to client), and if requested info is not found in it
> then you will send info that you read from SDI file.
> Basically this would be simulation of Disk based overlay from EWF, but it
> would happen on server side.
> You must create program on server side that will handle all this requests.
>
> Third and probably the most compact solution if you only need to read data
> from server would be:
> FS<=> Integrated_RAMEWF_NDIS_Volume <=..= Remote server (no application
> needed).
>
> 1. You would need to integrate functionality similar to RAM EWF.
> 2. You need to expose volume C: this you should be able easily to create
> using ramdisk sample.
> 3. You should use NDIS and make support for TFTP so you can read info from
> same SDI file that you used for initial boot.
>
> This is the most compact solution and probably easiest to accomplish. You
> have to maintain only one file on server side. No need for extra support
on
> server side.
>
>
> Your choice.
>
>
> Regards,
> Slobodan
>
>
>
>
>
>
>
> "zx1620" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > Slobodan
> > thanks a lot!
> > you give out most useful information i need. so what i should do is:
> > 1. create a NDIS-Disk driver that does following work:
> > FS IO <--> NDISDISK <--> Remote Server
> > what's the best solution at server side? a virtual disk, right?
> >
> > 2. provide a bootable SDI image of mini-footprint and a target
> image(virtual
> > disk on server).
> > WAO!!!! no need to care about pxe .
> > component of windows ram disk is also not used anymore.
> >
> >
> > 3. get NDISDISK loaded in a proper way so it could be recognized as the
> only
> > disk in system.
> > is there any special thing to pay attention at this point?
> >
> > 4. all things are working in my way
> >
> > Regards
> >
> > Nick
> >
> > "Slobodan Brcin" <(E-Mail Removed)> wrote in message
> > news:#(E-Mail Removed)...
> > > Nick,
> > >
> > > I think that I overestimated the problem, this should not be so hard
to
> > do.
> > >
> > > 1. You should make only one SDI image with bootable disk image.
> > > 2. Use DDK example of ramdisk and modify it with following
adjustments.
> > > - You should use NDIS (it is easy) for accessing network, or there are
> > third
> > > party socket support for drivers (I prefer NDIS it is cleaner).
> > > - You create virtual disk, not volume.
> > > - For all read request directed to your disk you should read requested
> > info
> > > from SDI file stored on server.
> > > - For all write request RAM EWF should protect you from getting this
> type
> > of
> > > request.
> > > - If you loose connection with server and you have read request
pending
> > then
> > > you could block your device and wait until connection is reestablished
> > (very
> > > bad).
> > >
> > > Process of boot:
> > > 1. BIOS map your disk from SDI file, and makes it accessible trough
int
> > 13.
> > > 2. ntldr. start booting device using int 13 like on local HDD.
> > > 3. When all required OS drivers are loaded (including your driver)
> system
> > > will try to continue boot from partition and logical volume.
> > > - Since your driver is loaded and it represents only disk device in
your
> > > system. XPe will continue boot process trough your driver.
> > >
> > >
> > > I don't know if this is enough but it should cover most of the
problems.
> > >
> > > Regards,
> > > Slobodan
> > >
> > >
> > >
> > >
> > > "zx1620" <(E-Mail Removed)> wrote in message
> > > news:#9dnA$(E-Mail Removed)...
> > > > thx, Slobodan!
> > > >
> > > > >3. Spend months creating your own driver.
> > > > i'd like this one. a good chance to get into the system.
> > > >
> > > > >This need to contain files that are loaded before volume C: is
> mounted
> > > > i know that this is the key to the success, if this issue gets
> > passed,
> > > > the left things may be easier. but now, i have no idea on how to get
> > this
> > > > done.
> > > >
> > > > >what would happen is you loose connection to server for few moments
> > > during
> > > > read or write, your device would crash
> > > > sorry, are you sure about that?
> > > >
> > > > Nick
> > > >
> > > >
> > > > "Slobodan Brcin" <(E-Mail Removed)> wrote in message
> > > > news:(E-Mail Removed)...
> > > > > You are kidding right?
> > > > >
> > > > > 1a. Add more memory.
> > > > > 1b. Reduce image size.
> > > > > 2. Give up on this idea.
> > > > > 3. Spend months creating your own driver.
> > > > > 4. Find some other way probably unknown to me.
> > > > >
> > > > > If you want hypothetical approach to number 3.
> > > > >
> > > > > Make SDI that will contain only drivers and your driver. This need
> to
> > > > > contain files that are loaded before volume C: is mounted.
> > > > >
> > > > > Your driver need to communicate with your server and to expose
> virtual
> > > > disk
> > > > > device. Or maybe even better you should expose partition C: forced
> > > export
> > > > > (without mount and anything else).
> > > > > In first case you should be able to create virtual disk device.
> > > > > In second case you will have virtual volume that is not mounted.
> > > > > You could go even so far that you could store information's back
to
> > > > server,
> > > > > so you would not need to use EWF either.
> > > > >
> > > > > In case that this is possible, what would happen is you loose
> > connection
> > > > to
> > > > > server for few moments during read or write, your device would
> crash,
> > is
> > > > > this what you really want?
> > > > >
> > > > >
> > > > > Regards,
> > > > > Slobodan
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > "zx1620" <(E-Mail Removed)> wrote in message
> > > > > news:#(E-Mail Removed)...
> > > > > > hi all
> > > > > >
> > > > > > i need to implement booting XPE remotely (PXE/RPL) without
> local
> > > > disk.
> > > > > > remote boot service is not acceptable because it eats up too
much
> of
> > > > > memory.
> > > > > > any idea or direction is appreciated.
> > > > > >
> > > > > > Nick
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Slobodan
thx!
yes, if i don't keep change, i could use RAM EWF at client side or a own
implement at server side.if RAM EWF used, how can i get it to work because
there is no EWF volume existing.

>FS<=> Integrated_RAMEWF_NDIS_Volume <=..= Remote server (no application
> needed).
i choose this mode at the beginning if RAM EWF works.
here's coming some more detailed issues, could you help me to analyse.

1.the bootable sdi is loaded into memory thru DHCP/PXE/TFTP, but how can i
know which server to contact with after my NDisk driver got loaded? there is
no parameters or settings tell me the server address.

2.which is the best way to call NDIS from my driver, calling TDI , binding
to a miniport or any other?

3 at server side, for bootable sdi footprint, nothing neeeded. however, i
need to implement a file disk driver that hold the target image. also i need
a server app to listen all disk redirect request from client and pass them
to the file disk driver. it would be like:

disk i/o request-->network disk--(calling
NDIS)-->Server--(DeviceIOControl)-->file disk
is there any problem?

here is another question?
during boot progress, at which point, no INT 13 is called anymore? im
trying to get answer using windbg and softice, no result yet.

Nick

"Slobodan Brcin" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Nick,
>
>
> You never said do you need info made on client to be persistent after
> reboot. But as you draw connections I concluded that you want to use
server
> to store information that are made on client.
> If you don't want to store changed info on server then you should use RAM
> EWF on client side.
> Something like: FS <=> EWF <= Partition <= NDISDISK <=...= Remote Server
> (Your app or driver that will serve required image data.)
> This requires you to have SDI file and DiskImage file on your server.
> I use < and > for disk data direction.
>
> Also there is alternate solution for two way communication:
>
> FS <=> NDISVolume <=...=> Remote Server (Your app or driver.)
> Client side driver could be derived directly from ramdisk sample from DDK
in
> previous case you would need to simulate storage device.
> On server side you must have SDI file with content of XPe partition one
file
> for all clients. It will be used during the boot and for data read.
> Also you will need one file per each client that will persistently contain
> changes made to volume on client side.
> When you give read request from client first you will try to read info
from
> this file (associated to client), and if requested info is not found in it
> then you will send info that you read from SDI file.
> Basically this would be simulation of Disk based overlay from EWF, but it
> would happen on server side.
> You must create program on server side that will handle all this requests.
>
> Third and probably the most compact solution if you only need to read data
> from server would be:
> FS<=> Integrated_RAMEWF_NDIS_Volume <=..= Remote server (no application
> needed).
>
> 1. You would need to integrate functionality similar to RAM EWF.
> 2. You need to expose volume C: this you should be able easily to create
> using ramdisk sample.
> 3. You should use NDIS and make support for TFTP so you can read info from
> same SDI file that you used for initial boot.
>
> This is the most compact solution and probably easiest to accomplish. You
> have to maintain only one file on server side. No need for extra support
on
> server side.
>
>
> Your choice.
>
>
> Regards,
> Slobodan
>
>
>
>
>
>
>
> "zx1620" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > Slobodan
> > thanks a lot!
> > you give out most useful information i need. so what i should do is:
> > 1. create a NDIS-Disk driver that does following work:
> > FS IO <--> NDISDISK <--> Remote Server
> > what's the best solution at server side? a virtual disk, right?
> >
> > 2. provide a bootable SDI image of mini-footprint and a target
> image(virtual
> > disk on server).
> > WAO!!!! no need to care about pxe .
> > component of windows ram disk is also not used anymore.
> >
> >
> > 3. get NDISDISK loaded in a proper way so it could be recognized as the
> only
> > disk in system.
> > is there any special thing to pay attention at this point?
> >
> > 4. all things are working in my way
> >
> > Regards
> >
> > Nick
> >
> > "Slobodan Brcin" <(E-Mail Removed)> wrote in message
> > news:#(E-Mail Removed)...
> > > Nick,
> > >
> > > I think that I overestimated the problem, this should not be so hard
to
> > do.
> > >
> > > 1. You should make only one SDI image with bootable disk image.
> > > 2. Use DDK example of ramdisk and modify it with following
adjustments.
> > > - You should use NDIS (it is easy) for accessing network, or there are
> > third
> > > party socket support for drivers (I prefer NDIS it is cleaner).
> > > - You create virtual disk, not volume.
> > > - For all read request directed to your disk you should read requested
> > info
> > > from SDI file stored on server.
> > > - For all write request RAM EWF should protect you from getting this
> type
> > of
> > > request.
> > > - If you loose connection with server and you have read request
pending
> > then
> > > you could block your device and wait until connection is reestablished
> > (very
> > > bad).
> > >
> > > Process of boot:
> > > 1. BIOS map your disk from SDI file, and makes it accessible trough
int
> > 13.
> > > 2. ntldr. start booting device using int 13 like on local HDD.
> > > 3. When all required OS drivers are loaded (including your driver)
> system
> > > will try to continue boot from partition and logical volume.
> > > - Since your driver is loaded and it represents only disk device in
your
> > > system. XPe will continue boot process trough your driver.
> > >
> > >
> > > I don't know if this is enough but it should cover most of the
problems.
> > >
> > > Regards,
> > > Slobodan
> > >
> > >
> > >
> > >
> > > "zx1620" <(E-Mail Removed)> wrote in message
> > > news:#9dnA$(E-Mail Removed)...
> > > > thx, Slobodan!
> > > >
> > > > >3. Spend months creating your own driver.
> > > > i'd like this one. a good chance to get into the system.
> > > >
> > > > >This need to contain files that are loaded before volume C: is
> mounted
> > > > i know that this is the key to the success, if this issue gets
> > passed,
> > > > the left things may be easier. but now, i have no idea on how to get
> > this
> > > > done.
> > > >
> > > > >what would happen is you loose connection to server for few moments
> > > during
> > > > read or write, your device would crash
> > > > sorry, are you sure about that?
> > > >
> > > > Nick
> > > >
> > > >
> > > > "Slobodan Brcin" <(E-Mail Removed)> wrote in message
> > > > news:(E-Mail Removed)...
> > > > > You are kidding right?
> > > > >
> > > > > 1a. Add more memory.
> > > > > 1b. Reduce image size.
> > > > > 2. Give up on this idea.
> > > > > 3. Spend months creating your own driver.
> > > > > 4. Find some other way probably unknown to me.
> > > > >
> > > > > If you want hypothetical approach to number 3.
> > > > >
> > > > > Make SDI that will contain only drivers and your driver. This need
> to
> > > > > contain files that are loaded before volume C: is mounted.
> > > > >
> > > > > Your driver need to communicate with your server and to expose
> virtual
> > > > disk
> > > > > device. Or maybe even better you should expose partition C: forced
> > > export
> > > > > (without mount and anything else).
> > > > > In first case you should be able to create virtual disk device.
> > > > > In second case you will have virtual volume that is not mounted.
> > > > > You could go even so far that you could store information's back
to
> > > > server,
> > > > > so you would not need to use EWF either.
> > > > >
> > > > > In case that this is possible, what would happen is you loose
> > connection
> > > > to
> > > > > server for few moments during read or write, your device would
> crash,
> > is
> > > > > this what you really want?
> > > > >
> > > > >
> > > > > Regards,
> > > > > Slobodan
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > "zx1620" <(E-Mail Removed)> wrote in message
> > > > > news:#(E-Mail Removed)...
> > > > > > hi all
> > > > > >
> > > > > > i need to implement booting XPE remotely (PXE/RPL) without
> local
> > > > disk.
> > > > > > remote boot service is not acceptable because it eats up too
much
> of
> > > > > memory.
> > > > > > any idea or direction is appreciated.
> > > > > >
> > > > > > Nick
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

RAM EWF can be configured and can work without EWF volume.
You can find and read my doc and component on www.xpefiles.com.

If you use EWF, then you probably wont be able to create virtual volume but
you will need virtual partition or virtual disk.

1.
You can use TCP/IP with DHCP server (default behavior) to obtain your IP
address.
Also trough NDIS you can simulate same network packets that BIOS do for PXE
boot. So you can access file you want on server using TFTP.
Much simpler implementation would be to use fixed IP address of server that
has your application, and to use direct TCP connection between your driver
and your server application.
Drawback to this is that this requires you to have your app on server side.

2.
There is no best way.
TDI is much easier and direct way to use various kind of network protocols
like TCP/IP, etc.
But if you want to use TFTP you will need to write NDIS protocol driver or
to use some third party driver.
In normal circumstances you should export upper side of your driver so it
can be accessed trough TDI. But since it is your single purpose driver you
can make another way of direct control.

3.
If you can manage to use TFTP then you can access file on server trough it,
no need for extra app on server side.
This is one way only.

If you want server app, then easiest for implement would be to use TCP/IP
for communication.
And you can use ReadFile to read requested data from file. One option.
Better option is to map view to file in memory. So you can use virtual
memory manager to handle read and write accesses to your file. Much faster
and easier, you access file like any other piece of memory.

4. use /SOS option in boot.ini you will see list of all drivers that are
loaded by ntldr. trough int 13 after this load is done I think that int 13
is no longer used and that XP start executing.

Regards,
Slobodan

"zx1620" <(E-Mail Removed)> wrote in message
news:OSgpM#(E-Mail Removed)...
> Slobodan
> thx!
> yes, if i don't keep change, i could use RAM EWF at client side or a
own
> implement at server side.if RAM EWF used, how can i get it to work because
> there is no EWF volume existing.
>
> >FS<=> Integrated_RAMEWF_NDIS_Volume <=..= Remote server (no application
> > needed).
> i choose this mode at the beginning if RAM EWF works.
> here's coming some more detailed issues, could you help me to analyse.
>
> 1.the bootable sdi is loaded into memory thru DHCP/PXE/TFTP, but how can i
> know which server to contact with after my NDisk driver got loaded? there
is
> no parameters or settings tell me the server address.
>
> 2.which is the best way to call NDIS from my driver, calling TDI , binding
> to a miniport or any other?
>
> 3 at server side, for bootable sdi footprint, nothing neeeded. however, i
> need to implement a file disk driver that hold the target image. also i
need
> a server app to listen all disk redirect request from client and pass them
> to the file disk driver. it would be like:
>
> disk i/o request-->network disk--(calling
> NDIS)-->Server--(DeviceIOControl)-->file disk
> is there any problem?
>
> here is another question?
> during boot progress, at which point, no INT 13 is called anymore? im
> trying to get answer using windbg and softice, no result yet.
>
> Nick
>
> "Slobodan Brcin" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > Nick,
> >
> >
> > You never said do you need info made on client to be persistent after
> > reboot. But as you draw connections I concluded that you want to use
> server
> > to store information that are made on client.
> > If you don't want to store changed info on server then you should use
RAM
> > EWF on client side.
> > Something like: FS <=> EWF <= Partition <= NDISDISK <=...= Remote Server
> > (Your app or driver that will serve required image data.)
> > This requires you to have SDI file and DiskImage file on your server.
> > I use < and > for disk data direction.
> >
> > Also there is alternate solution for two way communication:
> >
> > FS <=> NDISVolume <=...=> Remote Server (Your app or driver.)
> > Client side driver could be derived directly from ramdisk sample from
DDK
> in
> > previous case you would need to simulate storage device.
> > On server side you must have SDI file with content of XPe partition one
> file
> > for all clients. It will be used during the boot and for data read.
> > Also you will need one file per each client that will persistently
contain
> > changes made to volume on client side.
> > When you give read request from client first you will try to read info
> from
> > this file (associated to client), and if requested info is not found in
it
> > then you will send info that you read from SDI file.
> > Basically this would be simulation of Disk based overlay from EWF, but
it
> > would happen on server side.
> > You must create program on server side that will handle all this
requests.
> >
> > Third and probably the most compact solution if you only need to read
data
> > from server would be:
> > FS<=> Integrated_RAMEWF_NDIS_Volume <=..= Remote server (no application
> > needed).
> >
> > 1. You would need to integrate functionality similar to RAM EWF.
> > 2. You need to expose volume C: this you should be able easily to create
> > using ramdisk sample.
> > 3. You should use NDIS and make support for TFTP so you can read info
from
> > same SDI file that you used for initial boot.
> >
> > This is the most compact solution and probably easiest to accomplish.
You
> > have to maintain only one file on server side. No need for extra support
> on
> > server side.
> >
> >
> > Your choice.
> >
> >
> > Regards,
> > Slobodan
> >
> >
> >
> >
> >
> >
> >
> > "zx1620" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> > > Slobodan
> > > thanks a lot!
> > > you give out most useful information i need. so what i should do
is:
> > > 1. create a NDIS-Disk driver that does following work:
> > > FS IO <--> NDISDISK <--> Remote Server
> > > what's the best solution at server side? a virtual disk, right?
> > >
> > > 2. provide a bootable SDI image of mini-footprint and a target
> > image(virtual
> > > disk on server).
> > > WAO!!!! no need to care about pxe .
> > > component of windows ram disk is also not used anymore.
> > >
> > >
> > > 3. get NDISDISK loaded in a proper way so it could be recognized as
the
> > only
> > > disk in system.
> > > is there any special thing to pay attention at this point?
> > >
> > > 4. all things are working in my way
> > >
> > > Regards
> > >
> > > Nick
> > >
> > > "Slobodan Brcin" <(E-Mail Removed)> wrote in message
> > > news:#(E-Mail Removed)...
> > > > Nick,
> > > >
> > > > I think that I overestimated the problem, this should not be so hard
> to
> > > do.
> > > >
> > > > 1. You should make only one SDI image with bootable disk image.
> > > > 2. Use DDK example of ramdisk and modify it with following
> adjustments.
> > > > - You should use NDIS (it is easy) for accessing network, or there
are
> > > third
> > > > party socket support for drivers (I prefer NDIS it is cleaner).
> > > > - You create virtual disk, not volume.
> > > > - For all read request directed to your disk you should read
requested
> > > info
> > > > from SDI file stored on server.
> > > > - For all write request RAM EWF should protect you from getting this
> > type
> > > of
> > > > request.
> > > > - If you loose connection with server and you have read request
> pending
> > > then
> > > > you could block your device and wait until connection is
reestablished
> > > (very
> > > > bad).
> > > >
> > > > Process of boot:
> > > > 1. BIOS map your disk from SDI file, and makes it accessible trough
> int
> > > 13.
> > > > 2. ntldr. start booting device using int 13 like on local HDD.
> > > > 3. When all required OS drivers are loaded (including your driver)
> > system
> > > > will try to continue boot from partition and logical volume.
> > > > - Since your driver is loaded and it represents only disk device in
> your
> > > > system. XPe will continue boot process trough your driver.
> > > >
> > > >
> > > > I don't know if this is enough but it should cover most of the
> problems.
> > > >
> > > > Regards,
> > > > Slobodan
> > > >
> > > >
> > > >
> > > >
> > > > "zx1620" <(E-Mail Removed)> wrote in message
> > > > news:#9dnA$(E-Mail Removed)...
> > > > > thx, Slobodan!
> > > > >
> > > > > >3. Spend months creating your own driver.
> > > > > i'd like this one. a good chance to get into the system.
> > > > >
> > > > > >This need to contain files that are loaded before volume C: is
> > mounted
> > > > > i know that this is the key to the success, if this issue gets
> > > passed,
> > > > > the left things may be easier. but now, i have no idea on how to
get
> > > this
> > > > > done.
> > > > >
> > > > > >what would happen is you loose connection to server for few
moments
> > > > during
> > > > > read or write, your device would crash
> > > > > sorry, are you sure about that?
> > > > >
> > > > > Nick
> > > > >
> > > > >
> > > > > "Slobodan Brcin" <(E-Mail Removed)> wrote in message
> > > > > news:(E-Mail Removed)...
> > > > > > You are kidding right?
> > > > > >
> > > > > > 1a. Add more memory.
> > > > > > 1b. Reduce image size.
> > > > > > 2. Give up on this idea.
> > > > > > 3. Spend months creating your own driver.
> > > > > > 4. Find some other way probably unknown to me.
> > > > > >
> > > > > > If you want hypothetical approach to number 3.
> > > > > >
> > > > > > Make SDI that will contain only drivers and your driver. This
need
> > to
> > > > > > contain files that are loaded before volume C: is mounted.
> > > > > >
> > > > > > Your driver need to communicate with your server and to expose
> > virtual
> > > > > disk
> > > > > > device. Or maybe even better you should expose partition C: forc
ed
> > > > export
> > > > > > (without mount and anything else).
> > > > > > In first case you should be able to create virtual disk device.
> > > > > > In second case you will have virtual volume that is not mounted.
> > > > > > You could go even so far that you could store information's back
> to
> > > > > server,
> > > > > > so you would not need to use EWF either.
> > > > > >
> > > > > > In case that this is possible, what would happen is you loose
> > > connection
> > > > > to
> > > > > > server for few moments during read or write, your device would
> > crash,
> > > is
> > > > > > this what you really want?
> > > > > >
> > > > > >
> > > > > > Regards,
> > > > > > Slobodan
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > "zx1620" <(E-Mail Removed)> wrote in message
> > > > > > news:#(E-Mail Removed)...
> > > > > > > hi all
> > > > > > >
> > > > > > > i need to implement booting XPE remotely (PXE/RPL) without
> > local
> > > > > disk.
> > > > > > > remote boot service is not acceptable because it eats up too
> much
> > of
> > > > > > memory.
> > > > > > > any idea or direction is appreciated.
> > > > > > >
> > > > > > > Nick
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

zx1620 schrieb:
> hi all
>
> i need to implement booting XPE remotely (PXE/RPL) without local disk.
> remote boot service is not acceptable because it eats up too much of memory.
> any idea or direction is appreciated.
>
> Nick
>
>
Take a look at BXP, from Venturcom (www.vci.com).
Only needed files are transfered, so memory requirement is reduced.

Romuald Thiéry