Improve company productivity with a Business Account.Sign Up


Boot Windows98, hide desktop, launch application?

Posted on 2000-03-23
Medium Priority
Last Modified: 2010-04-02
Does anyone know a way, or can anyone refer me to information on how to boot Windows98 to directly enter my GUI application, completely hiding the desktop from ever being seen?
Question by:tdubroff
  • 4
  • 3

Accepted Solution

feenix earned 400 total points
ID: 2650799
Just edit the system.ini file. In the boot-section there is a key called shell. Normally it contains explorer.exe, but you can change it to run your own program.

I've used this in a few programs, so it works perfectly.

Author Comment

ID: 2651831
Feenix, I did a quick test with winword.exe.  Figured that it would load right into Word, but instead it said there was an error and that I should reinstall Windows!  I'll do another test tomorrow with my executable, but do you know the reason this is happening?

Expert Comment

ID: 2652454
I haven't gotten that kind of an error ever. Did you remember to put the whole path to the ini file? E.g. C:\dir\program.exe? Otherwise it won't work and it might give you that kind of an error.
Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.


Author Comment

ID: 2653253
I put the whole path in.  I'll test with a new executable shortly.

Author Comment

ID: 2653971

I used an MFC-based app with MFC dlls statically linked and it worked fine.  

I've also added an _onexit function that logs the user off when the app is closed.  However, what I'd really like to do is allow an admin to get to the desktop on app exit, but anybody else gets logged off.

Can you offer more help?

Expert Comment

ID: 2654182
As far as I know, the desktop cannot be started from a program, so if you set the shell to your own program, you have to change the value and boot to get the normal desktop back.

Author Comment

ID: 2678068
I figured I'd post this here as well, so that if people use the search engine they'd get an update.  Also, thanks for your help feenix and hopefully this will also help you.

"Boot Windows into your own application first, then goto desktop"

I recently inherited a project in which a PC running Windows98 executes
an application which controls various hardware components in a system.
This system, including the controlling PC, is delivered directly to end
users.  The PC exists only to run the controller application and house
a database that stores information on how the system is used.  End users
need not - and should not - have access to the database, file system, or
anything which may affect the way the PC is to be used in the system.

When I inherited the project, a shortcut to the controller application was
placed in the Startup folder.  So after Windows loaded the desktop and
explorer (start button, desktop icons, etc visible) the controller
application started.  The problem with this is that end users may still
access the PC normally by simply clicking on the start button and then
gaining access to anything in the computer.

To provide a better modicum of protection to the PC's file contents, I
made the PC boot directly into the controller application, skipping
the usual Windows Shell (no start button, no system tray, no desktop icons,
no executables visible in the Task Manager).  I also edited the application
so that when the end user quit from the application the PC was shutdown.  
However, when a maintainer quits from the application the familiar Windows
desktop is loaded.

I pieced together how to do all this from as
well as Dino Espisito's book, 'Programming the Windows Shell'.  Both
items are great resources for the person starting to learn how to
program in/with Windows.  I realize the solution presented is not perfect;
any computer-savvy end user could easily bypass the controller application
if they really wanted to.  So, if you have information which would improve
on the security setup, please email me at

Several people on experts-exchange suggested editing the system.ini
file to boot directly into the controller application.  If you replace
shell=explorer.exe with shell=controllerapp.exe then the desired effect
is gained; Windows will boot directly into the application without the
start button, system tray, or any desktop icons visible.  The problem with
this method is that it does not allow for the loading of the normal desktop
if a maintainer is using the system.  Even the normal programatic ways of
restarting the Windows shell do not work; simply ShellExecute-ing
explorer.exe and systray.exe only cause a Windows Explorer view to pop up.

Another clue that this is not the right way to do this, is that when a
critical update for Windows (lets say) is downloaded, the user is often
prompted to restart the machine.  Why restart the machine?  Because when
a PC is already booted up and running, several system files have already
been loaded into memory and cannot be changed.  A sharing violation will
occur if the attempt is made to change any of these files.  However, when
a PC is restarted there is a short time period where these system files
are not yet being accessed and software running during this time can go
ahead and modify these files.  It is this time period where the controller
application is executed.

How did I do this?  Well one way appeared to be editing the system.ini
file.  However, I just discussed why this was not feasable.  Also, editing
the system.ini file is surely not the way Microsoft performs critical
updates.  Editing the system.ini file only allows for explorer.exe to
be replaced by a single other piece of software (some other *.exe).  
But it could very well happen, and it often does happen, that multiple
executables need to be run before the Windows Shell really gets into the
swing of things.  So, how to designate that certain software should run
before the normal desktop is loaded?  The solution is to use the Registry.  

Inside HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion exist two subkeys entitled Run and RunOnce.  It turns out that the Windows boot-up process executes any values contained within these keys before or during the Shell bootup.  Under the Run subkey, systray.exe is found.  This is the executable that is responsible for initializing the system tray and
displaying the start button.  Because the controller application needs to
execute before the start button is made visible, I did not place it as a
value inside the Run subkey.

Instead, I used the RunOnce subkey.  In Dino Espisito's book he shows that
during bootup, Windows executes the values inside the RunOnce subkey in an optimal time period just after all the normal Windows services are started but before any registered programs are completed and before the contents of the Run subkey are executed.  The only hickup in using the RunOnce subkey is that after the value is executed, the entry is deleted, thus making the entry run once and only once.  The Run subkey does not have this feature. Any item in the Run subkey will execute everytime Windows is booted up.

So here's where I got a little bit tricky.  I placed the following value
in the RunOnce subkey:

      ControllerApp      "c:\controller\controller.exe"

I then changed the controller application code to set this key every
time an end user closed the controller application.  Also when an end
user closed the application I called the Windows API function ExitWindowsEx() which causes the PC to shutdown.  Shutting down the PC of course prevents it from running any other applications inside RunOnce, or Run for that matter.

Here is a snippet of the code I'm talking about:

      int ControllerApp::ExitInstance()
          if (!g_UserIsMaintainer) {

              // Add the RunOnce registry value for this application
            CString subkey = "Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce";
            CString keyValue1 = "ControllerApp";
            CString keyValue2 = "c:\\controller\\controller.exe";

            HKEY  hKey;
            RegOpenKeyEx(HKEY_LOCAL_MACHINE, subkey, 0, KEY_SET_VALUE, &hKey);
            RegSetValueEx(hKey, keyValue1, 0, REG_SZ, (BYTE*) keyValue2.GetBuffer(0), keyValue2.GetLength()+1);

              // Turn off the PC
          return CWinApp::ExitInstance();

To make very clear, if the user is a maintainer of the system, the controller
application is not reinstatiated under the RunOnce subkey and the PC is not
shutdown (maintainer's must be able to get to the desktop).

Why didn't I just simply replace the controller application in the RunOnce
subkey every time the controller application was started, regardless of end
user or maintainer?  Actually, that's how I started out.  But the infinite loop
I had created showed me the error of my ways.  Windows will execute each item in the RunOnce subkey and then remove that item and continue on to the next item to execute.  My controller application itself kept adding a new value, so when the application finished for a maintainer (no call to ExitWindowsEx()), Windows lo and behold found another value under RunOnce, my app again!

What I have described up until now is perfect if the application is only ever
used by end users.  The PC will boot up finding the controller application
in RunOnce and it will execute it.  When the end user is done with the system, the application will reinstantiate the RunOnce subkey and shutdown the PC.  If on the other hand, a maintainer boots up the PC and quits the application, the RunOnce subkey will not contain the call to the controller application.  

This is bad news.  This means that the next time an end user logs in, the
controller application won't automatically start and furthermore the normal
Windows Shell, start button included, will boot up - waiting for the end
user to presumably wreak havoc or at least put a call into customer support.

The final solution then is to put a helper application under the Run subkey,
which when executed reinstantiates the controller application under the
RunOnce subkey.  Note that if a value already exists under a key it will
simply be replaced, not duplicated.  Therefore the Run key will contain the

      ReinstateController      "c:\controller\reinstate.exe"

So, if a maintainer exits the controller application, Windows will eventually
execute the helper application because it is placed in the Run subkey.
The helper makes sure that the next time the PC is booted the controller
application will start up again.

I hope this helps people in similar circumstances.


Featured Post

Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Unlike C#, C++ doesn't have native support for sealing classes (so they cannot be sub-classed). At the cost of a virtual base class pointer it is possible to implement a pseudo sealing mechanism The trick is to virtually inherit from a base class…
Often, when implementing a feature, you won't know how certain events should be handled at the point where they occur and you'd rather defer to the user of your function or class. For example, a XML parser will extract a tag from the source code, wh…
The viewer will learn how to clear a vector as well as how to detect empty vectors in C++.
The viewer will be introduced to the member functions push_back and pop_back of the vector class. The video will teach the difference between the two as well as how to use each one along with its functionality.

585 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question