Re: Prevent command prompt from popping up at system startup

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: some EWF RAM questions
    ... and I'm worried about losing the PF benefits and losing RAM ... I use EWF with RAM overlay. ...
    (microsoft.public.windowsxp.embedded)
  • Re: 21A error during boot
    ... A RAM overlay does not store any writes to the EWF partition (it ...
    (microsoft.public.windowsxp.embedded)
  • Re: some EWF RAM questions
    ... RDP/ICA connections as a time (using published applications, ... and I'm worried about losing the PF benefits and losing RAM ... I use EWF with RAM overlay. ...
    (microsoft.public.windowsxp.embedded)
  • Re: Disabling EWF?
    ... You have overlay of changed data that is contained in RAM. ... With commit option pending during the graceful reboot EWF will save all changes to disk volume. ...
    (microsoft.public.windowsxp.embedded)
  • Re: Registry-based RAM EWF questions
    ... The one-reboot process is correct for RAM Reg configurations because FBA ... skips the step where EWF would normally create its special partition. ... an overlay partition, so there is no need for it to create this partition. ...
    (microsoft.public.windowsxp.embedded)