Prevent command prompt from popping up at system startup

[Jure]

[I already posted this question, but there was an error when submitted,
so i hope it won't appear twice.]

Hi,

maybe this isn't the right newsgroup to ask this question, but since
it's related to XP embedded, I'll try.

I'm trying to achieve the following: every time the system (XP
Embedded) boots up, i'd like to call commit on EWF. Now i did that by
setting a registry key in
HKLM\Software\Microsoft\Windows\CurrentVersion\Run with the following
value: "C:\Windows\System32\ewfmgr.exe c: -commit". The problem is that
when the system boots up, the command prompt appears on the desktop for
a moment (like if you executed this command from the Run menu) and this
is undesired. Is it somehow possible to suppress it, or at least run it
minimized?

Thanks in advance for any answers,
Jure

 

[KM]

Jure,

ewfmgr is a console app and that explains why you are seeing the blank window blinking quickly at the boot.

The best way to fix this would probably be writing your own simple and little app that will call in to the EWF API to commit the
overlay. You can make your app small and non-console so that it starts very fast and no GUI seen.

 

[Jure]

Thanks for your answer.

Is this the only approach? I'm asking that because maybe I'll have to
modify the command to execute and at that time I'll not be able to
recompile my app. Ok, it might be possible to supply the arguments in
e.g. a text file, but is there maybe an easier way to achieve that?
Someday I'll maybe have to call another console app in the same way,
and it isn't very practical to write a custom app for every such need.

Thanks

 

[KM]

Jure,

Honestly, I couldn't quite understand how launching a console app problem is
really connected to EWF. What I suggested earlier was creating a simple app
that calls into the EWF API [commit]. Obviously, this app wouldn't care
about any other console app(s) you might need to launch at run time but it
would do the commit function you need.

Any console app you can launch with ShellExecute[Ex] call providing the
SW_HIDE parametr as the nShowCmd argument (please refer to MSDN for more
info). It should hide the app implicit console window on start (won't work
for extra console windows that may be created by the app explicetely by
colling console alloc API).

KM

Thanks for your answer.

Is this the only approach? I'm asking that because maybe I'll have to
modify the command to execute and at that time I'll not be able to
recompile my app. Ok, it might be possible to supply the arguments in
e.g. a text file, but is there maybe an easier way to achieve that?
Someday I'll maybe have to call another console app in the same way,
and it isn't very practical to write a custom app for every such need.

Thanks

 

[Jure]

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

Jure

 

[steves]

I'm curious - Why do you want to do this?

If you commit EWF at every boot, you are committing - nothing really.
The system has just been restarted, and no-one has had time to make any
changes, so.... what are you committing?

Maybe you really don't need the EWF if you are committing it all the
time anyhow?


SteveS
StevesATeyeDASHimagingDOTcom

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

Jure

Jure,

Honestly, I couldn't quite understand how launching a console app problem is
really connected to EWF. What I suggested earlier was creating a simple app
that calls into the EWF API [commit]. Obviously, this app wouldn't care
about any other console app(s) you might need to launch at run time but it
would do the commit function you need.

Any console app you can launch with ShellExecute[Ex] call providing the
SW_HIDE parametr as the nShowCmd argument (please refer to MSDN for more
info). It should hide the app implicit console window on start (won't work
for extra console windows that may be created by the app explicetely by
colling console alloc API).

KM

 

[KM]

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

I'm curious - Why do you want to do this?

If you commit EWF at every boot, you are committing - nothing really.
The system has just been restarted, and no-one has had time to make any
changes, so.... what are you committing?

Maybe you really don't need the EWF if you are committing it all the
time anyhow?


SteveS
StevesATeyeDASHimagingDOTcom

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

Jure

Jure,

Honestly, I couldn't quite understand how launching a console app problem is
really connected to EWF. What I suggested earlier was creating a simple app
that calls into the EWF API [commit]. Obviously, this app wouldn't care
about any other console app(s) you might need to launch at run time but it
would do the commit function you need.

Any console app you can launch with ShellExecute[Ex] call providing the
SW_HIDE parametr as the nShowCmd argument (please refer to MSDN for more
info). It should hide the app implicit console window on start (won't work
for extra console windows that may be created by the app explicetely by
colling console alloc API).

KM

 

[Jure]

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]

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.

 

[Jure]

Hi,

sorry for the delay.

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.

Thanks,
Jure

 

[Milong Sabandith [MSFT]]

Jure,
It looks like you have these requirements.

1 Protect CF card from writes.

2 Flush Cache periodically
-Reading your scenario you are rebooting the machine.
-The rebooting actually is freeing up your cache since you are using RAM
mode.

3 Enable some writes to data files.
-You want to run ewfmgr -commit to commit the data files to disk.

A possible solution is to use FBWF. You'll still need to reboot the machine
to clear the cache but i think you'll have to do it infrequently. The reason
is you can list your data files in a write-through list which allows the
files to be written directly to disk. This won't use up your RAM overlay.

-milong

 

[KM]

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.

 

[Jure]

I think i misunderstood the features of FBWF. I thought that with
selective commits, it was possible to commit the overlay *during*
system operation and not on reboots. That way I could protect the CF
from repetitive writes to the same location/file and flush the overlay
e.g. only every hour. I implied that by reading the following:
http://msdn2.microsoft.com/en-us/library/aa940862.aspx ("Selective
Commit is immediate and persists through reboots")

So, if I understand correctly (from the your posts and the
documentation):
1) with Selective commits, you commit only the files you want, but this
occours only at system reboot,
2) with Selective write through you can bypass the overlay and write
directly to the CF.

And the whole idea is to make a list of files which are possibly
changed by the running applications and put it in the FBWF's
write-through list. That way the RAM overlay wouldn't be filled up,
since all writes would be done directly to the CF. And additionally, if
any changes are made to any files not listed in the write-through list
(i.e. they are in the overlay), it could be still possible to commit
them at reboot.

Do I understand correctly?

But if that's how things are (no commit possible during system
operation to free the overlay and writing some most accessed and
modified files directly to the CF), I don't see how the lifetime of the
CF is protected? The only advantage I see is that the files which are
not listed in the write-through list don't get modified, if you don't
perform a commit among two reboots.

Sorry if I completely missed the point of FBWF, but I understood it
that way.

@KM:

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.

I didn't know of those restrictions.

Btw, I was under impression you're using EWF RAM mode, aren't you?

Yes, I'm using RAM Reg mode. But still, if I understand right what's
stated here http://msdn2.microsoft.com/en-us/library/ms940853.aspx, you
can do "ewfmgr c: -commitanddisable -live" which commits the data to
the CF without the need to reboot the system, but then the overlay
remains disabled (and the CF unprotected) from that point in time. Am
I wrong?


Thanks for your patience and help,
Jure

 

[Sean Liming \(eMVP\)]

On your point 1 below. FBWF does Selective commits immediately. EWF does a
commit on a reboot.

The operating system areas that are constantly read & writen to are
protected by FBWF's RAM overlay. i.e. the registry files. How frequent your
application writes to the flash will also be a factor, but you have some
control.

Regards,

Sean Liming
www.sjjmicro.com / www.seanliming.com
XP Embedded Book Author - XP Embedded Advanced, XP Embedded
SupplementalToolkit

 

[Milong Sabandith [MS]]

I just want to add that FBWF does selective file commits. When EWF commits,
it commits everything in the overlay.

So with FBWF, you'll need to decide whether you want to do selective file
commits or use the write-through list. If there are many writes to the file
and you want to commit at the end, the using the selective file commit makes
sense.

-milong

 

[KM]

Jure,

1) No, selective commit is instantaneous and synchronous. Basically you will get a return code from the FbwfCommitFile API on
whether the commit was successful or not. Note that the commit doesn't stop protection for the specified file. Read it more here:
http://msdn2.microsoft.com/en-us/library/aa940894.aspx

Basically you can do the commits to the selected number of data files on controlled basis. E.g., you can "flush" the overlay when an
important application operation was performed or on a timer basis. The same applies to the registry hive files. In any case this
will prolong your CF lifetime.

2) Yup

Or you can certainly use write-through list but then you should analyze how often writes are being done to selected files. You may
wear out flash blocks occupied by those files quickly.




Another good thing about FBWF is that you can set the maximum size of the overlay. This can protect you from the memory overload by
the growing overlay. This can be accomplished by setting a reg.setting (setting on FBWF page in TD) or at run time with
FbwfSetCacheThreshold: http://msdn2.microsoft.com/en-us/library/aa940913.aspx

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

I think i misunderstood the features of FBWF. I thought that with
selective commits, it was possible to commit the overlay *during*
system operation and not on reboots. That way I could protect the CF
from repetitive writes to the same location/file and flush the overlay
e.g. only every hour. I implied that by reading the following:
http://msdn2.microsoft.com/en-us/library/aa940862.aspx ("Selective
Commit is immediate and persists through reboots")

So, if I understand correctly (from the your posts and the
documentation):
1) with Selective commits, you commit only the files you want, but this
occours only at system reboot,
2) with Selective write through you can bypass the overlay and write
directly to the CF.

And the whole idea is to make a list of files which are possibly
changed by the running applications and put it in the FBWF's
write-through list. That way the RAM overlay wouldn't be filled up,
since all writes would be done directly to the CF. And additionally, if
any changes are made to any files not listed in the write-through list
(i.e. they are in the overlay), it could be still possible to commit
them at reboot.

Do I understand correctly?

But if that's how things are (no commit possible during system
operation to free the overlay and writing some most accessed and
modified files directly to the CF), I don't see how the lifetime of the
CF is protected? The only advantage I see is that the files which are
not listed in the write-through list don't get modified, if you don't
perform a commit among two reboots.

Sorry if I completely missed the point of FBWF, but I understood it
that way.

@KM:

I didn't know of those restrictions.


Yes, I'm using RAM Reg mode. But still, if I understand right what's
stated here http://msdn2.microsoft.com/en-us/library/ms940853.aspx, you
can do "ewfmgr c: -commitanddisable -live" which commits the data to
the CF without the need to reboot the system, but then the overlay
remains disabled (and the CF unprotected) from that point in time. Am
I wrong?

You are correct here and this is why FBWF is often a much better option

 

[Jure]

Hi,

thanks very much to all of you for your answers, you helped me a lot!

So, FBWF can do commits during system operation. At first I also
understood it that way, but what confused me was Milong's post, where
he said:
"A possible solution is to use FBWF. You'll still need to reboot the
machine
to clear the cache but i think you'll have to do it infrequently. The
reason
is you can list your data files in a write-through list which allows
the
files to be written directly to disk. This won't use up your RAM
overlay."

The scentence "You'll still need to reboot the machine to clear the
cache" confused me a little bit. Actually I still don't understand it
completely. Why should the machine be rebooted, if it's possible to
commit the overlay at runtime? Maybe one of the reasons would be to
discard unwanted/unnecessary changes and have the cache emptied - e.g.
because of many small writes the OS or an application makes to
different files, which do not need to be made persistent and the only
way to free that part of the overlay is to reboot....

Jure

 

[KM]

Jure,

The scentence "You'll still need to reboot the machine to clear the
cache" confused me a little bit. Actually I still don't understand it
completely. Why should the machine be rebooted, if it's possible to
commit the overlay at runtime? Maybe one of the reasons would be to
discard unwanted/unnecessary changes and have the cache emptied - e.g.
because of many small writes the OS or an application makes to
different files, which do not need to be made persistent and the only
way to free that part of the overlay is to reboot....

You answered your question yourself You need reboot to discard the changes end users might be doing at run time but you don't
really need them to be persistent.

Actually it would be really useful API (or command for the manager) if FBWF (and EWF) supported "clear cache on the fly"
functionality. I think we have made this request with regards to EWF in this NG long time ago but perhaps there are some
complications through the code that prevent it from being implemented.

 

[Jure]

Thanks KM, you solved my last doubt about FBWF operation. Now it's all
clear.

Regards,
Jure