| Author |
Message |
Dietmar
Guest
|
 Posted:
Thu Dec 30, 2004 7:05 pm Post subject:
Re: BOOTING SDI WITH SYSLINUX |
|
|
Hi Slobodan,
I think, that only the image crashes after 120 days?
Why should Remi not send me those ntldr and startrom.com?
I think he wants an answer why other builds crash?
I will build an SDI image with the same startrom.com I used and another
build of ntldr to test whether you, Slobodan, are right.
Dietmar |
|
| Back to top |
|
 |
Slobodan Brcin (eMVP)
Guest
|
| Posted:
Thu Dec 30, 2004 7:11 pm Post subject:
Re: BOOTING SDI WITH SYSLINUX |
|
|
Hi Dietmar,
| Quote: | Why should Remi not send me those ntldr and startrom.com?
I think he wants an answer why other builds crash?
|
Because of those awful legal mumbo/jumbo stuff :-(
At the end even if you make this all work if you plan to go commercial you will have to check with your legal department if your
usage purpose is in order regarding the legal stuff.
This is far beyond my understanding to help you with :-(
Regards,
Slobodan |
|
| Back to top |
|
|
Dietmar
Guest
|
| Posted:
Thu Dec 30, 2004 7:21 pm Post subject:
Re: BOOTING SDI WITH SYSLINUX |
|
|
Hi Slobodan,
I have an setup.exe (CD1)of XP EmbeddedSP1 build 17.5.2002
and another build 13.2.2003
and another build 13.9.2002.
Which is the right?
Thanks
Dietmar |
|
| Back to top |
|
|
Slobodan Brcin (eMVP)
Guest
|
| Posted:
Thu Dec 30, 2004 7:35 pm Post subject:
Re: BOOTING SDI WITH SYSLINUX |
|
|
Hi Dietmar,
I do not remember :-(
But I think that you should have some option on main install page.
Regards,
Slobodan
"Dietmar" <dietmar.stoelting@t-online.de> wrote in message news:652afcbd0d47bb640f89b1b51e742db2@localhost.talkaboutsoftware.com...
| Quote: | Hi Slobodan,
I have an setup.exe (CD1)of XP EmbeddedSP1 build 17.5.2002
and another build 13.2.2003
and another build 13.9.2002.
Which is the right?
Thanks
Dietmar
|
|
|
| Back to top |
|
|
Dietmar
Guest
|
| Posted:
Thu Dec 30, 2004 7:52 pm Post subject:
Re: BOOTING SDI WITH SYSLINUX |
|
|
Thanks,
I got it via Loader length 34400h.
Dietmar |
|
| Back to top |
|
|
Rémi Lefèvre
Guest
|
| Posted:
Thu Dec 30, 2004 7:58 pm Post subject:
Re: BOOTING SDI WITH SYSLINUX |
|
|
On Thu, 30 Dec 2004 09:52:30 -0500, Dietmar wrote:
Hi again Dietmar,
I'm sorry for this inconvenience, but I did this patch for the company in
which I work, and I don't want to cause them problems. In all cases, like
I said, I'm in holidays and don't have those files right now. I really
want to help you, but can't do this beyond the legal stuff, and I was
quite sure that you could find the file by yourself.
Anyway, I'm glad you found the same NTLDR that I use, but as Slobodan
said, I'm afraid that you don't get more success with syslinux than with
the standard solution to boot images > 500 MB, it's a driver issue, and
the driver is not included in the boot loader.
Best regards,
Rémi
| Quote: | Thanks,
I got it via Loader length 34400h.
Dietmar |
|
|
| Back to top |
|
|
KM
Guest
|
| Posted:
Thu Dec 30, 2004 10:43 pm Post subject:
Re: BOOTING SDI WITH SYSLINUX |
|
|
Dietmar,
How about installing the Remote Boot Server and getting the ntldr from the Program Files\Windows Embedded\Remote Boot
Service\Downloads\ntldr directory?
http://www.microsoft.com/downloads/details.aspx?familyid=32379b6f-1f3a-4194-8e26-a4c9653adbc5&displaylang=en
The ntldr length there is exactly 34400h. (don't know what else we could expect :-) )
You will also find startrom.com and startrom.n12 there.
KM
PS. Seems like I missed the entire conversation by taking a nap :-)
| Quote: | Hi Dietmar,
Why should Remi not send me those ntldr and startrom.com?
I think he wants an answer why other builds crash?
Because of those awful legal mumbo/jumbo stuff :-(
At the end even if you make this all work if you plan to go commercial you will have to check with your legal department if your
usage purpose is in order regarding the legal stuff.
This is far beyond my understanding to help you with :-(
Regards,
Slobodan
|
|
|
| Back to top |
|
|
KM
Guest
|
| Posted:
Thu Dec 30, 2004 10:50 pm Post subject:
Re: BOOTING SDI WITH SYSLINUX |
|
|
Rémi,
| Quote: | Hi Dietmar,
Do you have problems with syslinux and the SDI patch ?
KM, you seem to confound Linux & syslinux. There is "linux" in syslinux
because it was initially a bootloader to boot linux. But a lot of formats
have been added with time (boot sectors, com & com32 images, disk images,
...) and with the patch, SDI. It is just a quite complete boot loader.
Actually it can be used without anything linux related (a windows tftp
server to boot a xpe client). With the patch, it is just an alternative to
startrom.n12 (/.com).
|
I see. Thanks for the clarifications!
I am interested in seeing some alternative bootloader solutions as, in my opinion, there is not so many publicly available on the
Windows market.
Since you mentioned you have a "patch" for the startrom.*, did you have a chance to implement a non unicast version (MTFTP, or
etc.)? You'd certaily have to worry about the server side as well.
KM
| Quote: | I initially made the patch to profit of the
many DHCP options that are supported by the syslinux derivative PXElinux.
regards,
R. Lefèvre
Dietmar,
What exactly you are asking about?
You don't import the blobs in any particular order. You specify which blob type you load using /import switch of the sdimgr.
Don't forget to pack the SDI file after the imports.
Please read this artcile ("Preparing the SDI" section):
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnxpesp1/html/ram_sdi.asp
Btw, how you are planning to use that SDI file? Why do you need BOOT and LOAD blobs?
I suspect that you are going to use some pxe linux server with linux tftp (don't know much about syslinux) and you don't want to
have to download anything beyond the SDI file. Is it true?
KM
HI all,
which is correkt?
BOOT blob, LOAD blob, Partition blob
or BOOT blob, Partition blob, LOAD blob?
hihi...
Dietmar
|
|
|
| Back to top |
|
|
Rémi Lefèvre
Guest
|
| Posted:
Thu Dec 30, 2004 11:27 pm Post subject:
Re: BOOTING SDI WITH SYSLINUX |
|
|
On Thu, 30 Dec 2004 09:50:08 -0800, KM wrote:
| Quote: | Rémi,
Hi Dietmar,
Do you have problems with syslinux and the SDI patch ?
KM, you seem to confound Linux & syslinux. There is "linux" in syslinux
because it was initially a bootloader to boot linux. But a lot of formats
have been added with time (boot sectors, com & com32 images, disk images,
...) and with the patch, SDI. It is just a quite complete boot loader.
Actually it can be used without anything linux related (a windows tftp
server to boot a xpe client). With the patch, it is just an alternative to
startrom.n12 (/.com).
I see. Thanks for the clarifications!
I am interested in seeing some alternative bootloader solutions as, in my opinion, there is not so many publicly available on the
Windows market.
Since you mentioned you have a "patch" for the startrom.*, did you have a chance to implement a non unicast version (MTFTP, or
etc.)? You'd certaily have to worry about the server side as well.
KM
|
Hi KM,
I don't have a patch for startrom.*, I made a patch for syslinux which
makes it an alternative for startrom.* but it is probably what you meant.
I'm not interested at the moment for non unicast transfer, and I have
not so much free time, so it is unlikely that I adapt syslinux to support
it. I can only refer you to H. Peter Anvin (the syslinux developer) who
said:
"As several of you have asked, tftp-hpa isn't likely to support multicast
TFTP any time soon, because such support would require some very
fundamental structural changes which would be very much against the goal
of keeping tftp-hpa "psycho portable", as I like to say.
However, I'm playing with the possibility of supporting multicast TFTP
(the RFC version, not the weird "MTFTP" Intel/PXE version) in PXELINUX. I
originally thought it was impossible without completely breaking the very
nice filesystem abstraction model I had already implemented, but I think I
might be able to deal with that, at least for the large files (kernel and
initrd, as opposed to config and display files.)
However, in order to test this I need a TFTP server which can do TFTP
multicast. Anyone happens to know of one?
For those of you that are interested, the reason this is tricky is that
one of the consequences of using TFTP multicast is that packets arrive out
of order. The current SYSLINUX framework assumes sequential access. To
make matters worse, the kernel file is not only not contiguous in memory,
you don't know what the memory layout will be until you have read the
first block. This can be dealt with by doing large copies, of course, but
that's rather unpleasant. It may very well be the only sane way to deal
with it, however."
and Harry Hoffman added:
"pxelinux works just great with TFTP. Why would you need MTFTP? It would
save some packets if you boot multiple clients at a time, but would need major
effort to get this into pxelinux. Also, if you managed to boot all of your clients
with MTFTP, they would also need to get some file systems (maybe root
filesystems)
via nfs or else, and this definitively doesn't work for nfs, smb and what else you
could think of.
| Quote: | Does anyone know of any other network bootloaders that use multicast? Do many
people see this as a need?
|
I don't see this as a need, since tftp works even for booting some hundred machines
at a time. You need some sane network structure for this (switched
ethernet with a
higher uplink to the server), but then it's working as it should, and also this should
be standard for modern networks."
So as you can see, it might be supported (however unlikely in the mtftp
form) in the future. It was in 2003, but I don't think there has been
updates for multicast in syslinux since.
Rémi
| Quote: | I initially made the patch to profit of the
many DHCP options that are supported by the syslinux derivative PXElinux.
regards,
R. Lefèvre
Dietmar,
What exactly you are asking about?
You don't import the blobs in any particular order. You specify which blob type you load using /import switch of the sdimgr.
Don't forget to pack the SDI file after the imports.
Please read this artcile ("Preparing the SDI" section):
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnxpesp1/html/ram_sdi.asp
Btw, how you are planning to use that SDI file? Why do you need BOOT and LOAD blobs?
I suspect that you are going to use some pxe linux server with linux tftp (don't know much about syslinux) and you don't want to
have to download anything beyond the SDI file. Is it true?
KM
HI all,
which is correkt?
BOOT blob, LOAD blob, Partition blob
or BOOT blob, Partition blob, LOAD blob?
hihi...
Dietmar
|
|
|
| Back to top |
|
|
Dietmar
Guest
|
| Posted:
Fri Dec 31, 2004 12:07 am Post subject:
Re: BOOTING SDI WITH SYSLINUX |
|
|
Hi Konstantin
thank you for the link.
I dont know whether it is the same ntldr, as I used.
I will prove this whether that one works also with SDI.
Now I gave you the exact description of what ntldr you must use for SDI
with Syslinux. (I have no company)
startrom.com in the same directory as ntldr SEEMS to be ever the same.
ONLY that ntldr works for me:
Windows Embedded SP1 Version 5.1.2600.1106
with ntldr 214016 Byte (34400h)
build 4.September 2002 16:01:46
xpsp1.020828-1920
in directoty C:\...\Windows Embedded\Remote Boot Service\Downloads\ntldr.
I tried so much ntldr's, but that from Saad Syed
I cant found.
Good luck
Dietmar |
|
| Back to top |
|
|
Dietmar
Guest
|
| Posted:
Fri Dec 31, 2004 12:41 am Post subject:
Re: BOOTING SDI WITH SYSLINUX |
|
|
Hi all,
The ntdetect.com in the above desribed version of Windows
Embedded in the folder C:\...\Windows Embedded\Remote Boot
Service\Downloads\
DIFFERS from newer Versions of XPe with SP2.
It is 47580 Bytes, (like that in XPProSP1)
and the newer ntdetect.com are 47564 Byte.
Nice to hear from you,
great work Remi
Dietmar |
|
| Back to top |
|
|
KM
Guest
|
| Posted:
Fri Dec 31, 2004 12:57 am Post subject:
Re: BOOTING SDI WITH SYSLINUX |
|
|
Rémi,
Thanks for forwarding us the info from the syslinux devs.
| Quote: | I don't have a patch for startrom.*, I made a patch for syslinux which
makes it an alternative for startrom.* but it is probably what you meant.
|
Yup. That is what I meant.
| Quote: | I'm not interested at the moment for non unicast transfer, and I have
not so much free time, so it is unlikely that I adapt syslinux to support
it. I can only refer you to H. Peter Anvin (the syslinux developer) who said:
"As several of you have asked, tftp-hpa isn't likely to support multicast
TFTP any time soon, because such support would require some very
fundamental structural changes
|
No doubt.
| Quote: | which would be very much against the goal
of keeping tftp-hpa "psycho portable", as I like to say.
|
Not sure I understood this. What portablility he is talking about here? (or, better ask, portablility of what?)
| Quote: | However, I'm playing with the possibility of supporting multicast TFTP
(the RFC version, not the weird "MTFTP" Intel/PXE version) in PXELINUX.
|
Forget about Intel's implementation of the MTFTP in PXE ROM. I does not work as needed on large networks.
I was developed for a small boot program downloads only (and this is clear from Intel protocol draft).
| Quote: | I originally thought it was impossible without completely breaking the very
nice filesystem abstraction model I had already implemented, but I think I
might be able to deal with that, at least for the large files (kernel and
initrd, as opposed to config and display files.)
|
I don't know anything aobut the syslinux filesystem abstraction model but it definitely can be done for the large files.
| Quote: | However, in order to test this I need a TFTP server which can do TFTP
multicast. Anyone happens to know of one?
|
There are some MTFTP servers on market. But you will unlikely need those.
The major reason is that you will need to tweak MTFTP protocol (if not rewrite). Current protocol specification is not meant for
multiply synched downloads of large files.
E.g., the paket counter is only 2 bytes (even with MTU 1536 it does not give you much).
So the point is that you will likely have to write your own "MTFTP" server.
| Quote: | For those of you that are interested, the reason this is tricky is that
one of the consequences of using TFTP multicast is that packets arrive out
of order.
|
Absolutely. But this problem can be fixed by the using an enhanched packet counter.
Or, tagain, in your own protcol version you can establish more proper ways to keep the order.
| Quote: | The current SYSLINUX framework assumes sequential access. To
make matters worse, the kernel file is not only not contiguous in memory,
you don't know what the memory layout will be until you have read the
first block. This can be dealt with by doing large copies, of course, but
that's rather unpleasant. It may very well be the only sane way to deal
with it, however."
and Harry Hoffman added:
"pxelinux works just great with TFTP. Why would you need MTFTP? It would
save some packets if you boot multiple clients at a time, but would need major
effort to get this into pxelinux. Also, if you managed to boot all of your clients
with MTFTP, they would also need to get some file systems (maybe root
filesystems)
via nfs or else, and this definitively doesn't work for nfs, smb and what else you
could think of.
|
Again, I can't speak for the syslinux, but in Windows world.. You don't need FS support on the client side there from bootloader.
Much more problems appear when you think about diskless stations (not having a temp local storage for the boot).
SDI will not work for you (unless you have amasinly huge RAM on your client device).
| Quote: | Does anyone know of any other network bootloaders that use multicast? Do many
people see this as a need?
|
I was researching this question a while ago and could not come to a final conclusion.
However, I think if there were a buninesse case (a strong demand) for the multicast support, MS would have already covered it.
(I am still thinking about Windows world, sorry)
| Quote: | I don't see this as a need, since tftp works even for booting some hundred machines
at a time. You need some sane network structure for this (switched
ethernet with a
higher uplink to the server), but then it's working as it should, and also this should
be standard for modern networks."
So as you can see, it might be supported (however unlikely in the mtftp
form) in the future. It was in 2003, but I don't think there has been
updates for multicast in syslinux since.
|
Yes, I agree. It can be supported but not in the RFC'd MTFTP form.
Either some protocol tweaks need to be done or a new protocol implemented.
I was evaluating some different approaches for multicast downloads of large OS images a while ago (maybe the same 2003) and we (not
only me) came up with prety good specs on the implementation side (I mean we spec'ed protocol, code, bootloader, etc.).
It was quite a long time ago and I do not remember all the details (unless I read through the specs again).
But the point is that it is doable. Since syslinux hs some good improvement on bootloader part, I thought you might have come up
with a multicast solution already.
Anyway, thanks for the dicussion and good info.
Do you have links to syslinux newgrwoups or forums (which searchable engines)? I understand it is under GPL so it should be covered
in public somehow.
Thanks,
Konstantin
| Quote: | I initially made the patch to profit of the
many DHCP options that are supported by the syslinux derivative PXElinux.
regards,
R. Lefèvre
Dietmar,
What exactly you are asking about?
You don't import the blobs in any particular order. You specify which blob type you load using /import switch of the sdimgr.
Don't forget to pack the SDI file after the imports.
Please read this artcile ("Preparing the SDI" section):
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnxpesp1/html/ram_sdi.asp
Btw, how you are planning to use that SDI file? Why do you need BOOT and LOAD blobs?
I suspect that you are going to use some pxe linux server with linux tftp (don't know much about syslinux) and you don't want
to
have to download anything beyond the SDI file. Is it true?
KM
HI all,
which is correkt?
BOOT blob, LOAD blob, Partition blob
or BOOT blob, Partition blob, LOAD blob?
hihi...
Dietmar
|
|
|
| Back to top |
|
|
Rémi Lefèvre
Guest
|
| Posted:
Fri Dec 31, 2004 9:45 am Post subject:
Re: BOOTING SDI WITH SYSLINUX |
|
|
On Thu, 30 Dec 2004 11:57:56 -0800, KM wrote:
| Quote: | Rémi,
Thanks for forwarding us the info from the syslinux devs.
I don't have a patch for startrom.*, I made a patch for syslinux which
makes it an alternative for startrom.* but it is probably what you meant.
Yup. That is what I meant.
I'm not interested at the moment for non unicast transfer, and I have
not so much free time, so it is unlikely that I adapt syslinux to support
it. I can only refer you to H. Peter Anvin (the syslinux developer) who said:
"As several of you have asked, tftp-hpa isn't likely to support multicast
TFTP any time soon, because such support would require some very
fundamental structural changes
No doubt.
which would be very much against the goal
of keeping tftp-hpa "psycho portable", as I like to say.
Not sure I understood this. What portablility he is talking about here? (or, better ask, portablility of what?)
However, I'm playing with the possibility of supporting multicast TFTP
(the RFC version, not the weird "MTFTP" Intel/PXE version) in PXELINUX.
Forget about Intel's implementation of the MTFTP in PXE ROM. I does not work as needed on large networks.
I was developed for a small boot program downloads only (and this is clear from Intel protocol draft).
I originally thought it was impossible without completely breaking the very
nice filesystem abstraction model I had already implemented, but I think I
might be able to deal with that, at least for the large files (kernel and
initrd, as opposed to config and display files.)
I don't know anything aobut the syslinux filesystem abstraction model but it definitely can be done for the large files.
However, in order to test this I need a TFTP server which can do TFTP
multicast. Anyone happens to know of one?
There are some MTFTP servers on market. But you will unlikely need those.
The major reason is that you will need to tweak MTFTP protocol (if not rewrite). Current protocol specification is not meant for
multiply synched downloads of large files.
E.g., the paket counter is only 2 bytes (even with MTU 1536 it does not give you much).
So the point is that you will likely have to write your own "MTFTP" server.
For those of you that are interested, the reason this is tricky is that
one of the consequences of using TFTP multicast is that packets arrive out
of order.
Absolutely. But this problem can be fixed by the using an enhanched packet counter.
Or, tagain, in your own protcol version you can establish more proper ways to keep the order.
The current SYSLINUX framework assumes sequential access. To
make matters worse, the kernel file is not only not contiguous in memory,
you don't know what the memory layout will be until you have read the
first block. This can be dealt with by doing large copies, of course, but
that's rather unpleasant. It may very well be the only sane way to deal
with it, however."
and Harry Hoffman added:
"pxelinux works just great with TFTP. Why would you need MTFTP? It would
save some packets if you boot multiple clients at a time, but would need major
effort to get this into pxelinux. Also, if you managed to boot all of your clients
with MTFTP, they would also need to get some file systems (maybe root
filesystems)
via nfs or else, and this definitively doesn't work for nfs, smb and what else you
could think of.
Again, I can't speak for the syslinux, but in Windows world.. You don't need FS support on the client side there from bootloader.
Much more problems appear when you think about diskless stations (not having a temp local storage for the boot).
SDI will not work for you (unless you have amasinly huge RAM on your client device).
Does anyone know of any other network bootloaders that use multicast? Do many
people see this as a need?
I was researching this question a while ago and could not come to a final conclusion.
However, I think if there were a buninesse case (a strong demand) for the multicast support, MS would have already covered it.
(I am still thinking about Windows world, sorry)
I don't see this as a need, since tftp works even for booting some hundred machines
at a time. You need some sane network structure for this (switched
ethernet with a
higher uplink to the server), but then it's working as it should, and also this should
be standard for modern networks."
So as you can see, it might be supported (however unlikely in the mtftp
form) in the future. It was in 2003, but I don't think there has been
updates for multicast in syslinux since.
Yes, I agree. It can be supported but not in the RFC'd MTFTP form.
Either some protocol tweaks need to be done or a new protocol implemented.
I was evaluating some different approaches for multicast downloads of large OS images a while ago (maybe the same 2003) and we (not
only me) came up with prety good specs on the implementation side (I mean we spec'ed protocol, code, bootloader, etc.).
It was quite a long time ago and I do not remember all the details (unless I read through the specs again).
But the point is that it is doable. Since syslinux hs some good improvement on bootloader part, I thought you might have come up
with a multicast solution already.
Anyway, thanks for the dicussion and good info.
Do you have links to syslinux newgrwoups or forums (which searchable engines)? I understand it is under GPL so it should be covered
in public somehow.
Thanks,
Konstantin
|
Hi Konstantin,
I don't think the syslinux mailing list has "searchable" engines. However,
you can download the full archive at this address:
http://www.zytor.com/pipermail/syslinux/
When you have this, you can easily search for anything in it.
regards,
Rémi
| Quote: | I initially made the patch to profit of the
many DHCP options that are supported by the syslinux derivative PXElinux.
regards,
R. Lefèvre
Dietmar,
What exactly you are asking about?
You don't import the blobs in any particular order. You specify which blob type you load using /import switch of the sdimgr.
Don't forget to pack the SDI file after the imports.
Please read this artcile ("Preparing the SDI" section):
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnxpesp1/html/ram_sdi.asp
Btw, how you are planning to use that SDI file? Why do you need BOOT and LOAD blobs?
I suspect that you are going to use some pxe linux server with linux tftp (don't know much about syslinux) and you don't want
to
have to download anything beyond the SDI file. Is it true?
KM
HI all,
which is correkt?
BOOT blob, LOAD blob, Partition blob
or BOOT blob, Partition blob, LOAD blob?
hihi...
Dietmar
|
|
|
| Back to top |
|
|
KM
Guest
|
| Posted:
Fri Dec 31, 2004 2:04 pm Post subject:
Re: BOOTING SDI WITH SYSLINUX |
|
|
Rémi,
| Quote: | I don't think the syslinux mailing list has "searchable" engines. However,
you can download the full archive at this address:
http://www.zytor.com/pipermail/syslinux/
When you have this, you can easily search for anything in it.
|
Thanks for the link. Any information is always helpful :-)
Konstantin |
|
| Back to top |
|
|
Rémi Lefèvre
Guest
|
| Posted:
Fri Dec 31, 2004 2:33 pm Post subject:
Re: BOOTING SDI WITH SYSLINUX |
|
|
Slobodan, Konstantin, anyone...
Have you an idea why the loader only works with this
version of NTLDR (34400h size) ?
Are you aware of any behaviour difference between the versions ?
I really don't see why it only works with this one; particularly, it
should work with the later versions released with XPe (SP2 and sooner).
Rémi
On Thu, 30 Dec 2004 14:07:55 -0500, Dietmar wrote:
| Quote: | Hi Konstantin
thank you for the link.
I dont know whether it is the same ntldr, as I used.
I will prove this whether that one works also with SDI.
Now I gave you the exact description of what ntldr you must use for SDI
with Syslinux. (I have no company)
startrom.com in the same directory as ntldr SEEMS to be ever the same.
ONLY that ntldr works for me:
Windows Embedded SP1 Version 5.1.2600.1106
with ntldr 214016 Byte (34400h)
build 4.September 2002 16:01:46
xpsp1.020828-1920
in directoty C:\...\Windows Embedded\Remote Boot Service\Downloads\ntldr.
I tried so much ntldr's, but that from Saad Syed
I cant found.
Good luck
Dietmar |
|
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in