Re: Prevent command prompt from popping up at system startup

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?
Are you writing (or planning on) lots of stuff to the disk from your custom shell app? Maybe some databases used, etc.?
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.

- 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).


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. 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


That's right. I call commit on boot time because actually it doesn't
matter when you issue this command, as long as it's done before the
system reboots, of course. And the boot time seemed the easiest
solution to me.

I'll also explain why I use such an approach, maybe anyone of you has a
better suggestion how to do that and I'll be gratefull for any help.
I'm using RAM Reg mode to protect the lifetime of the CompactFlash
where the system runs. The CompactFlash is 4GB in size, whereas the
system RAM is "only" 1GB, so it could be possible to fill up the whole
RAM. But since the user will be limited in its actions, that should
never occour. With that I mean that the system will boot in a custom
shell which is an application which allows only certain actions. To
tell the truth, I haven't tested the system in a long run yet, i.e.
running for a week, but I'll do it as soon as I have the chance.

I also thought of the possibility of filling up the RAM which would
lead to a system crash, but is there any other approach to protect the
CF? Maybe to commit the overly when the system runs, but as I know
that's impossible....

Regards,
Jure


KM wrote:
My guess is...

The actual commit is going to be done on graceful shutdown/reboot.
The storage is still protected (calls are redirected to the EWF overlay). So if sudden power loss occurs, it won't break the
system.

And all the changes user makes are persistent. Sometime it may be required by a system specs.

However, there is still a risk factor in such approach. If RAM overlay used, user changes, if not controlled, may easy and
quickly
increase the overlay size before the current session ends (reboot). The overlay will grow unlimitedly until it eats up all the
memory. Only cure (without being able to limit EWF overlay size) is to control what users can do at run time - lock the OS,
shell,
turn off all possible OS, IE and app caches, disable background disk processes like defragmentator, etc.

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

Jure wrote:
Thanks for your help. I'll do what you suggested.



.

Relevant Pages

  • Re: Multi-user access of an Embedded Windows System ?
    ... to decide whether you want them to be directed to RAM (RAM/RAM Reg Overlay) ... scenario so long as you don't exceed your system's RAM or disk space. ... > Is there some other product that behaves more like Windows Terminal Server ...
    (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: Deploy XPe to multiple targets (using SDI and EWF)
    ... I wanted EWF that will support simultaneous RAM and Disk Overlay, so I can use read-only medium for boot and then move OS updates to ... RAM overlay would allow me stateless operation as usual. ... You case sound similar to what I want but you instead of RAM EWF want to use SDI RAM disk for OS, ...
    (microsoft.public.windowsxp.embedded)
  • Re: Prevent command prompt from popping up at system startup
    ... I call commit on boot time because actually it doesn't ... I'm using RAM Reg mode to protect the lifetime of the CompactFlash ... Maybe to commit the overly when the system runs, ... The storage is still protected (calls are redirected to the EWF overlay). ...
    (microsoft.public.windowsxp.embedded)
  • Re: EWF Custom Shell no installer -> updating the shell in the field
    ... using RAM overlay anyway. ... But if I create a bootable disk with a custom installer shell. ... I am not quite sure yet if we will use disk or RAM EWF. ...
    (microsoft.public.windowsxp.embedded)
Loading