ways to avoid EWF

[Dick Dawson]

I'm following up on a question I asked last week. I will be running a
system with CF in which I can eliminate any need for my applications to
write to disk except for very occasionally needing to update a DLL and
possibly a couple of .exe files (this won't happen more than several times a
year). There will be no browser, no display and keyboard, etc. so I don't
clearly see that any temp files, MRU file lists, etc. will be updated. I
will have a small swap file only for the purpose of enabling performance
statistics. I suppose the system may update some event logs at boot time
but the systems will run 24x7 as long as possible without being rebooted. I
don't know whether system facilities such as pipes and sockets may write to
the disk in some way or whether the OS routinely writes to the registry.
Under these circumstances, do I need EWF to protect my CF or can I assume
that writes will be so infrequent that EWF protection is not needed? EWF
presents a problem that I explained previously in that the most likely way
that these systems will stop will be because of an ungraceful shutdown and
in that case the very occasional changes I do make will be lost.

A different theoretical architecture for my system would be to run out of
ramdisk that is loaded from the contents of CF. Is such an architecture
supported or possible? In this scenario I would still need to do occasional
writes to the CF.

DD

 

[Guest]

I would not assume that writes the flash would be infrequent, running without
EWF is probably a bad idea.

But, for this bit..

EWF
presents a problem that I explained previously in that the most likely way
that these systems will stop will be because of an ungraceful shutdown and
in that case the very occasional changes I do make will be lost.

I suggest looking at EwfMgrCommitFile
http://msdn.microsoft.com/library/d.../en-us/xpehelp/html/xelrfewfmgrcommitfile.asp

With this it is possible to commit changes to a file to the flash without
doing a shutdown.

There are a few limitations, the file must have already existed on the
flash, and must not have changed size or name etc...

But even with these limits, this is an incredibly useful function for a
device which needs to store data, and may not be (or never is) shutdown
properly.

 

[Dick Dawson]

My need is to update a few executable files, both DLL and EXE. If I pad
these files to a length greater than their natural length so that an update
could fit into the same file size as the previous version would that create
a problem? Is any OS function that loads programs and DLLs going to be
upset by such padding?

Note that I did a little experiment on a small program that was 28672 bytes
in size. I appended 32K of zero bytes to this EXE to produce a file size of
61440 bytes. The program performed its functions correctly both before and
after. So I have some indication this method will work but it would be
comforting to have stronger assurances.

DD

 

[Guest]

What I did in for this, I have a couple of exe's that need to be updated on
the fly...
I keep these in a larger file, which is fixed in size (with plenty of spare
space).
The custom shell then extracts these files to the 'flash' (effectivly ram)
on startup to execute them.
I can then update the files in the fixed size file on flash without worrying
that the size is going to change. (it also means that I don't have to worry
about trying to overwrite files currently in use by the OS...)

This ofc only works if you know what files are going to be updated.

 

[Raymond Cruz]

Stormblade,
I am interested in this technique but I don't know enough about XPe to
understand what "The custom shell then extracts these files to the 'flash'
(effectivly ram) on startup to execute them" means. Can you provide more
detail?

RC

 

[Guest]

Sounds like a traditional "unzip" or similar extract operation. But since EWF
is used, the output files will not be commited to actual flash, but only
reside in RAM.

/ Hannes.