For an MVP (Microsoft-Help, Most-Valued Professional Program) professional:

I am having trouble with four non-Microsoft-Corporation computer programs in
a Windows-95 operating system. Three of them are part of the same downloaded
software package. In spite of the fact that Windows 95 is not listed as a
supported operating system for those three programs, it is possible to use
such programs in Windows 95, in the best case with just occasional invalid
page-fault errors on exiting one of the three programs. Simultaneously
pressing the “Ctrl,� “Alt,� and “Delete� keys, then in an ensuing list
clicking on the name of the program to be closed, and finally clicking “End
Task� might have lowered the frequency of that problem. But unfortunately
for at least one of those programs I no longer have the option to reinstall
and reregister it for long-term use, free of charge, which might have
otherwise been a good thing to try to fix the problems in using it. But
before removing such a program and then not being able to use it again free
of charge on the computer in which I had the troubles, I'd like to know if
the problems might really be in Windows-95 system files or not because it
might be that replacing one or more system files might enable one or more of
the troublesome programs to work much better than otherwise. One of the
troubles with at least one of the programs is that “File, Open� and “File,
Save As...� no longer open a File, Open or File, Save As dialog box,
respectively, which I think might in each of these cases be considered a
Common-Control Dialog Box or Common-Controls Dialog Box. On the other hand
“File, Open� does open such a dialog box in Microsoft Corporation's supplied
program WordPad on that same computer; so this evidence makes me lean toward
the troubles being not in Windows 95, but within the non-Microsoft program's
own, present, installation environment.

Question 1. On a Windows-95-loaded hard-disk drive how does one determine,
free of charge, if there are any corrupt system files or not?

Question 2a. In Windows 95's ScanDisk there is a “file-system� check.
Exactly what is done in that?

Question 2b: Is that “file-system� check different from a check for corrupt
system files?

Question 3a. A. On the Internet, for example at
http://www.updatexp.com/scannow-sfc.html, I have read that some
non-Microsoft-Corporation programs can overwrite important, Windows-95 system
files. B. But I have quite a number of times noticed in Windows 95 that in
the course of installing a program or piece of software when an attempt is
made to overwrite a file with a version of it older than the one already on
the hard-disk drive that the human being is asked whether he wants to keep
the existing file on the hard-disk drive or not; and if he clicks “Yes� to
this question, the newer file is, I presume, not replaced with an older
version of it. So it looks like in B there is built-in protection against A
in the case where the system file on the hard-disk drive is newer than the
one being attempted to be written. In a case where a non-Microsoft program
tries to overwrite a system file with a newer version of it than is already
on the hard-disk drive, is there no protection against such a replacement in
Windows 95?

Question 3b. Suppose one has installed all of the Windows-95 updates and
service pack 1 to such an installation that he wants. After that in Windows
95 is there an option to prevent the overwriting of system files?

Question 3c. If so, where can one find it or how does one set such an
option?

Thanks in advance for your help.

Pat

Pat S. <PatS@discussions.microsoft.com> wrote:


A reasonable conclusion. You're right that the dialog boxes are
"common controls". They are implemented in DLL files that all programs
can and do use. It's not easy to guess what would cause program not to
show those boxes anymore. Exactly what does happen in the affected
program when you use the "File|Open..." command?

Umm..I don't think you do.

Examines a file system - identified by a "drive letter" - to find out
whether there are any cross-linked files or abandoned clusters (disk
space that's neither marked as free space nor included in a file).
Tries to fix these things when it finds them.

Very different. To check for corrupt system files, you'd presumably
have to compare the ones in use against known good versions.

I suppose it would depend on the installer that the program uses.

You could make them read-only, that would (I think) make it harder to
overwrite them. Which could backfire when you install an app that
needs a newer version of such a file.

Select the file, right-click, select Properties. Or check out the
"attrib" command-line command.

--
Tim Slattery
MS MVP(DTS)
Slattery_T@bls.gov

Thanks for your prompt reply, Tim! To answer your question in the program in
which "File, Open" does not work right now on my mother's Windows-95-loaded
computer, what currently happens on that computer when I click the "File"
menu and then select "Open" in the drop-down list is very mundane.---An image
of an hourglass appeared along with some rapidly repeating clicking sounds
from that computer. Within a few seconds the hourglass disappeared and the
rapid clicking ended. Then once again I could look at a computer screen
which looked just like it did before selecting "File, Open." So other than
the temporary display of the image of an hourglass, nothing else new and
visible appeared on the computer screen as a result of clicking the "File"
menu and then selecting "Open." Mundane? Yes, but perhaps even this
description might give you a clue as to the invisible things that might have
been taking place in all of that clicking.

Now I get down to the "nitty gritty."

Question 1. How would you exactly define a system file in Windows 95, as a
file which has the extension .sys, as any file in the directory
C:\Windows\system, as any file which has the extension .sys in the directory
C:\Windows\system, as a .dll file in the directory C:\Windows\system, or as
something else?

It appears to me that at least part of the answer as to how to check for
corrupt system files is in your answer to my previous question 2b, namely to
compare the suspect system files against known good ones of the same
corresponding file names.

Question 2a. In detail how would one make such a comparison? With your
probably more complete knowledge and perhaps experience on the subject of
discussion, Tim, you are welcome to add something relevant to or even correct
what I write here in this posting. If a system file includes a Dynamic
Linked Library (DLL) file, I suppose it is a probably a binary file. So
attempting to look inside such a file with, say WordPad would I suppose just
result in a display of strange characters making little direct sense to most
human beings. But there might be other system files, such as .sys files
which would make sense opening them in WordPad. Being an outsider, not an
insider who wrote the code for system files, I suppose one has to compare the
outside-the-file properties, such as the file sizes, dates of their last
modifications, and version numbers. But it seems to me that doing things
this way could become really tricky, for example, in an update to Windows 95
replacing an original system file with a newer and better one.--That process
we should take as a legitimate and leave such a file alone after all of the
updates and service pack 1 for Windows 95 have either been installed or
already included in the Windows-95 with which one starts. But I suppose a
non-Microsoft program could also replace a Windows-95 system file with a
newer version of it. I just guess that that might be acceptable to Windows
95 most of the time, but perhaps sometimes be unacceptable to Windows 95.

This is more thinking than about doing because the "doing" I imagine would
be very time-consuming. So in the scenario I just proposed here is a way I
could imagine tackling the problem of deciding which updated files I should
conservatively accept and which ones to reject. The underlying principle
here is a principle of doubt, that any system file not provided by Microsoft
Corporation is questionable whether it would it work with Windows 95 or not;
so reject it. So following this principle I could imagine first making a
list of system files in the .cab files of an original
Windows-95-operating-system Compact Disc (CD). Then look at a file list for
all of the files installed by the Windows 95 updates I have installed to that
operating system. Take all of those files instead of the files of the same
names in the original Windows-95-operating-system CD; and take all of the
original Windows-95 CD files that have not been replaced. Consider all of
the files in the preceding sentence which remain as a set of good system
files and assume they all work. Make a list of them which includes their
sizes, dates of last modification, and version numbers. Then make a similar
list of the system files presently on the computer where some applications
are not working completely well. Comparing the two lists reject all files
presently on the computer with dates of last modification newer than the
dates for the corresponding files in the good system files list; and replace
them with system files following the procedure in "Replacing a corrupt
Windows-95 system file" on the Web page
http://www.geocities.com/SiliconVall...6013/tips.html.

The weakness I see in the total outline I just mentioned is essentially what
you mentioned, Tim, in not including a newer version of a system file than
Microsoft Corporation produced for Windows 95, but which works well with an
application. Not having access to the source code, it seems surprising that
a person who is not a Microsoft-Corporation employee could produce system
files which in every instance include everything that a
Microsoft-Corporation-produced system file would include. (This seems
somewhat like someone looking at a factory and the products which come out of
it using just his brain to try and figure out everything which takes place
inside that factory to produce those products without ever going inside that
factory or learning from anyone what takes place inside that factory. It
would be hard, wouldn't it?) But I could understand that a non-Microsoft
employee could add function to a file meant to replace a Microsoft system
file that the Microsoft version of that file did not include. Then if an
application depends on that additional function to be there in that replaced
system file, just using the Microsoft system files would prevent that
non-Microsoft application from working completely well. So this sort of
thing gets really hard!

Fortunately I have each of the four applications which don't work well on my
mother's computer also installed on my friend's computer and working better
there in two or three of the four cases. So I could imagine comparing the
files of the sometimes troublesome application on the two computers. Where
there is a difference between corresponding application files in their sizes,
dates of last modification, or version numbers on the two computers then I
could imagine copying the application file on the computer in which the
application is working reasonably well onto the computer in which the
application is not working, if that does not violate any copyright laws.

It is sort of fun to think about how things might be done without actually
doing them. But all of this seems like a mini-research project which could
take lots of time. Perhaps a better approach for my mother's computer could
be to switch to another free program which hopefully works even better in
Windows 95 and provides a good overlap in function with the program I can no
longer reinstall from its company-distributed installation file, reregister
it for free, and then have its use available for people on that computer for
a very long time; fortunately I think there is such a program to which I can
possibly turn.

A proactive approach for my friend's Windows-95-loaded computer, on which
one of the troublesome applications on my mother's computer is working well,
except for occasional invalid page faults on closing that application, could
be for me to back up her hard drive using a free backup program. Then if in
the future the program which is particularly troublesome on my mother's
computer also has great problems on my friend's computer, I could have the
option of restoring her hard drive back to the condition in which troublesome
program worked well. This approach would follow Benjamin Franklin's wise
counsel: "An ounce of prevention is worth a pound of cure." A potential
difficulty I see with this approach is whether the free disk space for
writing the backup of the used portion of that hard drive is sufficient for
writing the backup file(s). The next question is whether one can run the
free program I have in mind to restore the used portion of the hard drive
using the backup file which is stored on that same hard drive. I think
Windows XP's system backup utility can do that sort of thing on a
Windows-XP-loaded hard drive, if there is sufficient free disk space to write
the backup file in the first place. Back to Windows 95, writing the backup
to 3.5-inch diskettes seems very impractical, probably requiring a large
number of such diskettes for the purpose. Also writing the backup onto CDs
is presently probably not possible because for starters there may not be any
Universal Serial Bus (USB) output on that computer through which one could
cable an external CD writer; but Windows 95 OSR2 I suppose would probably
handle the software for a USB port, if there were such a piece of hardware on
a Windows-95-loaded computer.

But also for my friend's Windows-95-loaded computer I could imagine
installing the free application or program I mentioned two paragraphs above
and hopefully be through with the problems of the sometimes troublesome
application in Windows 95, an operating system not supported by the sometimes
troublesome application's distributor. I think this is the easiest solution
for my mother's computer. It also a conceivable option on my friend's
computer as well, especially if in the future there are ever difficulties
similar to those on my mother's computer.

Thanks for what you have done already for me, Tim! Have a good day!

Pat

"Tim Slattery" wrote:

Pat S. <PatS@discussions.microsoft.com> wrote:

Ugh. I don't know what would cause that. It must be finding the common
control DLL, it would complain about a missing DLL otherwise.

Umm...a file used by the operating system? I'd think most everything
in the \Windows directory would qualify, but there are temp files and
IE cache there. There are also things like screensavers and wallpapers
that aren't really necessary to run Windows but are installed with the
OS.

This would involve a huge collection of files running into many
hundred megabytes. I don't think it can be done practically. You could
try reinstalling Win95 over itself, which should replace all the OS
files with new copies from the CD.

Yes,

None at all. DLLs are the result of compiling source code, usually
written in C (C++ wouldn't be a factor in Win95), or sometimes Visual
Basic. Nobody tries to look into the actual DLL, if it needs to be
examined or changed you work with that source code and recompile. OF
course, MS doesn't distribute source code for all those DLLs.

That could be a problem.

They don't. What happens is that an application depends on a newer
version of an MS DLL, and the programmer includes that newer version
in the installation package.

You could start by examining the directories where the app's *.exe
file resides and making sure that everything in there is identical
between the working and non-working installations. Presumably this
program has a *.ini file where it stores user preferences. That will
probably not be the same between any two installations. It's
human-readable, and you may be able to figure out which lines in it
correspond to which program options (depends on how devious the
programmer was).
That might indeed be the best course to take.

I think some backup programs can do that. I don't know which one
you're thinking of and I don't know much about any of them anyway.

I think
Yup. And floppies aren't the most reliable storage medium in the first
place.

Win95b has rudimentary USB support. It's not terribly likely that
you'd be able to get a USB CD drive to work with Win95b.

--
Tim Slattery
MS MVP(DTS)
Slattery_T@bls.gov

<snip>

how about putting another small HD in and use it for backup (image , direct
copy , etc)

Thanks, Tim and Haggis, for kindly and promptly posting your suggestions for
me and perhaps others to read! I appreciate your practical suggestions, Tim,
of comparing things between the two computers loaded with the same
application in the directory containing the application's .exe file.
Concerning your comment, Tim: "What happens is that an application depends on
a newer
version of an MS DLL, and the programmer includes that newer version
in the installation package."

If this is how things are done, I'm wondering how there could be a problem
with the added application in Windows 95. As long as the newer version of a
well-working system file was built by Microsoft Corporation for use in
Windows 95, I guess that there could only be a problem if say, only one or
less than a whole group of updated system files for Windows 95, which were
designed to of necessity all coexist and work together, was or were added.
Is that what sometimes causes a problem with an added application? Now in my
case I have tried to use a non-Microsoft-supplied application without
official support for Windows 95, but with support for Windows 98. I'm
"getting away with this" on my friend's, Windows-95-loaded computer, except
for occasional invalid-page faults on closing that application. In general
could another potential problem be that the programmer of an added
application may have used a Windows-98 system file, say Shell32.dll or
mfc42.dll or kernel32.dll, that has the same name as a Windows-95 system
file, but which Windows 95 for some reason cannot handle? Perhaps Windows 95
might not "know" about Windows 98, might be unable to recognize a Windows-98
system file incompatible with Windows 95, and therefore cannot inform the
Windows-95 user in an interesting way like, "Hey, you're trying to use a
Windows-98 system file with me. My name is 'Windows 95,' not 'Windows 98,'
got it?" I hope you enjoy a little humor or "color" here to make things
interesting for us. How is my guessing here? Or has someone built in
recognition of later Windows versions of files of the same name in earlier
versions of Windows? If not, and such things cause problems in different
versions of Windows, it would seem like a good thing to do and to add the
messaging of such an incompatibility to the Windows user.

And your idea, Haggis, is a clever one of using a small hard drive for
backup because if I look around I might have one that is not bad. If one
were to follow that "route," I suppose one would look for an extra, unused
connector in the gray, Integrated-Development-Environment (IDE) cable and
hook up the second hard drive, also connecting the usual, colored, power
leads to it, assuming there are some extra leads like those in the computer.
I would really like to avoid getting into the CMOS Setup for that computer,
which after I did so months ago, I have yet to find a way to get both the
3.5-inch diskette drive and a printer working in the same Windows session.
(If it were not for such concerns, I suppose it would probably be good to get
into the CMOS Setup and configure the added hard drive as a slave, leaving
the Windows-95-loaded hard drive as the master hard drive.) So I would hope
that Windows would detect the added hard drive for me; else I could use "Add
New Hardware" in "Control Panel" to add a hard drive with perhaps a generic
driver file that would make it work. The backup program I have in mind might
erase what's on the added hard drive in writing a backup file onto it; else I
might have to use the commands "fdisk" and "format" in MS-DOS (Microsoft Disk
Operating System) or DOS to format that added hard drive. I would like to
know if I would need to do anything else or not in order to have that second
hard drive work in a computer. I would really like to avoid losing what
already works just to make a backup of the present hard drive's contents. I
don't promise to follow this "route." And even I do not pursue it, I still
think it is good for me to know how one would make a backup of a hard drive
on a temporarily added hard drive in a desktop computer.

I think I once tried to hook up a hard drive into the internal cables of
somebody's else's desktop computer to fix a problem of my own on that added
hard drive, but failed. So I think I ended up taking that hard drive to a
commercial place to have Windows 95 installed again on that hard drive.
Thanks again, Tim and Haggis, for your input here!

Pat

"Haggis" wrote:

"Pat S." <PatS@discussions.microsoft.com> wrote in message
news:4D944A89-08FA-472D-BE06-5F4BE9B3E1D5@microsoft.com...
if your "supplied" was meant for win98 then is it most likely looking to use
resources that were not part of win95

same as having software meant to work on win98SE and installing it on
regular win98 , it will give problems of many shapoes and sizes


yes , connect to a "spare" connector on your IDE cable (slave jumper setting
recommended for a storage secondary drive)

if the jumper is correct and the drive is on the proper connector ,
depending on the age of your BIOS ...it should auto-detect it
you may also have a "auto detect IDE " or the like in your CMOS

if there is no usefull information on the drive ..format FAT32 and do your
backup (I use simple batch files with switches to overwrite existing files)
so I have a cumulative backup of sorts :>

HTH!

The warning about replacing files (eg DLLs) with newer versions will occur
if the installation routine is clever enough to detect that they are about
to get overwritten (some aren't). In your case I would guess that files
weren't replaced, but new versions of the files were copied into the system
(with a different name). Only the new application will use these files -
old applications built for Windows 95 don't even know they exist. But these
new files expect to find certain operating system features that only come
with Windows 98, and so when your application accesses these DLL routines
they fail because the operating system features they expect to find just
aren't there.

Whether your application is a Microsoft application or a non-Microsoft
application is not relevant. However, if it's a non-Microsoft application it
might be using DLLs that weren't already on your machine (they might be
exclusive to that manufacturer, and you don't have any other software from
that manufacturer) so that would also explain why there were no files that
got replaced. But the reason for the DLLs failing would be the same.

The programmer will definitely be using functions from files such as
shell32.dll, but they will not have included those files in the package, and
these files would not have been replaced with a new version in the
installation. These files are an essential part of the operating system and
cannot be simply upgraded by an installation program. The fact that the
programmer can't make this replacement is what makes the application
supported on Windows 98 and not supported on Windows 95 - the programmer
can't upgrade your operating system for you.
--
Jeff Richards
MS MVP (Windows - Shell/User)
"Pat S." <PatS@discussions.microsoft.com> wrote in message
news:4D944A89-08FA-472D-BE06-5F4BE9B3E1D5@microsoft.com...

Thanks, Haggis and Jeff Richards for kindly posting your comments here. I'd
like to have the correct understanding about whether system files can be
overwritten or not. I suspect that the answer depends on what people mean by
a system file. I have been trying to reconcile Jeff Richards' comments with
those on http://www.updatexp.com/scannow-sfc.html about the overwriting
system files in Windows 95. That Web site indicates that system files can be
overwritten in Windows 95 by applications (presumably mostly non-Microsoft
applications), whereas from Jeff Richards I got the impression that an
important system file like shell32.dll, which is part of the Windows-95
operating system, cannot be overwritten by some non-Microsoft application. I
now suspect that that Web address might be referring to “system files� as
files in a C:\Windows or C:\Windows\system directory which are not
Microsoft-produced files, but files some non-Microsoft application wrote in
one of those directories; furthermore I suspect that real, Microsoft-produced
system files of the Windows-95 operating system can only be overwritten by
the Windows-95 operating system itself, not by any non-Microsoft application.
How is my guessing or understanding here?

Pat

"Jeff Richards" wrote:

It depends what you mean by 'can'. It's possible to overwrite any file
with a different version if you know the tricks. The really determined can
boot to DOS and overwrite anything with a different version or even a
completely different file. There's no magical protection for a file just
because it's important to the operating system, or just because it was
written by Microsoft. But overwriting any file used by the operating system
with a version that's not compatible will cause problems, ranging from the
trivial to the catastrophic.

An important file like shell32.dll 'could' be overwritten by a different
version, but it's unlikely that the operating system would continue to run.

Someone preparing an installation package will only include those system
files which either might not already be on the user's machine,or for which
there are multiple versions available and they believe the latest version is
required. They can follow the Microsoft defaults, or they can make their
own rules. The files they copy might be Microsoft files or they might be
ones they created themselves or they might be ones from a third party that
they purchased as part of a library to make their software development
easier.

If they get it wrong, the installation might replace existing files with
non-compatible versions, which is the issue mentioned on the page you
referred to. If the user copies files manually (for instance, when trying
to make a W98 application run on a W95 machine) then they can create
incompatibilities. And in some cases the newer version of a file which is
supposed to be compatible just isn't, also creating problems.
--
Jeff Richards
MS MVP (Windows - Shell/User)
"Pat S." <PatS@discussions.microsoft.com> wrote in message
news:FB1B1FD7-C324-410D-96A1-38187C50FE9D@microsoft.com...

"Pat S." <PatS@discussions.microsoft.com> wrote in message
news:19074447-43F1-4401-B333-94EFD80FD9F5@microsoft.com...
When you hear the clicking sound, is it coming from the floppy drive? Does the
green light on the floppy drive light up when the clicking occurs?
--
Glen Ventura, MS MVP Shell/User, A+
http://dts-l.org/goodpost.htm