4 Jun
2011
4 Jun
'11
5:59 p.m.
Update to Windows Vista+, which has KTM.
--
Best regards,
Alex Ionescu
On 2011-06-04, at 10:21 AM, Adam wrote:
A number of times (eg. .NET install/AV install) I have
had it happen at the end of the install. Then when I attempt to uninstall it there are
errors produced regarding it (often not just after a fresh install of Windows; I mean
after using the computer for some time - particularly after updating Windows Installer)
then it makes the product difficult (if not impossible) to uninstall.
On Sun, 05 Jun 2011 00:07:44 +1000, Zachary Gorden <drakekaizer666(a)gmail.com>
wrote:
And how many times does the database get
corrupted? I've never run into it
and the conditions that would cause a corruption would equally screw any
other installer, since it would have to be a run that got interrupted
mid-install.
On Sat, Jun 4, 2011 at 8:58 AM, Adam <geekdundee(a)gmail.com> wrote:
> 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 <ionucu(a)videotron.ca>
> 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"
<ionucu(a)videotron.ca>
>>> To: "ReactOS Development List" <ros-dev(a)reactos.org>
>>> 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"
<ionucu(a)videotron.ca
>>>>> >
>>>>> To: "ReactOS Development List" <ros-dev(a)reactos.org>
>>>>> 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
<colin(a)reactos.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Timo Kreuzer <timo.kreuzer(a)web.de> 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
>>>>>>> Ros-dev(a)reactos.org
>>>>>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Ros-dev mailing list
>>>>>>> Ros-dev(a)reactos.org
>>>>>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Ros-dev mailing list
>>>>>>> Ros-dev(a)reactos.org
>>>>>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Ros-dev mailing list
>>>>>>> Ros-dev(a)reactos.org
>>>>>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Ros-dev mailing list
>>>>>> Ros-dev(a)reactos.org
>>>>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Ros-dev mailing list
>>>>> Ros-dev(a)reactos.org
>>>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Ros-dev mailing list
>>>> Ros-dev(a)reactos.org
>>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> Ros-dev mailing list
>>> Ros-dev(a)reactos.org
>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>
>>
>>
>> _______________________________________________
>> Ros-dev mailing list
>> Ros-dev(a)reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>
>
> --
> Using Opera's revolutionary email client: http://www.opera.com/mail/
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev