Default to keep newer file during installs?

Is there a registry key to set W98's hardware (and perhaps software) installs
to default to silently overlooking the presence of a newer file, and keeping
it, when installing new hardware? An INI file entry will do equally well if
there is one, but not a commandline switch as the install process isn't
invoked that way, at least not in this case (while Windows is active).

(It could also be useful to set a value to cause a silent ignore of newer
files while defaulting to replace with older ones, and if a way to do that
exists, it might lead to an answer to the default-to-keep-newer method).

On Jun 4, 12:07*pm, Lostgallifreyan wrote:
Is there a registry key to set W98's hardware (and perhaps software) installs
to default to silently overlooking the presence of a newer file, and keeping
it, when installing new hardware? An INI file entry will do equally well if
there is one, but not a commandline switch as the install process isn't
invoked that way, at least not in this case (while Windows is active).

(It could also be useful to set a value to cause a silent ignore of newer
files while defaulting to replace with older ones, and if a way to do that
exists, it might lead to an answer to the default-to-keep-newer method).

No. The behavior you describe is the default one for inf files and
with a flag you can ignore current files and install the packages
files always, install only higher versioned files, or ask the user if
he wants his newer file overwritten with an older one if such is the
case. Otherwise the user is not informed usually of anything. File
date is really NOT the deciding issue, only file version number is -
higher is assumed to be newer and the one to use.

You might want to look at the help file for WillyPad which is an inf
file notepad type of program. Good info in it though.
http://sn81.free.fr/snoopy81/files/

Write your own packages with IExpress
http://www.mdgx.com/add.htm#IEA

Lee wrote in news:a939b0e3-77a5-40f7-be7e-
:

No. The behavior you describe is the default one for inf files and
with a flag you can ignore current files and install the packages
files always, install only higher versioned files, or ask the user if
he wants his newer file overwritten with an older one if such is the
case. Otherwise the user is not informed usually of anything. File
date is really NOT the deciding issue, only file version number is -
higher is assumed to be newer and the one to use.


Sure about that 'no'? You say the flag can set to 'install only higher
versioned files' which is exactly what I want (I assume this means without
prompting). When I say 'newer' I relay the phrasing of the actual message, I
realise it means version, not date. (If I want to keep an older file, this
can still work, I just hack its version number higher than anything I'll
likely encounter).

I'll look at editing inf files, I already do it a bit, but it might be wise
to avoid it if there's a risk of difficulty in syncing with changes in other
things that may be frequently updated, like those supplied with NUSB or
KernelEx. One possibility is a cache of of files (late or early) that the
installer will always check and use if it finds what it wants there. I've not
yet figured out if there is a way, but I bet there is...

Lee wrote in news:a939b0e3-77a5-40f7-be7e-
:

Write your own packages with IExpress
http://www.mdgx.com/add.htm#IEA


Thanks, that might be extremely useful.

Lee wrote:

(...)

Just out of curiosity Lee - how does one get a "my-deja.com" e-mail
address?

Or is that a non-functional (bogus) address?

Lee wrote in news:a939b0e3-77a5-40f7-be7e-
:

with a flag you can ignore current files and install the packages
files always, install only higher versioned files...

I found two equal file version numbers, 'File Version' and 'Product Version'.
While I tested using actual different versions of USBaudio.sys using the
COPYFLG_NO_VERSION_DIALOG flag (value 32), finding that it preserved the
newer version, I did a hex edit hack test to force an updated value for both
version numbers in the destination file, and that failed, the 'older' copy
overwrote it.

Any idea what else is being tested? It can't be just version numbers. (I
tried changing dates, expecting no change, and got none), but it might be
size (I tried putting extra bytes in a copy to see if it worked, but it
borked the version resource! Got to use a resource hacker somehow if I test
that again).

For reference, here's my test INF:

[Version]
Signature="$CHICAGO$"

[DefaultInstall]
CopyFiles=X

[DestinationDirs]
X=10,Desktop

[X]
Usbaudio.sys,,,32
;COPYFLG_NO_VERSION_DIALOG
;no version conflict dialog
;keep newer file if it exists

On Jun 5, 9:15*am, Lostgallifreyan wrote:
Lee wrote in news:a939b0e3-77a5-40f7-be7e-
:

with a flag you can ignore current files and install the packages
files always, install only higher versioned files...

I found two equal file version numbers, 'File Version' and 'Product Version'.
While I tested using actual different versions of USBaudio.sys using the
COPYFLG_NO_VERSION_DIALOG flag (value 32), finding that it preserved the
newer version, I did a hex edit hack test to force an updated value for both
version numbers in the destination file, and that failed, the 'older' copy
overwrote it.

Any idea what else is being tested? It can't be just version numbers. (I
tried changing dates, expecting no change, and got none), but it might be
size (I tried putting extra bytes in a copy to see if it worked, but it
borked the version resource! Got to use a resource hacker somehow if I test
that again).

For reference, here's my test INF:

[Version]
Signature="$CHICAGO$"

[DefaultInstall]
CopyFiles=X

[DestinationDirs]
X=10,Desktop

[X]
Usbaudio.sys,,,32
;COPYFLG_NO_VERSION_DIALOG
;no version conflict dialog
;keep newer file if it exists

Not too sure you can muddle about in files like that and get away with
it to start with. CRC, digital signatures and other methods conspire
to keep people from doing exactly what you are wanting to do - change
version numbers to your own and make dll hell anew. I don't have any
ideas anyway, sorry. But it's not size. Over on MSFN.org they are
changing versions by recompiling the entire file and that works.

At one time I wanted to make a msi installation checker to see if
every file in the msi package was installed correctly and to test it I
would hex edit one byte (bit) and the inf file checker would replace
it right now and leave untouched files alone. I knew as I had changed
the dates on everything with Properties Plus - how the inf file could
find the files with one bit difference I have no clue but it did. It
must be doing a genuine CRC check? I found that 40 flag in some
obscure inf file and made a note of it. It's an undocumented flag to
be sure like most of the inf file process and processing - In house
and on a need to know basis only I suspect. Us on the outside can
only guess at it sometimes.
http://groups.google.com/group/micro...98ab39265b4a77

Windows Installer 2.0 Redistributable
for Windows 95, 98, and Me - 25 Sep 2001 1,670kb
http://www.microsoft.com/downloads/d...2-DE3BB768148F


98guy - it's a non-functional address now at least, I got mine when
Deja.com still owned Usenet and not Google. I never needed to change
it? I never used the free email service of Deja.com if there was one
anyway. I was such a noob at the time I just froze like a deer in the
headlights and kept on posting when Google took over. I'm doing good
to have it say Lee instead of mel like it does in some of my other
google groups. Several wanted me to use LookOut Express to download
these groups, but I never felt secure enough that my email wouldn't
get 'out there' despite their best advice. My email files are big
enough as it is anyway. And now there is little point - the Atari 8-
bit group gets more visits per week than this one... sniffle

Lee wrote in news:9f0433dd-d888-43fd-a37a-
:

Not too sure you can muddle about in files like that and get away with
it to start with. CRC, digital signatures and other methods conspire
to keep people from doing exactly what you are wanting to do - change
version numbers to your own and make dll hell anew.

Actually I don't. I'll hex-edit for myself, but my reason here is to find a
way to avoid the hell if I distribute my plans for the modular W98 build. As
it will use files used in part of NUSB, and patched ESDI_506.pdr for 48 bit
LBA, and likely KernelEx if it works right when I get round to trying, I'll
have to draw up a list of exact files by name, version, and size, and MD5
checksum. All that concerns me is that they work, and people can see what
they are and where they came from.

I wouldn't use any kind of limit on what people do with it, no 'trusted
computing' from me, just the best shot at a set of starting conditions so
that changes can be made with something to return to if they fail. I'm never
going to kid myself that I can control it once it's out of my machine, and
likely not even before that. W98 isn't going to survive that way, it survives
mainly because we never know by who, or how, some limitation might get fixed.
I know some people still try to manage this like M$, with cab files based on
their ways of working, but there's not much point. For one thing, there is no
definitive answer. It's not like anyone out here in the wilderness has their
entire W98 source code to audit.

Lee wrote in news:9f0433dd-d888-43fd-a37a-
:

At one time I wanted to make a msi installation checker to see if
every file in the msi package was installed correctly and to test it I
would hex edit one byte (bit) and the inf file checker would replace
it right now and leave untouched files alone. I knew as I had changed
the dates on everything with Properties Plus - how the inf file could
find the files with one bit difference I have no clue but it did. It
must be doing a genuine CRC check? I found that 40 flag in some
obscure inf file and made a note of it. It's an undocumented flag to
be sure like most of the inf file process and processing - In house
and on a need to know basis only I suspect. Us on the outside can
only guess at it sometimes.


Properties Plus. Totally indispensible. I still haven't decided if that
ought to be in my core where I'll agomise over 20 KB extra if I'm in the mood
for it. Very nice tool.

The 40 flag I saw too yesterday. Didn't give it much thought, but if you mean
a CopyFiles flag, it surely relates to 8, as 40 is 8+32, and we know what 32
does. I saw a LOT of 8's... (I'm assuming you mean 40 decimal, as hex 40
is decimal 64 and is also documented.

CRC wouldn't surprise me, as the first thing I do when files appear to be the
same is run FC /B. Just to be sure. Anyone with M$'s nouse would want to
build that in to an installer in some form to be sure their starting
conditions were good. I suspect their motives aren't necessarily any less
'pure' than mine, as they surely expected to have to change things yet again
later... I think like all of us, they are just banging pitons into rock in
case they fall off.

MSI is weird. Some hate it, I sort of like it. I like not having it in the
system (Ghosting back to an earlier state after use and extraction of program
files and reg entries for manual install), but I like how it works. Beats
InstallSheild which seems to have Securicor's private army aesthetic and
pollutes a machine like an occupying enemy army.

Interesting thread you linked to, I'll read it all.

Lee wrote in news:9f0433dd-d888-43fd-a37a-
:

must be doing a genuine CRC check? I found that 40 flag in some
obscure inf file and made a note of it. It's an undocumented flag to
be sure like most of the inf file process and processing - In house
and on a need to know basis only I suspect. Us on the outside can
only guess at it sometimes.


In this case we can. The mystery is elsewhere. 40 is just 32 (keep newer if
exists), combined with 8. Which is use Wininit.ini and Wininit.bak at reboot
to overwrite in-use file, forcing this behaviour even if the file is NOT in
use, possibly..

But suppose that the changed file is saved and closed. Maybe that sets a
state that guarantees that it is seen as NOT in use, as opposed to uncertain.
In this case the 8 part of the 40 flag might cause the other files to be made
as temporary files, leaving the originals apparently unchanged (till next
boot, anyway). In this case the changed one might not be deferred like the
rest, but immediately replaced by the setup installer if it knows the file
state. Just a guess, but it could fit..

Another possibility is that editing a file by one bit results in an
interpretation that the file is OLDER rather than newer, even if the edit was
to force an increment of version numbers in the version resource. Sounds odd,
I know, but it IS feasible, as M$ might have wanted to test for exactly those
kinds of shannigans and fix them. I don't know where your changed byte was in
the file, and it might matter for many subtle reasons, rather than a general
CRC check. If you didn't try doing it in some user-display text string, try
that, see if it makes any difference. I can't imagine a more innocuous place
to make the change, anyway...