Question About "autoexec.nt" and "config.nt" (in Vista)

[bjackson445]

We are creating an installer for our application which we of course
anticipate will be installed under Vista (more and more as Vista
becomes more commonly used). One thing this installer does is set the
attributes of the files "autotexec.nt" and "config.nt" to READ-ONLY
(BTW, in Vista, these files are located in C:\WINDOWS\SYSTEM32).
There is something peculiar about our app which is why, under XP, we
had the installer "protect" these files by setting them to READ-ONLY.
My question is, does anyone see any problem in setting these same
files to READ-ONLY under Windows Vista? We had no customer complaints
after thousands of installations under XP. But maybe Vista, at some
point, changes these files (ie. "autotexec.nt" and "config.nt") for
whatever reason and, if we set them to READ-ONLY, Vista wouldn't be
able to change them.
Thanks for any insight.

 

[Guest]

We are creating an installer for our application which we of course
anticipate will be installed under Vista (more and more as Vista
becomes more commonly used). One thing this installer does is set the
attributes of the files "autotexec.nt" and "config.nt" to READ-ONLY
(BTW, in Vista, these files are located in C:\WINDOWS\SYSTEM32).
There is something peculiar about our app which is why, under XP, we
had the installer "protect" these files by setting them to READ-ONLY.
My question is, does anyone see any problem in setting these same
files to READ-ONLY under Windows Vista? We had no customer complaints
after thousands of installations under XP. But maybe Vista, at some
point, changes these files (ie. "autotexec.nt" and "config.nt") for
whatever reason and, if we set them to READ-ONLY, Vista wouldn't be
able to change them.

1. Modifying system files, particularly in a way that might break the
operating system in unexpected ways is _a really bad idea!_ You may want to
rethink that plan altogether.

2. Is your application a 16-bit application? If not, those files have
absolutely no impact on it at all. They are only used to initialize the
16-bit WOW subsystem.

3. If your app is a 16-bit application it won't run at all on Vista 64-bit
as that OS has no 16-bit subsystem. You may want to note that before people
buy the app.

4. If your app is actually a 16-bit application and it needs to rely on the
autoexec.nt and config.nt files to be formatted a particular way to work
properly you would be a whole lot better off by using a .pif file that
overrides those files instead.

 

[bjackson445]

1. Modifying system files, particularly in a way that might break the
operating system in unexpected ways is _a really bad idea!_ You may want to
rethink that plan altogether.

2. Is your application a 16-bit application? If not, those files have
absolutely no impact on it at all. They are only used to initialize the
16-bit WOW subsystem.

3. If your app is a 16-bit application it won't run at all on Vista 64-bit
as that OS has no 16-bit subsystem. You may want to note that before people
buy the app.

4. If your app is actually a 16-bit application and it needs to rely on the
autoexec.nt and config.nt files to be formatted a particular way to work
properly you would be a whole lot better off by using a .pif file that
overrides those files instead.

Yes, this particular app is a 16-bit app. Our installer doesn't
modify "autotexec.nt" and "config.nt" at all, it only makes them Read-
Only.
We had no problems reported by customers who were using XP (ie.
regarding our installer making "autotexec.nt" and "config.nt" Read-
Only) and I'm wondering if it will be as safe under Vista?
Thanks.

 

[Jimmy Brush]

These files are read-only to users by default. Only administrative programs
can modify them.


--
- JB
Microsoft MVP - Windows Shell/User

Windows Vista Support Faq
http://www.jimmah.com/vista/

 

[Guest]

These files are read-only to users by default. Only administrative programs

can modify them.

Modifying the contents of these files is fine. Modifying the behavior of
them is not a good plan. The fact that nobody has reported problems is most
likely due to the fact that your app is the only 16-bit app these users have,
so you are saved by writing to a 15-year old model. That said, I think you
should update the app to 32-bits, or better yet, both 32 and 64\. You will
lose a significant portion of the market otherwise as 64-bit Vista does not
have a 16-bit subsystem.

 

[bjackson445]

Modifying the contents of these files is fine. Modifying the behavior of
them is not a good plan. The fact that nobody has reported problems is most
likely due to the fact that your app is the only 16-bit app these users have,
so you are saved by writing to a 15-year old model. That said, I think you
should update the app to 32-bits, or better yet, both 32 and 64\. You will
lose a significant portion of the market otherwise as 64-bit Vista does not
have a 16-bit subsystem.

We don't modify these file's behavior nor their contents; we only make
them Read-Only.
We have to support several thousand users who are still using some
legacy-ware that we have no control over.
By the way, I checked the properties of "autoexec.nt" and "config.nt"
in Vista and it shows the owner of these files as "SYSTEM". Also,
even though we set the attribute of both files to Read-Only, "SYSTEM"
still has full modifying priviledges according to Vista's properties
for these files.

 

[Guest]

We don't modify these file's behavior nor their contents; we only make

them Read-Only.

Making them read only IS modifying their behavior.

We have to support several thousand users who are still using some
legacy-ware that we have no control over.

I know all about legacy support. It bites.

By the way, I checked the properties of "autoexec.nt" and "config.nt"
in Vista and it shows the owner of these files as "SYSTEM". Also,
even though we set the attribute of both files to Read-Only, "SYSTEM"
still has full modifying priviledges according to Vista's properties
for these files.

I'm not saying that it will be a problem. I am saying you don't know whether
it will be a problem, and if it becomes a problem for anyone, they won't
necessarily even be able to trace it to you. You could very well have blown
up hundreds or thousands of boxes and never even have heard of it. Or, you
could have had no problems at all. There is no way to tell. That is why PIF
files were invented, many years ago, to allow applications to provide their
own context for the WOW sub-system without stomping on other applications.