Discussion:
Windows 7 still fails
(too old to reply)
Benedict Holland
2018-09-25 16:44:09 UTC
Permalink
Hello all,

First off, let me state that I have extreme sympathy for people who have to
develop for windows. That said, by default, the windows installer running
on windows 7 breaks with the Perl.exe failing. I had to use the -v gui text
option and install a full install of Perl.

A few things about this process, do not tell anyone to disable firewalls or
anti-virus software. That makes your product look extremely sketchy. I
understand that you can't plan for everything but if someone told you to
just run this strange script as root while disabling the firewall and
anti-virus scanners, you should be very suspicious.

Also, honestly, you should have it working under windows 7 at this point.
Turn the firewalls on. Run the installation scripts. Fix the problems. I
shouldn't have an xz error throwing a perl.exe error. Assume that users are
installing this in a corporate environment as a local user with reasonable
security. We are long past the point of saying that users should disable
computer protections.

Also, make the default install location C:\Users\<local user> if they are
not running it as admin and C:\Program Files (x86)\ if they are. It's the
little things like that which will solve a host of problems. If I tried to
install something as a user on C:\ it would just fail.

Thanks,
~Ben
Siep Kroonenberg
2018-09-25 19:04:38 UTC
Permalink
Post by Benedict Holland
Hello all,
First off, let me state that I have extreme sympathy for people who have to
develop for windows. That said, by default, the windows installer running
on windows 7 breaks with the Perl.exe failing. I had to use the -v gui text
option and install a full install of Perl.
A few things about this process, do not tell anyone to disable firewalls or
anti-virus software. That makes your product look extremely sketchy. I
understand that you can't plan for everything but if someone told you to
just run this strange script as root while disabling the firewall and
anti-virus scanners, you should be very suspicious.
Also, honestly, you should have it working under windows 7 at this point.
Turn the firewalls on. Run the installation scripts. Fix the problems. I
shouldn't have an xz error throwing a perl.exe error. Assume that users are
installing this in a corporate environment as a local user with reasonable
security. We are long past the point of saying that users should disable
computer protections.
Your problems are not everybody's problems. The installer is tested
under Windows 7, without turning off protections, both as a regular
user and as adminstrator.
Post by Benedict Holland
Also, make the default install location C:\Users\<local user> if they are
not running it as admin and C:\Program Files (x86)\ if they are. It's the
little things like that which will solve a host of problems. If I tried to
install something as a user on C:\ it would just fail.
On an out of the box Windows installation, regular users _can_ install
software in the root of C:. In a corporate environment, there may be
indeed be more restrictions.

Installing in the root of C: is not uncommon for Windows ports of
open source software. For one thing, some third-party scripts
included in TL may not have been tested with spaces or funny
characters in path names. So it is not clear whether your suggestion
would be an improvement.

Siep
Philip Taylor
2018-09-25 21:52:39 UTC
Permalink
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">Benedict Holland wrote:<br>
<br>
</div>
<blockquote type="cite"
cite="mid:CAD+mzox4d3R-LkS3GWLE_HAu4t8=***@mail.gmail.com">
<div dir="ltr">Also, make the default install location
C:\Users\&lt;local user&gt; if they are not running it as admin
and C:\Program Files (x86)\ if they are. It's the little things
like that which will solve a host of problems. If I tried to
install something as a user on C:\ it would just fail. <br>
</div>
</blockquote>
<br>
Please do <i><b>not</b></i> make the default install location
C:\Program Files (x86)\; the vast majority of TeX Live is data, not
program.  Microsoft recognise that C:\Program Files &amp; C:\Program
Files (x86) should contain executables, not data, and provide
various alternative locations where such executables may store their
data; in TeX Live, programs and data are inextricably bound
together, and thus such separation is not possible — therefore,
C:\Program Files (x86) is a very poor and inappropriate location in
which to install such a mixed bundle.<br>
<br>
<div class="moz-signature">-- <br>
&lt;Signature&gt;<br>
Philip Taylor</div>
</body>
</html>
Benedict Holland
2018-09-25 22:04:31 UTC
Permalink
Hi all,

Yes. I am well aware that my problems are not everyone's. That said,
searching for Perl.exe throwing an error on a texlive install under windows 7
results in a lot of hits so apparently it isn't just me.

I know of no applications that install any software on root in windows or
Linux by default. I have used both extensively for more than 15 years. I
mention setting paths precisely because it is a port. The defaults since
Vista was to install user applications in their AppData directory. Python
does this. Python 2.7 used to install under root this but they stopped and
now follow the common paths. The default location since XP was to install
32-bit applications in C:\Program Files (x86)\ and 64-bit applications in
C:\Program Files\. Both require admin rights. Since you know if they are
running the install as admin and you know that it is windows, it shouldn't
be too difficult to set a default path better than root.

Regarding Philip's response, that is true and texlive already seems to
partition the executables well in a normal user install. I can't think of a
better place for computer-wide data. I have seen way worse than to place
computer wide and accessible files and folders within Program Files. At the
very least, the default single user should probably be in AppData.

Installing directly under C:\ requires admin rights and is typically
frowned upon. Telling users to disable security features is quite bad. This
isn't an opinion. If someone handed code to you and told you to run it as
root but make sure to disable your firewalls and anti-virus software, you
shouldn't install it. We are well past the era where we just get to
magically trust code. Also, unfortunately, users might not know how to
disable a firewall or even have rights to do so. I don't know what Perl is
doing to need ports open but given that it seems to be a persistent problem
and has been for at least 4 years, I wish to bring it to your attention. I
don't know how difficult that would be to fix and I don't know what the
error is.

Basically, I tried installing it, the install still gives errors, I don't
know why, the error messages are less than helpful, it seemed to require a
full perl install, and the -v gui text seemed to work but again, I don't
know why.

Oh. Another note about the installer. If perl.exe does crash, the install
looks like it completes. It would be nice to give an error message saying
that the install did not complete successfully.

Believe it or not, I don't want to sound mean. This product is awesome. It
is just too complex to give to someone who isn't a developer and tell them
to install it and following your advice opens their computer up to
vulnerabilities. Since Lyx is actually that simple and Lyx demands a
TexLive install, I would love to see it get to a point where a normal user
can simply install it or report useful errors. Way easier said than done I
am sure.

Thanks,
~Ben
Post by Benedict Holland
Also, make the default install location C:\Users\<local user> if they are
not running it as admin and C:\Program Files (x86)\ if they are. It's the
little things like that which will solve a host of problems. If I tried to
install something as a user on C:\ it would just fail.
Please do *not* make the default install location C:\Program Files
(x86)\; the vast majority of TeX Live is data, not program. Microsoft
recognise that C:\Program Files & C:\Program Files (x86) should contain
executables, not data, and provide various alternative locations where such
executables may store their data; in TeX Live, programs and data are
inextricably bound together, and thus such separation is not possible —
therefore, C:\Program Files (x86) is a very poor and inappropriate location
in which to install such a mixed bundle.
--
<Signature>
Philip Taylor
Norbert Preining
2018-09-26 01:07:26 UTC
Permalink
Hi Benedict,

many people have already answered to your comments, so I only add a bit
more. First of all, thanks for your comments, they are appreciated!
Post by Benedict Holland
First off, let me state that I have extreme sympathy for people who have to
develop for windows. That said, by default, the windows installer running
on windows 7 breaks with the Perl.exe failing. I had to use the -v gui text
option and install a full install of Perl.
This is strange and unexpected, as mentioned before. It is hard to say
with Windows what might interfere, though.
Post by Benedict Holland
A few things about this process, do not tell anyone to disable firewalls or
anti-virus software. That makes your product look extremely sketchy. I
You might be right, but there are hardly any installers that unpack
(xz/tar) out there. We consistently get problems with virus scanners
holding off creation of files via tar/xz to check them, which in the end
breaks the un-tar process and the whole installation.
Post by Benedict Holland
Also, honestly, you should have it working under windows 7 at this point.
Turn the firewalls on. Run the installation scripts. Fix the problems. I
That sounds all like a *very*nice*theory*, and if would be
*reproducible* then one could check and fix it. The problem with these
kind of errors are that they are
* mostly confined to certain computers
* there is no recipe to reproduce the same behaviour
If you can consistenly reproduce the problem, and give a recipe that one
of our developers can consistenly reproduce the same behaviour on our
computers, then we can look into it and fix it.

The problem with Windows is that it is roulette, and not computing.
Post by Benedict Holland
shouldn't have an xz error throwing a perl.exe error. Assume that users are
installing this in a corporate environment as a local user with reasonable
security. We are long past the point of saying that users should disable
computer protections.
Agreed, and I would be happy to have this status.

Actually there is a way, but no volunteer (we are all vounteers) has
stepped forward to do it: Create a repackaged version of TL similar to
MacTeX, with all files already in place, no way to choose any
configuration, and create a normal .msi installer.

Technically not a problem, but I don't have interest and time for doing
it.

Would you step forward to provide something like this?

The maintainer of MacTeX does it also on a volunteer basis and does a
stupendous job.

All the best

Norbert

--
PREINING Norbert http://www.preining.info
Accelia Inc. + JAIST + TeX Live + Debian Developer
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Denis Bitouzé
2018-09-26 06:39:54 UTC
Permalink
Post by Norbert Preining
Post by Benedict Holland
First off, let me state that I have extreme sympathy for people who
have to develop for windows. That said, by default, the windows
installer running on windows 7 breaks with the Perl.exe
failing. I had to use the -v gui text option and install a full
install of Perl.
This is strange and unexpected, as mentioned before. It is hard to say
with Windows what might interfere, though.
IIRC, this was the only way for a student of mine to install TL on its
Windows computer. Such a case seems to be exceptional but sometimes
arises.
--
Denis
Reinhard Kotucha
2018-09-26 02:58:51 UTC
Permalink
Post by Benedict Holland
A few things about this process, do not tell anyone to disable
firewalls or anti-virus software. That makes your product look
extremely sketchy. I understand that you can't plan for everything
but if someone told you to just run this strange script as
root while disabling the firewall and anti-virus scanners, you
should be very suspicious.
Where exactly are you told to disable the firewall? AFAIK only virus
scanners are mentioned. The firewall shall *never* be disabled.

Anti-virus programs which scan files while they are written to a disk
shall always never be disabled. These scanners do not interfere with
the TeX Live installer, apart of maybe occasionally reporting false
positives.

Only anti-virus programs which scan the whole disk *and* unnecessarily
prevent other programs from writing files to a particular directory
while it's scanned interfere with the installer. Such programs can
safely be disabled temporarily, of course, because they are unable to
detect viruses immediately. Whenever a virus exists on your disk,
it's too late anyway. It might have been executed already before it's
detected.

I don't think that it's a TeX Live issue. Any other big software
package is certainly affected too.

As far as the default installation directory is concerned, in TL-2008
the installer evaluated an environment variable (I don't remember but
maybe something like %PROGRAMFILES%) in order to install to a
directory where Windows expect programs. This worked fine under XP
but many users were not able to install TL on Vista.

Since Windows treats every directory on drive C: differently, except
the root directory, we had to switch back to C:\texlive as a default.
I'm not happy with this decision but we have no other choice. Users
expect that everything works out-of-the-box.

Windows is a moving target, not an operating system you can rely on in
the long term. At the moment it's best to install at the root of
drive C: by default because all other directories on this drive are
"maintained" by Microsoft with unpredictable behavior. I'm sure that
experiencecd users avoid drive c: anyway.
Post by Benedict Holland
First off, let me state that I have extreme sympathy for people who
have to develop for windows.
When we started to write an installer which is supposed to support all
operating systems, we assumed that Perl offers a layer of abstraction
which allows us to easily write a script which works on all platforms.

Believe me, it was a nice dream.

Without the tremendous work done by Siep Kroonenberg, Tomasz
M. Trzeciak, and Akira Kakuto it would be impossible to support
Windows at all.

Supporting Windows is definitely a challenge but the most important
thing, in my opinion, is that TeX Live behaves identical on all
supported platforms, regardless how difficult it's to achieve.

Regards,
Reinhard
--
------------------------------------------------------------------
Reinhard Kotucha Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover mailto:***@web.de
------------------------------------------------------------------
Zdenek Wagner
2018-09-26 11:15:17 UTC
Permalink
Post by Reinhard Kotucha
Post by Benedict Holland
A few things about this process, do not tell anyone to disable
firewalls or anti-virus software. That makes your product look
extremely sketchy. I understand that you can't plan for everything
but if someone told you to just run this strange script as
root while disabling the firewall and anti-virus scanners, you
should be very suspicious.
Where exactly are you told to disable the firewall? AFAIK only virus
scanners are mentioned. The firewall shall *never* be disabled.
Anti-virus programs which scan files while they are written to a disk
shall always never be disabled. These scanners do not interfere with
the TeX Live installer, apart of maybe occasionally reporting false
positives.
Only anti-virus programs which scan the whole disk *and* unnecessarily
prevent other programs from writing files to a particular directory
while it's scanned interfere with the installer. Such programs can
safely be disabled temporarily, of course, because they are unable to
detect viruses immediately. Whenever a virus exists on your disk,
it's too late anyway. It might have been executed already before it's
detected.
I am not sure that antivirus software does not interfere. It depends on the
antivirus. As I know, it is possible that a directory is temporarily locked
and is not writable. There was a discussion on it some time ago so probably
now the installer can cope even with this problem. Another problem is that
an antivirus software can interfere with the installer. If I start a
program unknown to the antivirus, the process is killed, the antivirus
examines it and if it passes, the process is started again. The good news
is that if I push th button that I do not want to report the existence of
the unknown program the antivirus remembers is and the next time the
program is whitelisted and runs.

The problems are even larger. I have Windows 7 in a virtual machine and use
subversion and git on it without any problem. Other users take advantage of
my software available from subversion. I explained them how to fetch it and
they do it on Windows XP, 7, 8, Vista, 10. All Windows computers in our
institute are installed by the IT department with the same firewall setting
and with the campus license of the antivirus. Yet on one Windows 10
computer "svn checkout" crashed rporting that the disk is not writable. I
tried to checkout it into another directory, tried to do it as system admin
(with the highest rights as people from the IT department), with antivirus
disabled, with firewall disabled and nothing helped. Windows experts from
the IT department tried to help but we do not understand why it does not
work on this one computer. Finally I did checkout on another computer and
transfered the whole tree on a USB.

I know that I am now a bit off topic but I just wanted to demonstrate that
life with Windows can sometimes be very difficult.


Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz

Loading...