WinXPTalk.com

Nightman · Guest

After deploying system sucessfully using RAM Reg EWF with hibernation, I
still had some questions yet.
1. Now I can boot sytem with one clear hibernatefl.sys everytime, but how
can I update my EWF system, etc. adding some folds and files, install drivers
for perpherals ? If I commit these changes to HD, I can't ensure I still boot
up with the original clear hibernatefl.sys.
2. Yes, I can do some changes on protected volume by using "xpepm
-hibernate" without disable EWF. But where these changes to be stored, as I
found there's no changes occur to hibernatefl.sys file, even with the size
and date.
Thanks!

Nightman · Guest

But if you re-hibernate, it'll commit all the changes accumulated and I'm not
sure I can boot up system with the original fresh hibernate file. It againsts
the purpose of "Hibernate once/resume many". Can I commit only the pointed
change which I need, instead of all the accumulated changes?
Thanks.

"Sean Liming (eMVP)" wrote:

KM · Guest

I realized I was not clear in my post.
Committing the EWF volume commits the hibernation file. This zeroes out the first page of the hibernation file. This will cause the
system to boot normally and not from the hibernation file on the next boot even if it is a resume.
So you need to reboot after the EWF Commit.

KM

KM · Guest

Nightman,

See my response above. Basicaly, you have to reboot after you commit the changes and after the reboot to hibernate the image again
to use HORM.

Another option for you would be using resmany.dat
(http://msdn.microsoft.com/library/en-us/xpehelp/html/xetskEnablingHibernateOnceResumeManyEnvironmentWithEWF.asp). I never used or
tested it so I can't tell you how it works.

There is also a new feature of EWF on SP2 where you can commit some files (very restricted so you will unlikely use it). Read more
about it in XPe docs.

Another approach for you may be having an unprotected partition to store the files that needs to be changed often. But then please
keep in mind that you have to dismount that unprotected volume before you hibernate the image for HORM. Otherwise you can damage the
FS on that volume.

KM

KM · Guest

Sean Liming (eMVP) · Guest

Basically, you have to re-hibernate the system when you do an update. Using
the EWF APIs say like EWFCommitFile and then re-hiberate.

Regards,

Sean Liming (eMVP)
Managing Director
SJJ Embedded Micro Solutions

www.sjjmicro.com / www.seanliming.com
Author: Windows XP Embedded Advanced and Windows NT Embedded Step-by-Step

"Nightman" <Nightman@discussions.microsoft.com> wrote in message
news:6D102D59-4421-4EED-A710-F81D9577EDD2@microsoft.com...

KM · Guest

You also may want to issue a reboot after EWF Commit but before the hibernate. Otherwise you will always resume to the image in
"committed state".

KM

Nightman · Guest

Thanks KM.
Unfortunately, most of my possible changes on RAM Reg EWF system were
releated to windows system settings, etc static TCP/IP, computer name,
printers properties ... How can I commit one registry file then?

"KM" wrote:

Slobodan Brcin (eMVP) · Guest

Hi Nightman,

You have tough questions here, but let me give you basics then we can discuss what you must do depending on what you need.

1. EWF here is not your enemy it is your friend. You can't add new files to OS partition not because of EWF but because of content
that is stored in hiberfile and that content will be used during the boot. You can't change that content so as you can see it is a
problem.
2. All config info can be placed by you on unprotected and unmounted FS on second partition.
3. Regarding hibernation file read what Konstantin and Sean have said.

In theory you could update your system without the reboot, and then just do one reboot so your system apply this changes.

This would go something like this.
1. You have deployed few clients with same HORM content on disk.
2. You of course have a master XPe.
3. You do update of XPe image as suggested by Konstantin in you lab.
4. You access this disk offline with your application that will do following.

Prepare application:
- It should log all OS partition sector differences between new master disk and disk that is used on clients. (But you can exclude
unallocated sectors by FS to save some size).
- Additionally you should mark sectors that do not belong to hibrfile. (I mean you should save hiber file changes, also you should
figure out format of hibr file so you don't save full length of it just needed content)

Update application that will be executed on clients:
- Now we need to trick EWF and make a file system updates. First you would like to read content of each FS sector that we need to
update, and then write it back. This will force RAM EWF to cache this content in memory for successive OS usage.
- With previous step we cleared path for updating FS trough disk access with new sectors. (As long as OS is not rebooted we will use
virtual data from EWF overlay instead of changed data from disk so XPe will be ignorant of change)
- It should read hibr file data from your update file and overwrite the hibrfile on disk trough disk access. (This bypass EWF and
since data is not used during the XPe work it won't crash)
- Reboot computer without committing or hibernating.

Huh, this is it sound simple ?

Regards,
Slobodan

"Nightman" <Nightman@discussions.microsoft.com> wrote in message news:6D102D59-4421-4EED-A710-F81D9577EDD2@microsoft.com...

KM · Guest

Nightman,

I have never tried that but you can give it a try.

--
Regards,
KM, BSquare Corp.

Slobodan Brcin (eMVP) · Guest

Hi Konstantin,

Even if he could commit one registry file or any other file he would then have a integrity problem after resume. (We are still
talking about hibernation in this thread right?)

Regards,
Slobodan

"KM" <konstmor@nospam_yahoo.com> wrote in message news:Ohzdw3C9EHA.3592@TK2MSFTNGP09.phx.gbl...

KM · Guest

Slobodan,

No, I think Nightman has asked about just committing his particular changes but not committing the entire overlay.
At least that was my assumption :-)

I certainly agree that this should not be used with hibernation feature unless the hiberfil.sys file is updated (either by
hibernating after a reboot, or using the procedure outlined in your other post in this thread).

--
Regards,
KM, BSquare Corp.

Sean Liming (eMVP) · Guest

Interesting architectual problem as SUS, SMS, DUA come into play as well
with HORM, but re-hibernation is the only solution that I can see.

Regards,

Sean Liming
Managing Director
SJJ Embedded Micro Solutions

www.sjjmicro.com / www.seanliming.com
Author: Windows XP Embedded Advanced and Windows NT Embedded Step-by-Step

"KM" <konstmor@nospam_yahoo.com> wrote in message
news:uuxzBdD9EHA.2900@TK2MSFTNGP09.phx.gbl...

Slobodan Brcin (eMVP) · Guest

Sean,

What do you think about the way that I have described that would allow update without rehibernation?

Regards,
Slobodan

"Sean Liming (eMVP)" <seanl@seanliming.com.NOSPAM> wrote in message news:uy$fk4F9EHA.1392@tk2msftngp13.phx.gbl...

KM · Guest

I think HORM is not a complete embedded feature but rather just one of good use of hibernation and EWF.
Actually, there is so many interesting things that could be done in embedded space if we were having a way to change some
implementation or extend NT Loader, NT Kernel and EWF. However, none of them expose APIs (except the kernel but as we all know -
very minimum available).

Imagine ntldr extensions. Just pieces of code that ntldr calls in to (jumps to) on certain operations (before, during, after). That
could be some little programs (real/protected mode) under the root that, if found, are called from ntldr. E.g., instead of just
searching and checking resmany.dat (btw, has anybody confirmed this is working with XPe SP2?) the ntldr could load it up and jump to
a particular instruction by a specified offset. If this was well documented that could open many possibilities for extending XPe OS
features including the HORM.

The same store for EWF.sys, or some MS apps like SUS (WU Client), etc. If SUS client provided a way to call in a plug-in Dll, the
integration with EWF would be easier.

When it comes to considering XPe as a true embedded OS, it stumbles over the fact that XPe based on XP Pro binaries and XPe system
components cannot (or, better say, hard and time consuming to) be changed to meet some embedded needs.

--
Regards,
Konstantin

RAM Reg EWF with hibernation questions Goto page 1, 2 Next

	WinXPTalk.com Forum Index -> Embedded System	All times are GMT Goto page 1, 2 Next
Page 1 of 2