Re: Prevent command prompt from popping up at system startup

Jure,

Milong has already replied to your post and I have almost nothing to add.

FBFW can indeed be useful to you if you can figure out all the data files that are used/created/modified by the applications you
mentioned (3 apps if I understood you correctly - thin custom shell, .Net app and Nobeltec Admiral). I imagine, since you got the
sources, first two apps are going to be easy to componentize properly and use with FBFW. The last app though can be a bit tricky but
with the right tools in hands (FileMon, DiskMon, Dependency Walker) it is still possible to find out all the files that get changed.
If the app is well written, it is going to minimize disk operations (unless it is required by the functionality) and narrow it to
files under one/a few directories. So with the FBFW you can make sure to unprotect those directories or commit only when needed.
Also, registry hives are probably going to be a target for FBFW as well.

EWF live commit may also be an option for you but please keep in mind all the restrictions applied to the files to be committed - no
change in location on the disk, no change in size, etc. Btw, I was under impression you're using EWF RAM mode, aren't you?
Otherwise, if you use CF as the storage for disk overlay, you are not really protecting the flash.

If you do all the above you can really minimize the overlay size and, more important, have it estimated by calculating the size of
the blocks on the disk occupied by the files.

--
=========
Regards,
KM

Hi,

sorry for the delay.

KM wrote:
Jure,

I think 1G RAM is way enough to cover any XPe system that is properly setup - caches are off, Indexing service and
defragmentation
are off, etc. Without providing users to explorer shell functionally and limiting user ability to mess with the disk under your
custom shell app, you should be pretty safe from the overlay size standpoint.
Also, what helps is minimizing the footprint of your image. Having less software added to the OS is obviously minimizing number
of
potential components that may be modifying disk clusters on XP.

Although what's not very clear to me is:
- Why do you have such a big CF (4G?) for an image with such limited functionality?

Actually only 1,5GB of CF is used at present. We have chosen a 4GB CF
because we didn't know know much the final system will be large (and it
wasn't feasable to buy a 2GB CF and then find out it's too small).
Maybe it's better if I explain a little bit more in detail. The custom
application is actually only an entry point to 2 other applications on
the system. One of them is a custom app (written in .Net, not heavy on
writes), the other one is Nobeltec Admiral (www.nobeltec.com). If you
look at the specs of the last one, you'll see that it requires quite a
powerfull machine to operate properly. As far I tested it, it seems it
doesn't perform much writes - mainly it performs reads (charts
data....). So the image has a "limited" functionality, but the
applications that run on it are quite large, so that's the reason of
the (over)sized CF.

Are you writing (or planning on) lots of stuff to the disk from your custom shell app? Maybe some databases used, etc.?

No. The custom app actually performs some writes (to record and
reproduce the chart of some system's parameters through time), but that
writes should be localized to a small ammount of data.

The same goes for RAM - why have some much RAM available? If there are heavy apps running at run time there may be more
that we assume here that may fill up the overlay buffers quickly.

Explained before.


- Why do you need to use the easiest solution for the committing changes in overlay - launching the ewfmgr commit at the
boot time - if your image is custom shell based and user can do only limited things there?
There must be some other holes in the system you are not telling us that may be affecting the disk access. If so, it
would be hard to estimate how big the EWF overlay can be.
If not, why not commit the changes when end user makes some modifications using your custom app (or, better, commit
only
the required changes with FBWF or EWF).

Wow. I didn't even know FBFW existed. I quickly read through the
documentation on MSDN and what most caught my attention was the fact
that you can perform live commits (with EWF i think you can do that
only in EWF RAM mode). So, you suggest to use FBFW instead of EWF to
periodically commit the overly and avoid the problem of filling up the
RAM? That seems a very good idea to me, I only have to see what FBFW is
all about and how to set it up.



After all, you can always force your device to reboot on a scheduled basis to make sure to "clean up" the EWF overlay. Say, you
reboot it every week and you know that overlay doesn't grow more than 1G within a week.

I'm afraid that can't be done, because users will interract with the
system and it isn't very user friendly to reboot the system when they
are using it.

You should feel the real time range after an
extensive system testing.

Another approach that sometimes is useful and less risky than EWF RAM is in using RAM disk for storing most of heavy system
settings
that don't have to be persistent. This is of course assuming you can define what settings you want to be persistent and what not.
E.g., if you use IE (not using Explorer shell doesn't mean you don't use WinInet calls from within your apps) it may sometimes be
a
smart decision to move IE Cache to the ram disk storage that will be wipe out all the session stored data on reboot. The
advantage
of the RAM disk approach vs EWF RAM is that you can limit the RAM disk size (how you handle not enough disk space situation in
your
apps is up to you) while with the current EWF implementation there is no way to limit the overlay size.

--
=========
Regards,
KM



Thanks,
Jure



.

Relevant Pages

  • Re: Prevent command prompt from popping up at system startup
    ... -You want to run ewfmgr -commit to commit the data files to disk. ... This won't use up your RAM overlay. ... would be hard to estimate how big the EWF overlay can be. ... you can always force your device to reboot on a scheduled ...
    (microsoft.public.windowsxp.embedded)
  • Re: Why is HORM restricted to EWF-RAM??
    ... The major reason for using EWF RAM for HORM scenario was that the changes you do while you work with the image that are redirected ... With EWF Disk the changes are redirected to Disk overlay and EWF will pick them up at the ... HORM is enabled. ...
    (microsoft.public.windowsxp.embedded)
  • Re: EWF in SP2 Not Working
    ... The purpose of the MSDN article is to circumvent the need for a separate EWF ... and to have EWF configured for RAM Reg operation when it finishes ... REG 'Incorrect Function' issue" for more information. ... There are no specific drivers for my Disk Drive type - ...
    (microsoft.public.windowsxp.embedded)
  • Re: Application in RAM, CF writeprotected
    ... It supports RAM Overlay and Disk Overlays, you're looking for EWF RAM ...
    (microsoft.public.windowsxp.embedded)
  • Re: IRQL_NOT_LESS_OR_EQUAL and EWF
    ... i don't recall anything on BSOD. ... not EWF required. ... the OS to write to disk: http://msdn.microsoft.com/library/en-us/xpehelp/html/xeconElToritoCDAsDisk.asp. ... created by TD to the sdi file. ...
    (microsoft.public.windowsxp.embedded)
Loading