New installer fails miserably when path of %TEMP% contains spaces
Stefan Kanthak
%TEMP% contains spaces (and %TEMP% has no short 8dot3 pathname).
Error message:
| Opera: error
| (X) Error during execution "C:\Documents and Settings\Local Settings\Temp\7ZipSfx.000\Opera.exe /install".
| The system cant find the specified file.
Reason: Missing quotes around the executable pathname!
Expected behaviour: no beginners errors!
Pathnames may ALWAYS contain special characters, especially spaces.
Kids, where is your QA?
Stefan
ge...@none.net
The new installer is part of alpha builds and therefore assumed to have
bugs. Instead of bad mouthing Opera developers, why don't you report
this and your other post where you got the new build, i.e., on the blog?
Opera beta forums or filing a bug report is also a possibility.
Gene
Håvard Kvam Moen
Thanks for reporting this. We'll look into it.
Public testing is an important part of the QA process because more
eyeballs will be able to spot more problems. That is why we are
releasing these snapshots, after all. And alpha software is bound to
have a lot of bugs.
--
Håvard Kvam Moen
Desktop QA, Opera Software
Stefan Kanthak
> On Thu, 18 Nov 2010 14:44:55 +0100, "Stefan Kanthak"
> <postmaster@[127.0.0.1]> wrote:
>
>> The new Windows installer fails miserably when the environment variable
>> %TEMP% contains spaces (and %TEMP% has no short 8dot3 pathname).
>>
>> Error message:
>>
>> | Opera: error
>> | (X) Error during execution "C:\Documents and Settings\Local Settings\Temp\7ZipSfx.000\Opera.exe /install".
>> | The system cant find the specified file.
>>
>> Reason: Missing quotes around the executable pathname!
>>
>> Expected behaviour: no beginners errors!
>> Pathnames may ALWAYS contain special characters, especially spaces.
>>
>> Kids, where is your QA?
>
> Thanks for reporting this. We'll look into it.
I recommend to setup at least one Windows development and test machine
per site without any "short" (8.3) filename to catch such (simple) errors.
For Windows NT5.x it's easy; add/modify the following files to/in the
\i386\ directory of your Windows XP/2003 setup CD:
1.
--- MIGRATE.INF ---
[Version]
Signature = "$Windows NT$"
[AddReg]
HKLM,"System\ControlSet001\Control\FileSystem","NTFSDisable8dot3NameCreation",0x00010001,1
HKLM,"System\ControlSet001\Control\FileSystem","Win95TruncatedExtensions",0x00010001,0
--- EOF ---
2.
--- HIVESYS.INF ---
...
HKLM,"SYSTEM\CurrentControlSet\Control\FileSystem","NtfsDisable8dot3NameCreation",0x00010001,1
...
HKLM,"SYSTEM\CurrentControlSet\Control\FileSystem","Win95TruncatedExtensions",0x00010001,0
...
--- EOF ---
> Public testing is an important part of the QA process because more
> eyeballs will be able to spot more problems. That is why we are
> releasing these snapshots, after all. And alpha software is bound to
> have a lot of bugs.
(Un.-)fortunately I've not been bitten by a single error in all the
alphas of Opera 11 yet: the browser itself works for me.
But the "new" installer really needs some attention.
BTW: why do you use a 3rd party compression utility on Windows at all?
Your developers should know *.CAB as well as MAKECAB.EXE, EXTRACT.EXE,
WEXTRACT.EXE and IEXPRESS.EXE, which are part of every Windows
installation for more than 11 years now, and use these platform-native
tools instead!
Stefan
Jernej Simončič
> Your developers should know *.CAB as well as MAKECAB.EXE, EXTRACT.EXE,
> WEXTRACT.EXE and IEXPRESS.EXE, which are part of every Windows
> installation for more than 11 years now, and use these platform-native
> tools instead!
Probably because 7-zip is much easier to use, is faster at both compression
and especially decompression, and creates smaller files (even when you
count the overhead of decompression code)?
There's a very good reason why a ton of programs pack their installers with
7-zip for redistribution.
--
begin .sig
< Jernej Simončič ><>◊<>< jernej|s-ng at eternallybored.org >
end
Stefan Kanthak
> on Fri, 19 Nov 2010 19:45:29 +0100, Stefan Kanthak wrote:
>
>> Your developers should know *.CAB as well as MAKECAB.EXE, EXTRACT.EXE,
>> WEXTRACT.EXE and IEXPRESS.EXE, which are part of every Windows
>> installation for more than 11 years now, and use these platform-native
>> tools instead!
>
> Probably because 7-zip is much easier to use,
Really?
7-zip CANT be used on a Windows before you install it. And before that, you
have to download it. Which might be a little tricky without internet access.
MAKECAB.EXE etc. are all on board and available without installation.
And, just in case that you don't know: *.CAB don't need to be unpacked for
installation! Windows native SetupAPI (driven by *.INF) can access files
within *.CAB, directly, without intermediate decompression/extraction of
the whole archive.
> is faster at both compression
Maybe. But: who cares? Compression is done as part of the (automated) build
process, where a somehow slower compression routine is tolerable (if the
additional time is noticable at all).
> and especially decompression,
Really? I don't experience a noticable difference here.
> and creates smaller files
That's wrong:
MAKECAB.EXE /D CompressionType=LZX /D CompressionLevel=7 /D CompressionMemory=21
compresses as good as 7-zip.
And: what's the overall disk space consumption of the new opera installer?
How many MBs and files/folders get shuffled around?
- about 7MB for the self-extracting archive (1 file);
- about 18MB in %TEMP% (13 folders, 137 files);
- about 18MB in the destination directory (13 folders, 137 files).
Compare these numbers against a native Windows installer built with *.INF
and *.CAB:
- about 7MB for the *.CAB and *.INF (2 files);
- about 18MB in the destination directory (13 folders, 137 files).
About 18MB less disk space (NO temporary space needed at all for intermediate
decompression/extraction of the whole archive!), about 36MB less IO (the meta
data for creation/removal of the temporary files/folders not counted), and a
shorter installation time too!
Can 7-zip (or any other tool) beat that?
> (even when you count the overhead of decompression code)?
Do you count the overhead of downloading and installation of 7-zip by the end
user?
> There's a very good reason why a ton of programs pack their installers with
> 7-zip for redistribution.
No. There is never good reason not to use the platforms native tools.
Stefan
Jernej Simončič
> Really?
> 7-zip CANT be used on a Windows before you install it. And before that, you
> have to download it. Which might be a little tricky without internet access.
> MAKECAB.EXE etc. are all on board and available without installation.
Who cares? Only the developers need 7-zip installed on their machine, the
end user gets a self-extracting file which he just needs to run.
> And: what's the overall disk space consumption of the new opera installer?
> How many MBs and files/folders get shuffled around?
> - about 7MB for the self-extracting archive (1 file);
> - about 18MB in %TEMP% (13 folders, 137 files);
> - about 18MB in the destination directory (13 folders, 137 files).
Disk space on the end user's machine doesn't really matter when you can get
a 2TB drive for less than 80€. What matters is the amount needed to
download since bandwidth isn't free for the uploader.
> Compare these numbers against a native Windows installer built with *.INF
> and *.CAB:
> - about 7MB for the *.CAB and *.INF (2 files);
> - about 18MB in the destination directory (13 folders, 137 files).
Bzzt - you have 2 files - how will you ship them to the user? Remember,
people are used to download a single file to install something. Of course,
you could pack those 2 files to another archive, but that kinda defeats the
purpose. Also, with CAB+INF you can't just double-click one file to install
- you have to know that you need to right-click the inf file and select
Install - but the majority of users will never bother with that.
> About 18MB less disk space (NO temporary space needed at all for intermediate
> decompression/extraction of the whole archive!), about 36MB less IO (the meta
> data for creation/removal of the temporary files/folders not counted), and a
> shorter installation time too!
> Can 7-zip (or any other tool) beat that?
Yes, just about any installer can (besides, you're looking at the wrong
things - what matters for the publisher is to minimize bandwidth
consumption, and what matters to the user is to have as simple install
process as possible) - except that none of them are flexible enough for
Opera to use.
>> (even when you count the overhead of decompression code)?
> Do you count the overhead of downloading and installation of 7-zip by the end
> user?
No, because they don't need it.
>> There's a very good reason why a ton of programs pack their installers with
>> 7-zip for redistribution.
> No. There is never good reason not to use the platforms native tools.
When's the last time you saw an installer that uses inf+cab method?
Follow-up to opera.off-topic.
Stefan Kanthak
> on Sat, 20 Nov 2010 10:38:39 +0100, Stefan Kanthak wrote:
>
>> Really?
>> 7-zip CANT be used on a Windows before you install it. And before that, you
>> have to download it. Which might be a little tricky without internet access.
>> MAKECAB.EXE etc. are all on board and available without installation.
>
> Who cares? Only the developers need 7-zip installed on their machine, the
> end user gets a self-extracting file which he just needs to run.
Why should developers with a sane mind and proper knowledge of the platform
they write software for use a non-native compression utility?
IEXPRESS.EXE (which uses MAKECAB.EXE) creates self-extracting files on
Windows.
> What matters is the amount needed to
> download since bandwidth isn't free for the uploader.
If true, then *.CAB without a stub for extraction is the smallest form for
distribution.
>> Compare these numbers against a native Windows installer built with *.INF
>> and *.CAB:
>> - about 7MB for the *.CAB and *.INF (2 files);
>> - about 18MB in the destination directory (13 folders, 137 files).
>
> Bzzt - you have 2 files - how will you ship them to the user? Remember,
> people are used to download a single file to install something.
Unfortunately, people have been dumbed down.
> Of course, you could pack those 2 files to another archive, but that kinda
> defeats the purpose.
If you REALLY want to have an *.EXE use IEXPRESS.EXE and create one.
This will extract *.CAB and *.INF to %TEMP%, then run the *.INF, and still
use less resources than the 7-zip SFX.
> Also, with CAB+INF you can't just double-click one file to install
> - you have to know that you need to right-click the inf file and select
> Install - but the majority of users will never bother with that.
Yes. Dumbed down.
>> About 18MB less disk space (NO temporary space needed at all for intermediate
>> decompression/extraction of the whole archive!), about 36MB less IO (the meta
>> data for creation/removal of the temporary files/folders not counted), and a
>> shorter installation time too!
>
>> Can 7-zip (or any other tool) beat that?
>
> Yes, just about any installer can
Show the numbers!
> (besides, you're looking at the wrong things - what matters for the publisher
> is to minimize bandwidth consumption,
Where 7-zip has NO advantage over MakeCAB!
>>> (even when you count the overhead of decompression code)?
>> Do you count the overhead of downloading and installation of 7-zip by the end
>> user?
>
> No, because they don't need it.
Aha. But you wanted to count the overhead of the decompression code!
With *.CAB, you don't need that at all.
>>> There's a very good reason why a ton of programs pack their installers with
>>> 7-zip for redistribution.
>> No. There is never good reason not to use the platforms native tools.
>
> When's the last time you saw an installer that uses inf+cab method?
At least every time I install a device driver, a Windows component or a
Windows update!
Smart developers use *.CAB and *.INF^W^W^Wtheir platforms native format.
Others just haven't learned...
Stefan
Jernej Simončič
>> What matters is the amount needed to
>> download since bandwidth isn't free for the uploader.
> If true, then *.CAB without a stub for extraction is the smallest form for
> distribution.
I extracted Opera_installer_1100_1060_en.exe (7110051 bytes) to a new
directory, then compressed it to a CAB file (which turned out to be a much
more complex task than creating a typical archive). Anyway, the result of
running
MAKECAB.EXE /D CompressionType=LZX /D CompressionLevel=7 /D CompressionMemory=21 /f opera.txt
is a 7480130 bytes large CAB file - 370079 bytes larger than the original
installer (and this is despite the original installer having a nearly half
megabyte stub thanks to a huge uncompressed icon it includes).
>> Bzzt - you have 2 files - how will you ship them to the user? Remember,
>> people are used to download a single file to install something.
> Unfortunately, people have been dumbed down.
No, the computers were simply made more accessible to normal people (which
just want them to work, without having to read through several 500-page
manuals first).
> If you REALLY want to have an *.EXE use IEXPRESS.EXE and create one.
> This will extract *.CAB and *.INF to %TEMP%, then run the *.INF, and still
> use less resources than the 7-zip SFX.
Except that a plain CAB file is already larger than the current installer.
>>> About 18MB less disk space (NO temporary space needed at all for intermediate
>>> decompression/extraction of the whole archive!), about 36MB less IO (the meta
>>> data for creation/removal of the temporary files/folders not counted), and a
>>> shorter installation time too!
>>> Can 7-zip (or any other tool) beat that?
>> Yes, just about any installer can
> Show the numbers!
Basic Inno Setup installer 7429332 bytes - still smaller than the CAB file,
and much more user-friendly at the same time. I won't bother with NSIS,
because it's scripting is much more complex, which is too time consuming
just to prove a point (but NSIS usually creates smaller files than Inno).
>> (besides, you're looking at the wrong things - what matters for the publisher
>> is to minimize bandwidth consumption,
> Where 7-zip has NO advantage over MakeCAB!
Already proven to be false.
>> When's the last time you saw an installer that uses inf+cab method?
> At least every time I install a device driver, a Windows component or a
> Windows update!
Drivers either use their own installer, or come packed in ZIP files (and
are then used by the Add new hardware wizard). Their INF files don't
support the right-click -> Install method of installation. Windows updates
use .msu files, which is a custom format (updates for older versions of
windows come in self-extracting files - again no CAB and INF files in
sight).
> Smart developers use *.CAB and *.INF^W^W^Wtheir platforms native format.
> Others just haven't learned...
I guess there's no smart developers on Windows then?
Stefan Kanthak
> on Sat, 20 Nov 2010 16:04:29 +0100, Stefan Kanthak wrote:
>
>>> What matters is the amount needed to
>>> download since bandwidth isn't free for the uploader.
>> If true, then *.CAB without a stub for extraction is the smallest form for
>> distribution.
>
> I extracted Opera_installer_1100_1060_en.exe (7110051 bytes) to a new
> directory, then compressed it to a CAB file (which turned out to be a much
> more complex task than creating a typical archive).
You might have used CABARC.EXE which doesnt need a .DDF (diamond directive
file) as input.
> Anyway, the result of running
> MAKECAB.EXE /D CompressionType=LZX /D CompressionLevel=7 /D CompressionMemory=21 /f opera.txt
> is a 7480130 bytes large CAB file - 370079 bytes larger than the original
> installer (and this is despite the original installer having a nearly half
> megabyte stub thanks to a huge uncompressed icon it includes).
.CAB dont need an extractor since it is the native format, 7-zip bit but does,
so you'll have to account for the stub.
Opera_installer_1100_1094_en.exe : 7217606 bytes
------- = 1 : 1,0369 ~ 27 / 28
opera11.cab : 7483986 bytes
The difference is barely noticable, just within the typical error margin.-)
>>> Bzzt - you have 2 files - how will you ship them to the user? Remember,
>>> people are used to download a single file to install something.
>> Unfortunately, people have been dumbed down.
>
> No, the computers were simply made more accessible to normal people (which
> just want them to work, without having to read through several 500-page
> manuals first).
You need 500 pages for a simple sentence like
| Download both the .CAB and the .INF, then right-click the latter and click
| "Install"
OMG m(
>>> When's the last time you saw an installer that uses inf+cab method?
>> At least every time I install a device driver, a Windows component or a
>> Windows update!
>
> Drivers either use their own installer, or come packed in ZIP files (and
> are then used by the Add new hardware wizard).
Never heard of unattended setup? There is no .EXE to run then, and no
"Add new hardware wizard". Just a list of directories to be given in
[HKLM\Software\Microsoft\Windows\CurrentVersion] DevicePath=
and the drivers unpacked into these directories.
> Their INF files don't support the right-click -> Install method of
> installation.
Wrong. You can write INF files for driver installation for both right
click and the "Add new hardware wizard".
> Windows updates use .msu files, which is a custom format
Wrong again: .MSU are .CAB archives, using in-cabinet delta compression.
> (updates for older versions of windows come in self-extracting files
> - again no CAB and INF files in sight).
Wrong once^Wtwice more:
1. the .EXE you reference are .CAB and use an UPDATE.INF, interpreted but
through UPDATE.EXE (for Windows 9x, the .EXE were IEXPRESS installers,
with .INF for SetupX.Dll, SetupAPI.Dll or AdvPack.Dll).
2. take a look into %SystemRoot%\SoftwareDistribution\Download\ and check
the wire: Windows Update uses .CAB for transfer and .INF for install
BTW: what about the Windows components?
>> Smart developers use *.CAB and *.INF^W^W^Wtheir platforms native format.
>> Others just haven't learned...
>
> I guess there's no smart developers on Windows then?
Wrong guess! Check the drivers for Matrox Graphic cards, for example.
Or nVidia drivers: their NView is installed from NVIEW.CAB.
Then take a look at <http://home.arcor.de/skanthak/download/XP_SAFER.INF>,
<http://home.arcor.de/skanthak/download/GMAIL.INF> or
<http://home.arcor.de/skanthak/download/HOTMAIL.INF> or even
<http://home.arcor.de/skanthak/download/8859-15.EXE>
Software which I compile or distribute comes in .CAB and uses .INF
Stefan
Jernej Simončič
>> I extracted Opera_installer_1100_1060_en.exe (7110051 bytes) to a new
>> directory, then compressed it to a CAB file (which turned out to be a much
>> more complex task than creating a typical archive).
> You might have used CABARC.EXE which doesnt need a .DDF (diamond directive
> file) as input.
I could? But that needs the platform SDK or MS cabinet tools, neither of
which are installed on every machine by default (plus cabarc creates larger
files for some reason, despite using -m LZX:21).
> .CAB dont need an extractor since it is the native format, 7-zip bit but does,
> so you'll have to account for the stub.
I did account for the stub - and the file was still 361kB smaller.
> Opera_installer_1100_1094_en.exe : 7217606 bytes
> ------- = 1 : 1,0369 ~ 27 / 28
> opera11.cab : 7483986 bytes
> The difference is barely noticable, just within the typical error margin.-)
Relative difference doesn't mean much - 361kB is noticable when you have a
few millions of downloads (especially when the majority of these downloads
try to happen in the first few hours after a release).
>> No, the computers were simply made more accessible to normal people (which
>> just want them to work, without having to read through several 500-page
>> manuals first).
> You need 500 pages for a simple sentence like
>| Download both
99% people won't read past this word (why should they - every other piece
of software only needs them to download a single file and double-click it).
> Never heard of unattended setup? There is no .EXE to run then, and no
> "Add new hardware wizard". Just a list of directories to be given in
> [HKLM\Software\Microsoft\Windows\CurrentVersion] DevicePath=
> and the drivers unpacked into these directories.
That's what the installers do (unless by unattended setup you meant the
drivers that are installed from the OS install media).
>> Their INF files don't support the right-click -> Install method of
>> installation.
> Wrong. You can write INF files for driver installation for both right
> click and the "Add new hardware wizard".
I tried several drivers on my disk, and all of them reported "The INF file
you selected does not support this method of installation". I wonder why.
>> (updates for older versions of windows come in self-extracting files
>> - again no CAB and INF files in sight).
> Wrong once^Wtwice more:
> 1. the .EXE you reference are .CAB and use an UPDATE.INF, interpreted but
> through UPDATE.EXE (for Windows 9x, the .EXE were IEXPRESS installers,
> with .INF for SetupX.Dll, SetupAPI.Dll or AdvPack.Dll).
We must use a different OS - the XP updates I've seen unpack themselves to
directories with long names on a random drive, then run update.exe from
there - no CABs in sight in those directories.
> Wrong guess! Check the drivers for Matrox Graphic cards, for example.
> Or nVidia drivers: their NView is installed from NVIEW.CAB.
...but where's the INF file for NView? Besides, before you get to the NView
installer, the drivers have to be unpacked - from a self-extracting 7-Zip
archive (now where have we seen that before?).
(btw, it was similar with Matrox when I still had my P650 card - their
drivers were distributed in a self-extracting ZIP file)
> Software which I compile or distribute comes in .CAB and uses .INF
Is your software intended for the general public, and if it is, how many
users (or downloads) do you have?
Stefan Kanthak
> on Sat, 20 Nov 2010 23:45:23 +0100, Stefan Kanthak wrote:
>
>>> I extracted Opera_installer_1100_1060_en.exe (7110051 bytes) to a new
>>> directory, then compressed it to a CAB file (which turned out to be a much
>>> more complex task than creating a typical archive).
>> You might have used CABARC.EXE which doesnt need a .DDF (diamond directive
>> file) as input.
>
> I could?
That was a proposition to use an alternative tool, just in case you dont
know it.
> But that needs the platform SDK or MS cabinet tools, neither of
> which are installed on every machine by default
Developers have the platform SDK installed on their machine...
>> You need 500 pages for a simple sentence like
>>| Download both
>
> 99% people won't read past this word (why should they - every other piece
> of software only needs them to download a single file and double-click it).
Dumbed-down!
>> Never heard of unattended setup? There is no .EXE to run then, and no
>> "Add new hardware wizard". Just a list of directories to be given in
>> [HKLM\Software\Microsoft\Windows\CurrentVersion] DevicePath=
>> and the drivers unpacked into these directories.
>
> That's what the installers do
Basically,-)
> (unless by unattended setup you meant the
> drivers that are installed from the OS install media).
Right that.
>>> Their INF files don't support the right-click -> Install method of
>>> installation.
>> Wrong. You can write INF files for driver installation for both right
>> click and the "Add new hardware wizard".
>
> I tried several drivers on my disk, and all of them reported "The INF file
> you selected does not support this method of installation". I wonder why.
Read again, carefully: you CAN write INF files which support both.
>>> (updates for older versions of windows come in self-extracting files
>>> - again no CAB and INF files in sight).
>
>> Wrong once^Wtwice more:
>
>> 1. the .EXE you reference are .CAB and use an UPDATE.INF, interpreted but
>> through UPDATE.EXE (for Windows 9x, the .EXE were IEXPRESS installers,
>> with .INF for SetupX.Dll, SetupAPI.Dll or AdvPack.Dll).
>
> We must use a different OS - the XP updates I've seen unpack themselves to
> directories with long names on a random drive, then run update.exe from
> there - no CABs in sight in those directories.
The SFX is a stub plus CAB!
>> Wrong guess! Check the drivers for Matrox Graphic cards, for example.
>> Or nVidia drivers: their NView is installed from NVIEW.CAB.
>
> ...but where's the INF file for NView? Besides, before you get to the NView
> installer, the drivers have to be unpacked - from a self-extracting 7-Zip
> archive (now where have we seen that before?).
Just another good example for inferior driver packaging: I already mentioned
that .INF can access .CAB directly, without unpacking it. There is NO
(technical) need to distribute software in form of self-extracting archives!
> (btw, it was similar with Matrox when I still had my P650 card - their
> drivers were distributed in a self-extracting ZIP file)
Take a look at the extracted files!
Stefan
