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 <[email protected]> 
> 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 <[email protected]> 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 <[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
>>> 
> 
> 
> -- 
> 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


_______________________________________________
Ros-dev mailing list
[email protected]
http://www.reactos.org/mailman/listinfo/ros-dev

Reply via email to