Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ...
"As far as I'm aware that is a start-on-demand service which only starts up if you run a MSI installer" i confirm this On Fri, Jun 3, 2011 at 2:24 AM, Zachary Gorden wrote: > I intend to package the BE so that you have one installer for the various > platform targets instead of the current three installers we have right now. > I am not familiar enough with NSIS to know why Daniel did not do this, > though from his complaining I got the impression he didn't try to get any > fancier with the NSIS installer because he didn't want to go through the > trouble of futzing with it. One could argue that since we need little > beyond installing files and making sure that an uninstallation actually > cleans up the files and shortcuts, the best option is MSI since an MSI > installer actually registers with the OS the things that need to be cleaned > up when an application is to be uninstalled. > > Also a correction to your comment about the MSI service. As far as I'm > aware that is a start-on-demand service which only starts up if you run a > MSI installer. It'll hang around for a bit afterward, but then turns itself > off if you don't run another installer for a while. > > > On Thu, Jun 2, 2011 at 5:11 PM, Adam wrote: > >> Fair enough, but does RosBE actually do anything (installer-wise) other >> than install its files in a directory and set the occasional environment >> variable (PATH) - if this is the case, surely any installer (be it NSIS, >> Inno Setup, MSI, etc) can do this. >> >> >> On Fri, 03 Jun 2011 08:03:07 +1000, Zachary Gorden < >> drakekaizer...@gmail.com> wrote: >> >> The amount of functionality that MSIs offer comes with a price. Some of >>> us >>> believe it is worth it. Some don't. We, meaning Daniel and myself, want >>> a >>> MSI installer. If someone else wants to maintain the NSIS installer, we >>> will not stop them. We just won't offer any help doing so since we >>> (Daneil >>> and myself) want a MSI installer. >>> >>> On Thu, Jun 2, 2011 at 4:55 PM, Adam wrote: >>> >>> So having a service running all the time just to install programs, and having to not be able to uninstall a program cleanly if the MSI file has been moved/deleted (or if the MSI file that was copied into some obscure place in the %SYSTEMROOT% path) or due to some other sort of failure, provides an error, is clean is it? Not to mention it will be impossible to uninstall in Safe Mode (should it be necessary) since MSIEXEC refuses to run under Safe Mode these days. Never tried WiX before, but the problem wouldn't be WiX - it would be MSIEXEC and the way it works. On Fri, 03 Jun 2011 07:35:56 +1000, Ged Murphy wrote: Are you serious? Have you ever used WiX in a serious capacity? > It's far superior to NSIS in pretty much every way. > > > On 2 June 2011 22:18, Adam wrote: > > I do not like the idea of moving to Windows Installer for RosBE 2.0 - >> it >> can >> be quite tedious to clean up if the install is half done. IMO the >> original >> installer (NSIS) is much more cleaner than Windows Installer too. >> >> If it ain't broke don't fix it I say. >> >> On Fri, 03 Jun 2011 06:52:17 +1000, Colin Finck >> wrote: >> >> drei...@svn.reactos.org wrote: >> >>> > if not exist "CMakeLists.txt" ( >>> >>> Can we decide on dropping support for rbuild stuff in RosBE 2.0? >>> Reasons: >>> >>> - RosBE 2.0 will certainly come with an updated set of build tools. >>> (GCC 4.6 with mingw-w64 target is planned, maybe even a multilib >>> version) >>> The target change already makes older builds uncompilable with RosBE >>> 2.0. Even if this would be fixed, nobody would guarantee you that a >>> revision built with RosBE 2.0 behaves the same as one compiled with >>> 1.5.x. >>> - Several versions of RosBE can be installed parallely, especially if >>> you're also moving to a Windows Installer for RosBE 2.0, which >>> doesn't >>> care about Uninstall entries of NSIS. So everybody has the option >>> to build older rbuild-powered revisions at any time. >>> - It could make all scripts cleaner again :-) >>> >>> Regards, >>> >>> Colin >>> >>> ___ >>> 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 > > -- >>>
Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ...
Am 03.06.2011 02:24, schrieb Zachary Gorden: I intend to package the BE so that you have one installer for the various platform targets instead of the current three installers we have right now. You are aware that 14 MB + 16 MB + 11 MB = 41 MB ? I really see no point in bundling them all together. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ...
lol, ROS is ~41MB too On Fri, Jun 3, 2011 at 9:21 AM, Timo Kreuzer wrote: > Am 03.06.2011 02:24, schrieb Zachary Gorden: > > I intend to package the BE so that you have one installer for the various >> platform targets instead of the current three installers we have right now. >> > You are aware that 14 MB + 16 MB + 11 MB = 41 MB ? > I really see no point in bundling them all together. > > > > > ___ > 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
Re: [ros-dev] [ros-diffs] [pschweitzer] 52065: [NTOSKRNL] - renamed Io volumes global to match Windows names (in case of debug) - renamed IopDereferenceVpb() to IopDereferenceVpbAndFree(), IopReferenc
Do you even understand what hes talking to himself about? Perhaps you should refrain from commenting until you do. From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On Behalf Of Javier Agustìn Fernàndez Arroyo Sent: 02 June 2011 20:18 To: ReactOS Development List Cc: ros-di...@reactos.org Subject: Re: [ros-dev] [ros-diffs] [pschweitzer] 52065: [NTOSKRNL] - renamed Io volumes global to match Windows names (in case of debug) - renamed IopDereferenceVpb() to IopDereferenceVpbAndFree(), IopReferenceVpbForVerify() to IopR... i love the way you talk with yourself :P On Thu, Jun 2, 2011 at 8:02 PM, Alex Ionescu wrote: Same comment as before, resources MUST be acquired within a critical region (as the old code did). -- Best regards, Alex Ionescu On 2011-06-02, at 1:43 PM, pschweit...@svn.reactos.org wrote: > /* Acquire the FS lock */ > -KeEnterCriticalRegion(); > -ExAcquireResourceExclusiveLite(&FileSystemListLock, TRUE); > +ExAcquireResourceExclusiveLite(&IopDatabaseResource, TRUE); ___ 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
Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ...
I am sure the blokes at Microsoft Corporation and Adobe think in similar ways. :) On Fri, 03 Jun 2011 17:33:08 +1000, Javier Agustìn Fernàndez Arroyo wrote: lol, ROS is ~41MB too On Fri, Jun 3, 2011 at 9:21 AM, Timo Kreuzer wrote: Am 03.06.2011 02:24, schrieb Zachary Gorden: I intend to package the BE so that you have one installer for the various platform targets instead of the current three installers we have right now. You are aware that 14 MB + 16 MB + 11 MB = 41 MB ? I really see no point in bundling them all together. ___ 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
Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ...
I can't think of any advantages of packaging them together. It actually sounds more confusing that helpful. -Original Message- From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On Behalf Of Timo Kreuzer Sent: 03 June 2011 08:22 To: ReactOS Development List Subject: Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ... Am 03.06.2011 02:24, schrieb Zachary Gorden: > I intend to package the BE so that you have one installer for the > various platform targets instead of the current three installers we > have right now. You are aware that 14 MB + 16 MB + 11 MB = 41 MB ? I really see no point in bundling them all together. ___ 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
Re: [ros-dev] 1296 [dreimer] Get the cmake path from a system variable called _ROSBE_CMAKEPATH. Hard coding is eeevul!
Zachary Gorden wrote: I object highly to the idea of bundling cmake with the BE. Most platforms already have binaries built of cmake, either by the distro or for Windows, the people who make cmake provide an installer. I don't see the point here, you could say exactly the same about every tool we bundle. We provide the compilers and linkers and we provided rbuildbecause it was our own thing, but cmake is not and has its own environment. There are also easily installable third-party MinGW environments, but this is not the point. RosBE started as a project to bundle all build tools (always including GNU Make by the way), even when we didn't need our own specially patched versions yet. This is precisely why ReactOS is one of the easiest operating systems to compile and we can have 5-minute tutorials like this: http://www.youtube.com/watch?v=jnt7s2zEZFo On top of this, it allows us to have comparable builds between all developers, because we can be sure that they use the very same tools. I don't want to spend nights of debugging if problems are suddenly caused by using different CMake versions. I'm very reluctant to drop these fundamental ideas behind RosBE. They have certainly saved every ReactOS developer much time. - Colin ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ...
Of course, one could always provide functionality (within the installer) to download the optional components. That way the user doesn't have to download a 41MB file if he/she doesn't want to. No need to pack them up into one installer IMO IIRC a lot of installers support this, and I've seen this kind of thing in Windows installers as well as NSIS and some other installers. Something like the way the MinGW GUI installer works. On Fri, 03 Jun 2011 17:40:58 +1000, Ged Murphy wrote: I can't think of any advantages of packaging them together. It actually sounds more confusing that helpful. -Original Message- From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On Behalf Of Timo Kreuzer Sent: 03 June 2011 08:22 To: ReactOS Development List Subject: Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ... Am 03.06.2011 02:24, schrieb Zachary Gorden: I intend to package the BE so that you have one installer for the various platform targets instead of the current three installers we have right now. You are aware that 14 MB + 16 MB + 11 MB = 41 MB ? I really see no point in bundling them all together. ___ 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
Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ...
When I say wix, I mean windows installer. The two have become synonymous for me now. Much of what you say isn't true. The only issue I've ever come across with msi's is that failed installs can lead to the database becoming corrupt. However this is very rare and can be repaired in various ways. I get the feeling people use NSIS because it's open source and that must mean it's better/cooler. I prefer to look at the merits of both open and closed and choose the best. In 99% of cases, closed source comes out on top. -Original Message- From: Adam [mailto:geekdun...@gmail.com] Sent: 02 June 2011 22:55 To: ReactOS Development List; Ged Murphy Subject: Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ... So having a service running all the time just to install programs, and having to not be able to uninstall a program cleanly if the MSI file has been moved/deleted (or if the MSI file that was copied into some obscure place in the %SYSTEMROOT% path) or due to some other sort of failure, provides an error, is clean is it? Not to mention it will be impossible to uninstall in Safe Mode (should it be necessary) since MSIEXEC refuses to run under Safe Mode these days. Never tried WiX before, but the problem wouldn't be WiX - it would be MSIEXEC and the way it works. On Fri, 03 Jun 2011 07:35:56 +1000, Ged Murphy wrote: > Are you serious? Have you ever used WiX in a serious capacity? > It's far superior to NSIS in pretty much every way. > > > On 2 June 2011 22:18, Adam wrote: >> I do not like the idea of moving to Windows Installer for RosBE 2.0 - >> it can >> be quite tedious to clean up if the install is half done. IMO the >> original >> installer (NSIS) is much more cleaner than Windows Installer too. >> >> If it ain't broke don't fix it I say. >> >> On Fri, 03 Jun 2011 06:52:17 +1000, Colin Finck >> wrote: >> >>> drei...@svn.reactos.org wrote: >>> > if not exist "CMakeLists.txt" ( >>> >>> Can we decide on dropping support for rbuild stuff in RosBE 2.0? >>> Reasons: >>> >>> - RosBE 2.0 will certainly come with an updated set of build tools. >>> (GCC 4.6 with mingw-w64 target is planned, maybe even a multilib >>> version) >>> The target change already makes older builds uncompilable with RosBE >>> 2.0. Even if this would be fixed, nobody would guarantee you that a >>> revision built with RosBE 2.0 behaves the same as one compiled with >>> 1.5.x. >>> - Several versions of RosBE can be installed parallely, especially if >>> you're also moving to a Windows Installer for RosBE 2.0, which >>> doesn't >>> care about Uninstall entries of NSIS. So everybody has the option >>> to build older rbuild-powered revisions at any time. >>> - It could make all scripts cleaner again :-) >>> >>> Regards, >>> >>> Colin >>> >>> ___ >>> 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
Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ...
On Fri, 03 Jun 2011 17:58:42 +1000, Ged Murphy wrote: When I say wix, I mean windows installer. The two have become synonymous for me now. Much of what you say isn't true. The only issue I've ever come across with msi's is that failed installs can lead to the database becoming corrupt. However this is very rare and can be repaired in various ways. Now the problem here is: will the end users be able to apply this easily without risk of damaging the other installs? I'm not suggesting attempting to fix such a problem will damage the other installs or the system, but are the repair methods clean? I get the feeling people use NSIS because it's open source and that must mean it's better/cooler. I prefer to look at the merits of both open and closed and choose the best. In 99% of cases, closed source comes out on top. I must admit I am not a big fan of their clumsy syntax myself. Inno Setup seems better to me. As for open sourcedness - IMO its only really useful if you have the tools to edit the source. Bottom line is that I agree with this. -Original Message- From: Adam [mailto:geekdun...@gmail.com] Sent: 02 June 2011 22:55 To: ReactOS Development List; Ged Murphy Subject: Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ... So having a service running all the time just to install programs, and having to not be able to uninstall a program cleanly if the MSI file has been moved/deleted (or if the MSI file that was copied into some obscure place in the %SYSTEMROOT% path) or due to some other sort of failure, provides an error, is clean is it? Not to mention it will be impossible to uninstall in Safe Mode (should it be necessary) since MSIEXEC refuses to run under Safe Mode these days. Never tried WiX before, but the problem wouldn't be WiX - it would be MSIEXEC and the way it works. On Fri, 03 Jun 2011 07:35:56 +1000, Ged Murphy wrote: Are you serious? Have you ever used WiX in a serious capacity? It's far superior to NSIS in pretty much every way. On 2 June 2011 22:18, Adam wrote: I do not like the idea of moving to Windows Installer for RosBE 2.0 - it can be quite tedious to clean up if the install is half done. IMO the original installer (NSIS) is much more cleaner than Windows Installer too. If it ain't broke don't fix it I say. On Fri, 03 Jun 2011 06:52:17 +1000, Colin Finck wrote: drei...@svn.reactos.org wrote: > if not exist "CMakeLists.txt" ( Can we decide on dropping support for rbuild stuff in RosBE 2.0? Reasons: - RosBE 2.0 will certainly come with an updated set of build tools. (GCC 4.6 with mingw-w64 target is planned, maybe even a multilib version) The target change already makes older builds uncompilable with RosBE 2.0. Even if this would be fixed, nobody would guarantee you that a revision built with RosBE 2.0 behaves the same as one compiled with 1.5.x. - Several versions of RosBE can be installed parallely, especially if you're also moving to a Windows Installer for RosBE 2.0, which doesn't care about Uninstall entries of NSIS. So everybody has the option to build older rbuild-powered revisions at any time. - It could make all scripts cleaner again :-) Regards, Colin ___ 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
Re: [ros-dev] [ros-diffs] [pschweitzer] 52065: [NTOSKRNL] - renamed Io volumes g
Hi, > The notification routine can change the list, as there is no lock involved. List is locked by the caller. Have a look to: IoRegisterFsRegistrationChange(). Regarding all your remarks: thank you! They have been used to fix code and commited in r52073. Regards, P. Schweitzer ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] 1296 [dreimer] Get the cmake path from a system variable called _ROSBE_CMAKEPATH. Hard coding is eeevul!
I am agree with Colin. The idea of having a Build Environment is not just to make the life easier to our devs, but also to have ISOs which we can compare. If the Environment doesnt bundle *ALL* the tools, then we can have devs/testers with different Tools combinations...it can lead to break walls with our head. Also we should try to do the compilation as easier as possible, why not creating RosBE 2.0 with GUI frontend? :3 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] 1296 [dreimer] Get the cmake path from a system variable called _ROSBE_CMAKEPATH. Hard coding is eeevul!
I wonder if the CMake Gui can be used here. Have had a bit of a play with it but I'm not sure how it is possible to make it friendly for RosBE users so they don't have to linux around with the config and all that. On Fri, 03 Jun 2011 20:26:58 +1000, victor martinez wrote: I am agree with Colin. The idea of having a Build Environment is not just to make the life easier to our devs, but also to have ISOs which we can compare. If the Environment doesnt bundle *ALL* the tools, then we can have devs/testers with different Tools combinations...it can lead to break walls with our head. Also we should try to do the compilation as easier as possible, why not creating RosBE 2.0 with GUI frontend? :3 -- 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
Re: [ros-dev] 1296 [dreimer] Get the cmake path from a system variable called _ROSBE_CMAKEPATH. Hard coding is eeevul!
Guess what... Cmake provides such a GUI Le 03/06/2011 12:26, victor martinez a écrit : I am agree with Colin. The idea of having a Build Environment is not just to make the life easier to our devs, but also to have ISOs which we can compare. If the Environment doesnt bundle *ALL* the tools, then we can have devs/testers with different Tools combinations...it can lead to break walls with our head. Also we should try to do the compilation as easier as possible, why not creating RosBE 2.0 with GUI frontend? :3 ___ 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
Re: [ros-dev] 1296 [dreimer] Get the cmake path from a system variable called _ROSBE_CMAKEPATH. Hard coding is eeevul!
Does Cmake provide a GUI which: 1)Updates the local copy to any desired revision? 2)Which changes the Architecture to build ReactOS for the current session? 3)Fully clean the source directory/logs? :) Date: Fri, 3 Jun 2011 12:32:41 +0200 From: jerome.gar...@laposte.net To: ros-dev@reactos.org Subject: Re: [ros-dev] 1296 [dreimer] Get the cmake path from a system variable called _ROSBE_CMAKEPATH. Hard coding is eeevul! Guess what... Cmake provides such a GUI Le 03/06/2011 12:26, victor martinez a écrit : I am agree with Colin. The idea of having a Build Environment is not just to make the life easier to our devs, but also to have ISOs which we can compare. If the Environment doesnt bundle *ALL* the tools, then we can have devs/testers with different Tools combinations...it can lead to break walls with our head. Also we should try to do the compilation as easier as possible, why not creating RosBE 2.0 with GUI frontend? :3 ___ 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
Re: [ros-dev] 1296 [dreimer] Get the cmake path from a system variable called _ROSBE_CMAKEPATH. Hard coding is eeevul!
Am 03.06.2011 12:31, schrieb Adam: I wonder if the CMake Gui can be used here. Have had a bit of a play with it but I'm not sure how it is possible to make it friendly for RosBE users so they don't have to linux around with the config and all that. I've been using the cmake gui quite often (especially before the configure script was there, and of course certain persons were telling me how lame I was, using a gui tool ;-)) and it works like a charm. Its also very useful, if you want to change configuration settings without changing cmake files in the sources or editing a huge config file. For the initial configuration, I think the configure script is the easiest. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] 1296 [dreimer] Get the cmake path from a system variable called _ROSBE_CMAKEPATH. Hard coding is eeevul!
victor martinez wrote: Does Cmake provide a GUI which: 1)Updates the local copy to any desired revision? 2)Which changes the Architecture to build ReactOS for the current session? 3)Fully clean the source directory/logs? I fear we would attract too many people from the sandbox if we ship RosBE with such a GUI. If you want to try or develop ReactOS, you simply need some skills. Just requiring basic command line skills for building a whole OS is already better than what similar projects offer. In any case, something like this shouldn't be considered for the very first CMake release of RosBE. We could maybe bundle the already available CMake GUI if there are more votes for it. But to be honest, I don't think it's that hard to use the command line for setting the few options we have. The rest of the building process happens there anyway. - Colin ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [pschweitzer] 52065: [NTOSKRNL] - renamed Io volumes g
Ah, I didn't see the caller. There's still the issue of the missing volatile. It's required to make sure there is strict ordering between the spinlock acquisition and the increment/decrement. -- Best regards, Alex Ionescu On 2011-06-03, at 4:46 AM, Pierre Schweitzer wrote: > Hi, > >> The notification routine can change the list, as there is no lock involved. > List is locked by the caller. Have a look to: > IoRegisterFsRegistrationChange(). > > Regarding all your remarks: thank you! They have been used to fix code and > commited in r52073. > > Regards, > P. Schweitzer > > ___ > 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
Re: [ros-dev] [ros-diffs] [pschweitzer] 52065: [NTOSKRNL] - renamed Io volumes g
Am 03.06.2011 13:24, schrieb Alex Ionescu: Ah, I didn't see the caller. There's still the issue of the missing volatile. It's required to make sure there is strict ordering between the spinlock acquisition and the increment/decrement. Ordering is guaranteed, since the spinlock functions act as memory barriers, otherwise a lot of our code wouldn't work. Suggested reading: http://kernel.org/doc/Documentation/volatile-considered-harmful.txt Regards, Timo ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ...
The user is able to select which ones they want to install. If they only want the x86 BE, they don't have to install the x64 or ARM BE. On Fri, Jun 3, 2011 at 3:14 AM, Adam wrote: > On Fri, 03 Jun 2011 17:58:42 +1000, Ged Murphy > wrote: > > When I say wix, I mean windows installer. The two have become synonymous >> for me now. >> >> Much of what you say isn't true. >> The only issue I've ever come across with msi's is that failed installs >> can lead to the database becoming corrupt. >> However this is very rare and can be repaired in various ways. >> > > Now the problem here is: will the end users be able to apply this easily > without risk of damaging the other installs? I'm not suggesting attempting > to fix such a problem will damage the other installs or the system, but are > the repair methods clean? > > > >> I get the feeling people use NSIS because it's open source and that must >> mean it's better/cooler. >> I prefer to look at the merits of both open and closed and choose the >> best. >> In 99% of cases, closed source comes out on top. >> > > I must admit I am not a big fan of their clumsy syntax myself. Inno Setup > seems better to me. As for open sourcedness - IMO its only really useful if > you have the tools to edit the source. Bottom line is that I agree with > this. > > > >> >> -Original Message- >> From: Adam [mailto:geekdun...@gmail.com] >> Sent: 02 June 2011 22:55 >> To: ReactOS Development List; Ged Murphy >> Subject: Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ... >> >> So having a service running all the time just to install programs, and >> having to not be able to uninstall a program cleanly if the MSI file has >> been moved/deleted (or if the MSI file that was copied into some obscure >> place in the %SYSTEMROOT% path) or due to some other sort of failure, >> provides an error, is clean is it? Not to mention it will be impossible to >> uninstall in Safe Mode (should it be necessary) since MSIEXEC refuses to >> run under Safe Mode these days. >> >> Never tried WiX before, but the problem wouldn't be WiX - it would be >> MSIEXEC and the way it works. >> >> On Fri, 03 Jun 2011 07:35:56 +1000, Ged Murphy >> wrote: >> >> Are you serious? Have you ever used WiX in a serious capacity? >>> It's far superior to NSIS in pretty much every way. >>> >>> >>> On 2 June 2011 22:18, Adam wrote: >>> I do not like the idea of moving to Windows Installer for RosBE 2.0 - it can be quite tedious to clean up if the install is half done. IMO the original installer (NSIS) is much more cleaner than Windows Installer too. If it ain't broke don't fix it I say. On Fri, 03 Jun 2011 06:52:17 +1000, Colin Finck wrote: drei...@svn.reactos.org wrote: > > if not exist "CMakeLists.txt" ( > > Can we decide on dropping support for rbuild stuff in RosBE 2.0? > Reasons: > > - RosBE 2.0 will certainly come with an updated set of build tools. > (GCC 4.6 with mingw-w64 target is planned, maybe even a multilib > version) > The target change already makes older builds uncompilable with RosBE > 2.0. Even if this would be fixed, nobody would guarantee you that a > revision built with RosBE 2.0 behaves the same as one compiled with > 1.5.x. > - Several versions of RosBE can be installed parallely, especially if > you're also moving to a Windows Installer for RosBE 2.0, which > doesn't > care about Uninstall entries of NSIS. So everybody has the option > to build older rbuild-powered revisions at any time. > - It could make all scripts cleaner again :-) > > Regards, > > Colin > > ___ > 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 > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] 1296 [dreimer] Get the cmake path from a system variable called _ROSBE_CMAKEPATH. Hard coding is eeevul!
After the chat with zwabbit yesterday i feared exactly this will happen. I think we have two ways to add cmake to RosBE. 1. Let the Installer load the setup and run it silently in the background. 2. Bundle a minimal Version. I dont really like the idea to make users be forced to load cmake from an external link and install it afterwards. So lets choose between these two ways. I agree, some ppl have a cmake version already installed, but this does not stop us to provide it for the rest in one or another way. Am 03.06.2011 13:16, schrieb Colin Finck: victor martinez wrote: Does Cmake provide a GUI which: 1)Updates the local copy to any desired revision? 2)Which changes the Architecture to build ReactOS for the current session? 3)Fully clean the source directory/logs? I fear we would attract too many people from the sandbox if we ship RosBE with such a GUI. If you want to try or develop ReactOS, you simply need some skills. Just requiring basic command line skills for building a whole OS is already better than what similar projects offer. In any case, something like this shouldn't be considered for the very first CMake release of RosBE. We could maybe bundle the already available CMake GUI if there are more votes for it. But to be honest, I don't think it's that hard to use the command line for setting the few options we have. The rest of the building process happens there anyway. - 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
Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ...
Am 03.06.2011 16:29, schrieb Zachary Gorden: The user is able to select which ones they want to install. If they only want the x86 BE, they don't have to install the x64 or ARM BE. I don't worry about installation size, but download size. and 99% of all users will never use any of these. My vote on this: CMake: bundle it, optional on installation x64/arm: create individual installers ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] 1296 [dreimer] Get the cmake path from a system variable called _ROSBE_CMAKEPATH. Hard coding is eeevul!
@Ged The user is able to choose which BEs they want to install, so if they only want the x86 BE, they can deselect the x64 or ARM "features." That's a pretty standard functionality of MSI after all. @Daniel If that's the route being taken, you're going to have to go with #2. You can't run 2 MSIs at the same time and figuring out a way of keeping track of the latest version of cmake is not worth the effort. And if we are going with #2, I'm going to insist it's a separate install "feature" so that does of us who already have cmake can avoid duplicate installs. I still object to cmake being bundled at all, especially if we go with some "minimalist" version. That basically severely limits the usage of cmake while in the BE environment to what we happen to have included, which is a step backward for the idea of using the BE as the foundation of a full fledged SDK. I highly doubt cmake, at least on different versions of their Windows release, will be the determining factor for reproducible builds. We're using different versions of cmake on different OSes at work here and generally cmake is not the cause of any build problems. On Fri, Jun 3, 2011 at 9:33 AM, Daniel Reimer wrote: > After the chat with zwabbit yesterday i feared exactly this will happen. I > think we have two ways to add cmake to RosBE. > > 1. Let the Installer load the setup and run it silently in the background. > 2. Bundle a minimal Version. > > I dont really like the idea to make users be forced to load cmake from an > external link and install it afterwards. So lets choose between these two > ways. I agree, some ppl have a cmake version already installed, but this > does not stop us to provide it for the rest in one or another way. > > Am 03.06.2011 13:16, schrieb Colin Finck: > > victor martinez wrote: >> >>> Does Cmake provide a GUI which: >>> 1)Updates the local copy to any desired revision? >>> 2)Which changes the Architecture to build ReactOS for the current >>> session? >>> 3)Fully clean the source directory/logs? >>> >> >> I fear we would attract too many people from the sandbox if we ship RosBE >> with such a GUI. If you want to try or develop ReactOS, you simply need some >> skills. Just requiring basic command line skills for building a whole OS is >> already better than what similar projects offer. >> >> In any case, something like this shouldn't be considered for the very >> first CMake release of RosBE. >> We could maybe bundle the already available CMake GUI if there are more >> votes for it. But to be honest, I don't think it's that hard to use the >> command line for setting the few options we have. The rest of the building >> process happens there anyway. >> >> >> - 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
Re: [ros-dev] 1296 [dreimer] Get the cmake path from a system variable called _ROSBE_CMAKEPATH. Hard coding is eeevul!
Am 03.06.2011 16:46, schrieb Zachary Gorden: @Ged The user is able to choose which BEs they want to install, so if they only want the x86 BE, they can deselect the x64 or ARM "features." That's a pretty standard functionality of MSI after all. Just to be clear, we are talking about 1,5 hours download time for people with a 56k modem. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] 1296 [dreimer] Get the cmake path from a system variable called _ROSBE_CMAKEPATH. Hard coding is eeevul!
The only developer I know who would be majorly impacted by increased BE download size is Eric. Eric, any comments on this topic? On Fri, Jun 3, 2011 at 10:03 AM, Timo Kreuzer wrote: > Am 03.06.2011 16:46, schrieb Zachary Gorden: > > @Ged The user is able to choose which BEs they want to install, so if they >> only want the x86 BE, they can deselect the x64 or ARM "features." That's a >> pretty standard functionality of MSI after all. >> >> Just to be clear, we are talking about 1,5 hours download time for people > with a 56k modem. > > > > ___ > 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
Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ...
Timo Kreuzer 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
Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ...
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 wrote: > Timo Kreuzer 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
Re: [ros-dev] [ros-diffs] [pschweitzer] 52065: [NTOSKRNL] - renamed Io volumes g
While the paper on Linux's spinlock semantics was very interesting, it remains the fact that this is not the case in Windows in this particular instance. A lot of ReactOS code *is* missing calls such as KeMemoryBarrier() and (volatile), and only works by chance, so the argument that "otherwise our code wouldn't work" is a bit of a fallacy. You also need to think outside the strict-ordering x86 box. Most of ReactOS' code is totally borked on IA64, PPC or ARM (and semi-broken on x64 too, which has looser ordering). Of course, feel free to ignore the suggestion. -- Best regards, Alex Ionescu On 2011-06-03, at 8:08 AM, Timo Kreuzer wrote: > Am 03.06.2011 13:24, schrieb Alex Ionescu: >> Ah, I didn't see the caller. >> >> There's still the issue of the missing volatile. It's required to make sure >> there is strict ordering between the spinlock acquisition and the >> increment/decrement. >> > Ordering is guaranteed, since the spinlock functions act as memory barriers, > otherwise a lot of our code wouldn't work. > Suggested reading: > http://kernel.org/doc/Documentation/volatile-considered-harmful.txt > > Regards, > Timo > > > ___ > 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
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 wrote: > Timo Kreuzer 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
Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ...
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 wrote: Timo Kreuzer 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
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 wrote: > > Timo Kreuzer 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
Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ...
just 1 more thing... if you choose to download modules optionally, please dont forget about users behind a proxy which requires authentication (im one of them at work :) ) On Fri, Jun 3, 2011 at 7:03 PM, Alex Ionescu wrote: > 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 wrote: > > > > Timo Kreuzer 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
Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ...
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" To: "ReactOS Development List" 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 wrote: Timo Kreuzer 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
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" > To: "ReactOS Development List" > 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 wrote: >>> >>> Timo Kreuzer 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 > > >
Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ...
thank you for your explanation, Alex, well, im both a Linux and Windows user, but i didnt know this. Its just i have got several apps that cannot work because of the issue i said above But, anywan, im ok now, and thank you so much On Fri, Jun 3, 2011 at 8:20 PM, Alex Ionescu wrote: > 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" > > To: "ReactOS Development List" > > 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 > wrote: > >>> > >>> Timo Kreuzer 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
Re: [ros-dev] [ros-diffs] [pschweitzer] 52065: [NTOSKRNL] - renamed Io volumes g
Am 03.06.2011 17:55, schrieb Alex Ionescu: While the paper on Linux's spinlock semantics was very interesting, it remains the fact that this is not the case in Windows in this particular instance. A lot of ReactOS code *is* missing calls such as KeMemoryBarrier() and (volatile), and only works by chance, so the argument that "otherwise our code wouldn't work" is a bit of a fallacy. You also need to think outside the strict-ordering x86 box. Most of ReactOS' code is totally borked on IA64, PPC or ARM (and semi-broken on x64 too, which has looser ordering). Of course, feel free to ignore the suggestion. -- Best regards, Alex Ionescu I won't ignore the suggestion. I'd rather try to convince you that its useless. Lets look at this particular instance. Irql = KeAcquireQueuedSpinLock(Queue); OldValue = (*Ulong)--; KeReleaseQueuedSpinLock(Queue, Irql); KeAcquireQueuedSpinLock is declared as: _DECL_HAL_KE_IMPORT KIRQL FASTCALL KeAcquireQueuedSpinLock( IN OUT KSPIN_LOCK_QUEUE_NUMBER Number); Thats really all we need to know. Its a fastcall function. Its not inline, but a function calls across the translation unit boundaries. This alone is enough to guarantee strict compiler ordering of memory accesses around the bounds of the call. The compiler cannot know what will happen inside the function that is being called, so it won't make any assumptions about reordering possibilities. See: http://publications.gbdirect.co.uk/c_book/chapter8/sequence_points.html MSDN: http://msdn.microsoft.com/en-us/library/d45c7a5d%28VS.80%29.aspx "Function-call operator. The function-call expression and all arguments to a function, including default arguments, are evaluated/*and all side effects completed*/ prior to entry to the function. There is no specified order of evaluation among the arguments or the function-call expression." Also described in the ansi-C standard, but pretty abstract: http://www.bsb.me.uk/ansi-c/ansi-c-one-file#sec_2_1_2_3 http://www.bsb.me.uk/ansi-c/ansi-c-one-file#sec_3_3_2_2 Regards, Timo ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [pschweitzer] 52065: [NTOSKRNL] - renamed Io volumes g
What about on UP, where a strong compiler will realize that the call only raises IRQL to dispatch, and since these apis are in NTOSKRNL, they might get in-lined or modified. On AMD64, raising the IRQL means only modifying cr8. So the function will become: OldIrql == __readcr8(); __writecr8(DISPATCH_LEVEL); inc dword ptr [reg]; __writecr8(OldIrql); Is ordering still guaranteed in this scenario? -- Best regards, Alex Ionescu On 2011-06-03, at 3:35 PM, Timo Kreuzer wrote: > Am 03.06.2011 17:55, schrieb Alex Ionescu: >> >> While the paper on Linux's spinlock semantics was very interesting, it >> remains the fact that this is not the case in Windows in this particular >> instance. >> >> A lot of ReactOS code *is* missing calls such as KeMemoryBarrier() and >> (volatile), and only works by chance, so the argument that "otherwise our >> code wouldn't work" is a bit of a fallacy. >> >> You also need to think outside the strict-ordering x86 box. Most of ReactOS' >> code is totally borked on IA64, PPC or ARM (and semi-broken on x64 too, >> which has looser ordering). >> >> Of course, feel free to ignore the suggestion. >> >> -- >> Best regards, >> Alex Ionescu >> > > I won't ignore the suggestion. I'd rather try to convince you that its > useless. > Lets look at this particular instance. > > Irql = KeAcquireQueuedSpinLock(Queue); > OldValue = (*Ulong)--; > KeReleaseQueuedSpinLock(Queue, Irql); > > KeAcquireQueuedSpinLock is declared as: > > _DECL_HAL_KE_IMPORT > KIRQL > FASTCALL > KeAcquireQueuedSpinLock( > IN OUT KSPIN_LOCK_QUEUE_NUMBER Number); > > Thats really all we need to know. Its a fastcall function. Its not inline, > but a function calls across the translation unit boundaries. This alone is > enough to guarantee strict compiler ordering of memory accesses around the > bounds of the call. > The compiler cannot know what will happen inside the function that is being > called, so it won't make any assumptions about reordering possibilities. > > See: > http://publications.gbdirect.co.uk/c_book/chapter8/sequence_points.html > > MSDN: http://msdn.microsoft.com/en-us/library/d45c7a5d%28VS.80%29.aspx > "Function-call operator. The function-call expression and all arguments to a > function, including default arguments, are evaluated and all side effects > completed prior to entry to the function. There is no specified order of > evaluation among the arguments or the function-call expression." > > Also described in the ansi-C standard, but pretty abstract: > http://www.bsb.me.uk/ansi-c/ansi-c-one-file#sec_2_1_2_3 > http://www.bsb.me.uk/ansi-c/ansi-c-one-file#sec_3_3_2_2 > > Regards, > Timo > > ___ > 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
Re: [ros-dev] 1296 [dreimer] Get the cmake path from a system variable called _R
For all not-so-techie guys who want to start building and possibly develop ReactOS and for many testers it's important to keep it super-simple, RosBE is just so simple anyone can get started and it's not threatning at all. This is really important in my opinion. I also follow the Contiki OS, they also have a development suite, but it is a VMware Player image of the size of more then 2GB To include Ubuntu + build tools and utilities, that is heavy and mega crippled. I also insist on one RosBE including all needed portions of the building environment. I also would like to see some util for translators to make that easy. I would like something like RosTE too, a one installation package including a Test Environment with VM automatic iso downloader, debug-tools and such. ReactOS is supposed to be easy, keep it that way. /Jaix Bly Jan Blomqvist Kinander "ReactOS Development List" wrote on Fri, June 3rd, 2011, 9:42 AM: > Zachary Gorden wrote: > > I object highly to the idea of bundling cmake with the BE. Most > > platforms already have binaries built of cmake, either by the distro or > > for Windows, the people who make cmake provide an installer. > > I don't see the point here, you could say exactly the same about every > tool we bundle. > > > > We provide the compilers and linkers and we provided rbuildbecause it was > > our own > > thing, but cmake is not and has its own environment. > > There are also easily installable third-party MinGW environments, but > this is not the point. > RosBE started as a project to bundle all build tools (always including > GNU Make by the way), even when we didn't need our own specially patched > versions yet. This is precisely why ReactOS is one of the easiest > operating systems to compile and we can have 5-minute tutorials like > this: http://www.youtube.com/watch?v=jnt7s2zEZFo > > On top of this, it allows us to have comparable builds between all > developers, because we can be sure that they use the very same tools. > I don't want to spend nights of debugging if problems are suddenly > caused by using different CMake versions. > > I'm very reluctant to drop these fundamental ideas behind RosBE. They > have certainly saved every ReactOS developer much time. > > > - 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
Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ...
I suggest doing like many other, have one standard 400k installer but one fully packad exe as well, for the ones having troubble. /Jaix Bly "ReactOS Development List" wrote on Fri, June 3rd, 2011, 7:44 PM: > just 1 more thing... > > if you choose to download modules optionally, please dont forget about users > behind a proxy which requires authentication (im one of them at work :) > ) > > On Fri, Jun 3, 2011 at 7:03 PM, Alex Ionescu wrote: > > > 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 wrote: > > > > > > Timo Kreuzer 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
Re: [ros-dev] [ros-diffs] [pschweitzer] 52065: [NTOSKRNL] - renamed Io volumes g
Am 03.06.2011 21:48, schrieb Alex Ionescu: What about on UP, where a strong compiler will realize that the call only raises IRQL to dispatch, and since these apis are in NTOSKRNL, they might get in-lined or modified. This would only happen, if the function is either delcared as inline or inside the same translation unit. Both of that is not the case here. If it was the case (say we inlined KeAcquireQueuedSpinLock) then we would need to add an explicit memory barrier to that inline function. On AMD64, raising the IRQL means only modifying cr8. So the function will become: OldIrql == __readcr8(); __writecr8(DISPATCH_LEVEL); inc dword ptr [reg]; __writecr8(OldIrql); Is ordering still guaranteed in this scenario? No, not in this case. (Which is IMO a bad definition of KeRaiseIrql or a bad implementation of __writecr8) But how does the use of volatile fix this? It doesn't! MSDN says about volatile objects: "A write to a volatile object (volatile write) has Release semantics; a reference to a global or static object that occurs before a write to a volatile object in the instruction sequence will occur before that volatile write in the compiled binary." But we would need release + acquire semantics. and even then it wouldn't guarantee that __writecr8() is considered "reference to a global or static object". And gcc might even behave different. Luckily at least all Spinlock functions have an implicit memory barrier and are thus not prone to this problem. So instead of adding volatile here and there and random places or even to all shared data structures, we need to make sure, we stick to some locking rules, which would mean not to expect KeRaiseIrql() to provide an implicit memory barrier and to make sure all inlined spinlock functions will have a proper memory barrier. Regards, Timo ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [nyadav] 52076: [AUDSRV] finish upto actual mixing functions
Can you use the reactos / ansi coding standard.
This code is almost unreadable, which makes it very difficult to review
On 3 June 2011 22:41, wrote:
> Author: nyadav
> Date: Fri Jun 3 21:41:26 2011
> New Revision: 52076
>
> URL: http://svn.reactos.org/svn/reactos?rev=52076&view=rev
> Log:
> [AUDSRV] finish upto actual mixing functions
>
> Added:
> branches/nyadav-audio-branch/base/services/audsrv/mixer.c (with props)
> Modified:
> branches/nyadav-audio-branch/base/services/audsrv/CMakeLists.txt
> branches/nyadav-audio-branch/base/services/audsrv/audsrv.c
> branches/nyadav-audio-branch/base/services/audsrv/audsrv.h
> branches/nyadav-audio-branch/base/services/audsrv/rpc.c
> branches/nyadav-audio-branch/base/services/audsrv/stream.c
> branches/nyadav-audio-branch/dll/win32/audsrvapi/audsrvapi.c
> branches/nyadav-audio-branch/dll/win32/audsrvapi/audsrvapi.spec
>
> branches/nyadav-audio-branch/drivers/wdm/audio/backpln/audclient/audclient.c
> branches/nyadav-audio-branch/include/reactos/idl/audsrvrpc.idl
> branches/nyadav-audio-branch/include/reactos/libs/audsrv/audsrvapi.h
>
> Modified: branches/nyadav-audio-branch/base/services/audsrv/CMakeLists.txt
> URL:
> http://svn.reactos.org/svn/reactos/branches/nyadav-audio-branch/base/services/audsrv/CMakeLists.txt?rev=52076&r1=52075&r2=52076&view=diff
> ==
> --- branches/nyadav-audio-branch/base/services/audsrv/CMakeLists.txt
> [iso-8859-1] (original)
> +++ branches/nyadav-audio-branch/base/services/audsrv/CMakeLists.txt
> [iso-8859-1] Fri Jun 3 21:41:26 2011
> @@ -7,6 +7,7 @@
> audsrv.c
> audsrv.rc
> rpc.c
> + mixer.c
> stream.c)
>
> add_executable(audsrv ${SOURCE})
>
> Modified: branches/nyadav-audio-branch/base/services/audsrv/audsrv.c
> URL:
> http://svn.reactos.org/svn/reactos/branches/nyadav-audio-branch/base/services/audsrv/audsrv.c?rev=52076&r1=52075&r2=52076&view=diff
> ==
> --- branches/nyadav-audio-branch/base/services/audsrv/audsrv.c [iso-8859-1]
> (original)
> +++ branches/nyadav-audio-branch/base/services/audsrv/audsrv.c [iso-8859-1]
> Fri Jun 3 21:41:26 2011
> @@ -41,6 +41,7 @@
> const GUID KSMEDIUMSETID_Standard = {0x4747B320L, 0x62CE,
> 0x11CF, {0xA5, 0xD6, 0x28, 0xDB, 0x04, 0xC1, 0x00, 0x00}};
> const GUID KSDATAFORMAT_TYPE_AUDIO = {0x73647561L, 0x,
> 0x0010, {0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}};
> const GUID KSDATAFORMAT_SUBTYPE_PCM = {0x0001L, 0x,
> 0x0010, {0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}};
> +const GUID KSDATAFORMAT_SUBTYPE_IEEE_FLOAT = {0x0003L, 0x,
> 0x0010, {0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}};
> const GUID KSDATAFORMAT_SPECIFIER_WAVEFORMATEX = {0x05589f81L, 0xc356,
> 0x11ce, {0xbf, 0x01, 0x00, 0xaa, 0x00, 0x55, 0x59, 0x5a}};
>
> MixerEngine engine,*pengine;
> @@ -152,24 +153,31 @@
>
>
>
> -
> -void fill(MixerEngine * mixer,int buffer)
> -{
> - DWORD Length;
> - UINT i = 0;
> -Sleep(100);
> - Length = mixer->masterfreq * mixer->masterchannels *
> mixer->masterbitspersample / 8;
> - mixer->masterbuf[buffer] = (PSHORT)HeapAlloc(GetProcessHeap(), 0,
> Length);
> - while (i < Length / 2)
> - {
> - mixer->masterbuf[buffer][i] = 0x7FFF * sin(0.5 * (i - 1) * 500 *
> _2pi / 48000);
> - i++;
> - mixer->masterbuf[buffer][i] = 0x7FFF * sin(0.5 * (i - 2) * 500 *
> _2pi / 48000);
> - i++;
> - }
> - mixer->bytes_to_play = Length;
> -}
> -
> +void mixandfill(MixerEngine * mixer,int buffer)
> +{
> +
> while(WaitForSingleObject(mixer->streampresent,100)!=0){if(mixer->dead)
> return;} /*Check if there is at least one stream present.*/
> + if(mixer->masterdatatype == 0)/*signed int*/
> + {
> + if(mixer->masterbitspersample == 8)mixs8(mixer,buffer);else
> if(mixer->masterbitspersample == 16) mixs16(mixer,buffer);else
> if(mixer->masterbitspersample == 32) mixs32(mixer,buffer);else
> if(mixer->masterbitspersample == 64) mixs64(mixer,buffer);
> + }
> + else if (mixer->masterdatatype == 1)/*unsigned int*/
> + {
> + if(mixer->masterbitspersample == 8)mixu8(mixer,buffer);else
> if(mixer->masterbitspersample == 16) mixu16(mixer,buffer);else
> if(mixer->masterbitspersample == 32) mixu32(mixer,buffer);else
> if(mixer->masterbitspersample == 64) mixu64(mixer,buffer);
> + }
> + else if(mixer->masterdatatype == 2)/*Float*/
> + {
> + if(mixer->masterbitspersample ==
> 32)mixfl32(mixer,buffer);else if(mixer->masterbitspersample == 64)
> mixfl64(mixer,buffer);
> + }
> +
> + mixer->masterbuf[buffer] = HeapAlloc(GetProcessHeap(), 0,
> mixer->serverstreamlist->length_filtered);
> +
> CopyMemory(mixer->masterbuf[buffer],mixer->serverstreamlist->filt
Re: [ros-dev] [ros-diffs] [pschweitzer] 52065: [NTOSKRNL] - renamed Io volumes g
On 2011-06-03, at 5:31 PM, Timo Kreuzer wrote:
>
> Am 03.06.2011 21:48, schrieb Alex Ionescu:
>> What about on UP, where a strong compiler will realize that the call only
>> raises IRQL to dispatch, and since these apis are in NTOSKRNL, they might
>> get in-lined or modified.
> This would only happen, if the function is either delcared as inline or
> inside the same translation unit. Both of that is not the case here.
> If it was the case (say we inlined KeAcquireQueuedSpinLock) then we would
> need to add an explicit memory barrier to that inline function.
This isn't true -- a modern optimizing compiler uses link-time code generation
which crosses compilation units and inline semantics.
For example, in Windows 7, this function stores the address of the addend in
ESI, and all callers move the address in ESI prior. Completely different from
how it's defined in source, but the result of LTGC.
>
>
>>
>> On AMD64, raising the IRQL means only modifying cr8.
>>
>> So the function will become:
>>
>> OldIrql == __readcr8();
>> __writecr8(DISPATCH_LEVEL);
>> inc dword ptr [reg];
>> __writecr8(OldIrql);
>>
>> Is ordering still guaranteed in this scenario?
> No, not in this case. (Which is IMO a bad definition of KeRaiseIrql or a bad
> implementation of __writecr8)
This is how KeRaiseIrql(DISPATCH_LEVEL) behaves on AMD64 it's an inline in
wdm.h, which I'll paste, since last time I quoted MSDN you said I was making
stuff up.
__forceinline
KIRQL
KfRaiseIrql (
__in KIRQL NewIrql
)
{
KIRQL OldIrql;
OldIrql = KeGetCurrentIrql();
NT_ASSERT(OldIrql <= NewIrql);
WriteCR8(NewIrql);
return OldIrql;
}
> But how does the use of volatile fix this? It doesn't!
> MSDN says about volatile objects:
> "A write to a volatile object (volatile write) has Release semantics; a
> reference to a global or static object that occurs before a write to a
> volatile object in the instruction sequence will occur before that volatile
> write in the compiled binary."
> But we would need release + acquire semantics. and even then it wouldn't
> guarantee that __writecr8() is considered "reference to a global or static
> object". And gcc might even behave different.
These are all good points.
>
> Luckily at least all Spinlock functions have an implicit memory barrier and
> are thus not prone to this problem.
But not in UP -- which is what ReactOS Builds as.
>
> So instead of adding volatile here and there and random places or even to all
> shared data structures, we need to make sure, we stick to some locking rules,
> which would mean not to expect KeRaiseIrql() to provide an implicit memory
> barrier and to make sure all inlined spinlock functions will have a proper
> memory barrier.
Fair enough, so then those should be fixed.
>
> Regards,
> Timo
>
>
>
> ___
> 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
Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ...
One issue I can think of with packing everything up together is that it will become 3 times the size of the original BE (you're now packing 3 copies there) and in addition if ReactOS wants to support more platforms, the Build Environment will grow so big it will *appear* to be bloated. At the same time however it means fewer installers to maintain, but to be honest I think that appears to be the only advantage in packing them all into one. On Sat, 04 Jun 2011 00:29:53 +1000, Zachary Gorden wrote: The user is able to select which ones they want to install. If they only want the x86 BE, they don't have to install the x64 or ARM BE. On Fri, Jun 3, 2011 at 3:14 AM, Adam wrote: On Fri, 03 Jun 2011 17:58:42 +1000, Ged Murphy wrote: When I say wix, I mean windows installer. The two have become synonymous for me now. Much of what you say isn't true. The only issue I've ever come across with msi's is that failed installs can lead to the database becoming corrupt. However this is very rare and can be repaired in various ways. Now the problem here is: will the end users be able to apply this easily without risk of damaging the other installs? I'm not suggesting attempting to fix such a problem will damage the other installs or the system, but are the repair methods clean? I get the feeling people use NSIS because it's open source and that must mean it's better/cooler. I prefer to look at the merits of both open and closed and choose the best. In 99% of cases, closed source comes out on top. I must admit I am not a big fan of their clumsy syntax myself. Inno Setup seems better to me. As for open sourcedness - IMO its only really useful if you have the tools to edit the source. Bottom line is that I agree with this. -Original Message- From: Adam [mailto:geekdun...@gmail.com] Sent: 02 June 2011 22:55 To: ReactOS Development List; Ged Murphy Subject: Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ... So having a service running all the time just to install programs, and having to not be able to uninstall a program cleanly if the MSI file has been moved/deleted (or if the MSI file that was copied into some obscure place in the %SYSTEMROOT% path) or due to some other sort of failure, provides an error, is clean is it? Not to mention it will be impossible to uninstall in Safe Mode (should it be necessary) since MSIEXEC refuses to run under Safe Mode these days. Never tried WiX before, but the problem wouldn't be WiX - it would be MSIEXEC and the way it works. On Fri, 03 Jun 2011 07:35:56 +1000, Ged Murphy wrote: Are you serious? Have you ever used WiX in a serious capacity? It's far superior to NSIS in pretty much every way. On 2 June 2011 22:18, Adam wrote: I do not like the idea of moving to Windows Installer for RosBE 2.0 - it can be quite tedious to clean up if the install is half done. IMO the original installer (NSIS) is much more cleaner than Windows Installer too. If it ain't broke don't fix it I say. On Fri, 03 Jun 2011 06:52:17 +1000, Colin Finck wrote: drei...@svn.reactos.org wrote: > if not exist "CMakeLists.txt" ( Can we decide on dropping support for rbuild stuff in RosBE 2.0? Reasons: - RosBE 2.0 will certainly come with an updated set of build tools. (GCC 4.6 with mingw-w64 target is planned, maybe even a multilib version) The target change already makes older builds uncompilable with RosBE 2.0. Even if this would be fixed, nobody would guarantee you that a revision built with RosBE 2.0 behaves the same as one compiled with 1.5.x. - Several versions of RosBE can be installed parallely, especially if you're also moving to a Windows Installer for RosBE 2.0, which doesn't care about Uninstall entries of NSIS. So everybody has the option to build older rbuild-powered revisions at any time. - It could make all scripts cleaner again :-) Regards, Colin ___ 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 -- 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
