Next will you be suggesting for people to use MMC snapins as opposed to
writing standalone applications, because it is shitty standalone
applications that do things and not MMC?
You can use WIX/MSI to write shitty installers too if I am not mistaken.
I've seen brilliant NSIS/InstallShield installers and shitty MSI
installers. And vice versa.
As an end-user I must say MSI also tends to piss me off, particularly when
the database gets corrupted and what not. Good concept though, but I
question the way it is implemented. I have written about what I think
about MSI in another mail so no need for me to repeat myself.
But what I am trying to suggest is that shitty installers will be shitty
installers. You can write shitty installers in
SuperDuperUltraInstallerLanguageSoGoodItIsGuaranteedToMakeOtherInstallersShitTheirPantsAndGoBankrupt
and they will still be shitty installers.
On Sat, 04 Jun 2011 23:49:26 +1000, Alex Ionescu <[email protected]>
wrote:
Oh, I do believe shitty software/installers do this.
Microsoft's technologies do not, however.
So use WIX/MSI, not NSI/InstallShield.
--
Best regards,
Alex Ionescu
On 2011-06-04, at 9:23 AM, Kamil Hornicek wrote:
I'm in charge of 40+ PCs running mostly XP at work. Believe me when I
tell you people do write their own code (or use the available API
incorrectly) for installers or some online activation bullshit. I came
across several installers/apps that were unable to detect or use our
proxy (we also use wpad for proxy autodiscovery via dns) and I always
had to connect that PC directly to our gateway to make stuff install
which is annoying as hell. I am not making this up, pay me a visit if
you think otherwise.
K.
----- Original Message ----- From: "Alex Ionescu" <[email protected]>
To: "ReactOS Development List" <[email protected]>
Sent: Friday, June 03, 2011 8:20 PM
Subject: Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ...
Again all of this is irrelevant: since I think you are a Linux user, I
can understand why you are confused.
On Windows, all HTTP communication is done by WinHTTP and/or WinINET,
nobody writes their own custom socket code.
WinHTTP/WinINET control the proxy settings for the machine. In fact,
if you use Google Chrome on Windows (or Safari) and go to the
proxy/connection settings, you will see "IE's" proxy connection dialog
-- because these settings/dialog are owned by the OS Library, not the
individual applications.
Therefore, the installer will use 100% the same settings as the web
browser, including the same protocol.
So, as I stated, if the browser can download foo.exe, so will the
online installer.
--
Best regards,
Alex Ionescu
On 2011-06-03, at 1:50 PM, Kamil Hornicek wrote:
whatever you use for downloading the installer has to be configured
to connect throught the proxy and also to use its dns services for
host name resolving. if the installer itself isn't aware of the need
for proxy server (or is not able to connect through socks or whatever
the proxy uses) it won't be usually able to resolve the hostname it's
trying to connect to (depends on the exact network configuration).
also the default route to the internet would be missing or direct
outgoing connections would be blocked (which they usually are
otherwise you wouldn't be forced to use the proxy server in the first
place) so the traffic generated by the installer wouldn't have any
means to reach its destination.
I didn't want to derail the discussion and I apologize for that. I'll
shut up next time.
Kamil
----- Original Message ----- From: "Alex Ionescu"
<[email protected]>
To: "ReactOS Development List" <[email protected]>
Sent: Friday, June 03, 2011 7:03 PM
Subject: Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ...
Since online installers use HTTP, and the user got the installer off
HTTP, what would a proxy server change?
--
Best regards,
Alex Ionescu
On 2011-06-03, at 12:33 PM, Kamil Hornicek wrote:
I didn't want to spam this discussion but I have to.. What every
other software company also does is refusing to believe someone
might be behind a proxy server. If you go this way, please make
sure the installer doesn't need a direct connection. Also online
installers are generally a major pain in the ass if you don't
provide an offline installer too.
----- Original Message ----- From: Alex Ionescu
To: ReactOS Development List
Sent: Friday, June 03, 2011 5:56 PM
Subject: Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ...
Why separate installers for x64/ARM?
Just do what every software company this side of the century does:
a 400kb installer which lets you select the packages you want, and
downloads them.
--
Best regards,
Alex Ionescu
On 2011-06-03, at 11:38 AM, Zachary Gorden wrote:
Spoke with Amine and Daniel. I've agreed to the lesser evil of
bundling the FULL cmake. Reasons are if we want the BE to be
flexible enough to be used for more than just building ROS, we
can't gimp cmake with the belief that no one will need the things
we didn't include. This is again on Windows. I remain uninvolved
with decisions about the Linux BE.
On Fri, Jun 3, 2011 at 10:34 AM, Colin Finck <[email protected]>
wrote:
Timo Kreuzer <[email protected]> wrote:
My vote on this:
CMake: bundle it, optional on installation
x64/arm: create individual installers
* CMake: bundle it, go for the (minimal) version without an
installer. It's nothing "exotic" to install after all, just put it
together with the other utilities in RosBE.
* x64/arm: If build tool sizes are staying like this, create
individual installers. Just for testing, I'll try an x86/x64
multilib build of Binutils and GCC though, would be nice to know
how much smaller it is compared to separate x86 and x64 compilers.
So in general, I agree with Timo :-)
- Colin
_______________________________________________
Ros-dev mailing list
[email protected]
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
[email protected]
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
[email protected]
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
[email protected]
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
[email protected]
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
[email protected]
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
[email protected]
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
[email protected]
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
[email protected]
http://www.reactos.org/mailman/listinfo/ros-dev
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
Ros-dev mailing list
[email protected]
http://www.reactos.org/mailman/listinfo/ros-dev
