Adam... ReactOS will not be Win Vista/7 ;)
On Sat, Jun 4, 2011 at 8:05 PM, Adam geekdundee@gmail.com wrote:
And what about people with computers older than 2007 and/or people who do not want to (and/or cannot) pay $$$ for an upgrade and/or people who do not want to install an operating system that takes up 15GB of disk space?
On Sun, 05 Jun 2011 03:59:46 +1000, Alex Ionescu ionucu@videotron.ca wrote:
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@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@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@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@videotron.ca> > To: "ReactOS Development List" ros-dev@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@videotron.ca >>> > >>> To: "ReactOS Development List" ros-dev@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@reactos.org >>>>> wrote: >>>>> >>>>> Timo Kreuzer timo.kreuzer@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@reactos.org >>>>> http://www.reactos.org/mailman/listinfo/ros-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ros-dev mailing list >>>>> Ros-dev@reactos.org >>>>> http://www.reactos.org/mailman/listinfo/ros-dev >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ros-dev mailing list >>>>> Ros-dev@reactos.org >>>>> http://www.reactos.org/mailman/listinfo/ros-dev >>>>> >>>>> _______________________________________________ >>>>> Ros-dev mailing list >>>>> Ros-dev@reactos.org >>>>> http://www.reactos.org/mailman/listinfo/ros-dev >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Ros-dev mailing list >>>> Ros-dev@reactos.org >>>> http://www.reactos.org/mailman/listinfo/ros-dev >>>> >>>> >>> >>> _______________________________________________ >>> Ros-dev mailing list >>> Ros-dev@reactos.org >>> http://www.reactos.org/mailman/listinfo/ros-dev >>> >>> >> >> _______________________________________________ >> Ros-dev mailing list >> Ros-dev@reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >> >> > > _______________________________________________ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > >
Ros-dev mailing list Ros-dev@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@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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev