When will 0.3.15 release?

[Z98]

The ReactOS project provides probably one of the better prepackaged development environments in the open source community. We provide a single package that includes all of the compilers, linkers, libraries, and build systems that are needed to compile ReactOS from scratch. Other projects give you a list of dependencies and tools and tell you to go find/install them yourself. If you're lucky, they'll mention gotchas associated with any manual configuration that is also liable to be needed. For example, look at Samba. Best of luck even figuring out what you need.

To claim that this project 'needs' Visual Studio support misses two points. First, debugging an operating system is not anything like debugging a normal application. The tools you have available are considerably more limited because you are trying to debug something that normally provides all the infrastructure for the fancy debugging functionality you get through something like VS. Not even Microsoft provided any sort of integration for kernel debugging into VS until VS2012, and even then they only support it when running on Windows 8. So what you're asking for is something that Microsoft has just barely worked out with all of their resources. And the lower you go in the software stack, the fewer tools you have available until you reach the point where you're lucky to have even console output. And as my day job involves BIOS development, I can attest to moments where I don't even get that because either someone broke console output or I'm in a module that is being loaded before console output has been enabled. In such situations, you need to roll up your sleeves and work your way through the problem instead of simply giving up just because all the crutches you were used to having have all been yanked out. Which leads to the second point, and from my perspective the more important one. I'm not even going to try to put this politely since that'll just make the point convoluted. Placing what boils down to workflow preconditions before a willingness to contribute speaks poorly of the skills and/or attitude of a programmer. If a programmer is so unwilling to move outside his/her comfort zone, that suggests a mental inflexibility that will not be conducive to attempting to solve many of the difficulties inherent in trying to develop an operating system. The ability to do something quickly in VS says nothing more than a programmer knows how to use VS. It is not indicative of a programmer's problem solving ability, and 90% of solving a programming problem is being able to find it in the first place. Many of the current developers have for a damn long time wanted VS support for the purposes of navigating the source code and a few others want MS toolchain support so that they can use MS' debugging infrastructure, but the lack of has not prevented them from making significant contributions to the project. Developing an OS is not something you do quickly. If you want to actually do it right, you need to be willing to commit large chunks of time and think through the problem without having it handed to you on a silver platter, cause at that point it'd be faster for a current dev to resolve the issue himself.

[fred02]

sort of integration for kernel debugging into VS until VS2012, and even then they only support it when running on Windows 8.

Sorry for an offtopic, but furthermore isn't debugging only supported of Seven SP1 kernel or later?
On the other hand, my understanding is that WinDbg supported kernel debugging since NT 4.0, at least, but, of course, it is totally separate from VS.

[Z98]

Hmm, that is correct. I must be thinking of something else that was restricted to only Windows 8.

[BlackRabbit]

Placing what boils down to workflow preconditions before a willingness to contribute speaks poorly of the skills and/or attitude of a programmer.

What a coincidence.

Five minutes before reading your post, Z98, I donated money to a particular United States organization. I had donated money many times to this organization over the past five years. I always paid by credit-card or electronic check. Just now, I got an email from that organization asking for a donation. I really like this organization, but I thought, I'd love to donate, but I do not feel like fighting with their donation payment system again. I was just about to delete their email, until I decided to try just one more time. The donation page was very pleasant this time. They added little fat green buttons, etc. It was utterly clear where to enter my information (which they had pre-populated this time) and it was quick. The point is that even though their previous donation page was obviously good enough (since I had donated many times before), they did even better. It was totally painless.

Why would someone make an obviously good-enough page, better? It is because they were probably thinking about all those donations that they lost in a split-second because someone thought...Not in the mood to fight with the donation page.

I disagree that the problem is the attitude of the programmer. If these were paid positions, there would be no problem. It would actually be fun to keep a bit of hacking in the process. But like the people who changed the donation page, I am not thinking about those who have the time to invest. I am thinking about the hordes who do not, but still will, if you make the barrier-to-contribution so ridiculously low that they no longer have any excuses. These people want to help ReactOS. I do agree that the programmer might be lesser-skilled. That's my point.

I'm saying that if you give a 10-year-old an axe, and let him hack at a tree, it might take the kid 12 times as long as his father to chop down that tree. But eventually, the tree will fall, and even though it took him forever, that one tree counts if:

• There are 15,000 trees.
• There are 5,000 10-year-old's.

If, however, the father says, Oh, yeah, the axe blade is dull, so it will get stuck a few times a day. Here, I will show you how to sharpen axe blades, and I will teach you about knots and how to read the bark of a tree to determine the side of maximum vulnerability, and how to look at the branches and determine the trajectory of fall, and...
...you will get the following situation:

• There are 15,000 trees.
• There are 50 adults who are all excellent lumberjacks, thinking about all of those 15,000 trees.

Finally, I want to be clear that I think ReactOS, as a whole, is simply outstanding, including the build process. I never thought there was anything wrong with the web-site, for example.

[Could someone please tell me how to use the editor to add the name of the author of a quote?]

[fireball]

Some things which were said here are right, some are not straightly right, however, as for "it always can be better and we should aim that" - I fully agree. There is no limit in perfection.


As for time of 0.3.15 release, the concept of point releases is really quite old. And considering the approach our Testing team spends on preparing a release, I don't really want this time to be wasted on testing and improving a bad release.
Some fundamental things need to be fixed first, and then a good release could happen.

There is little point in releasing 0.3.15 now, if it's always possible to download prebuilt ISO of the latest revision, accessible from the frontpage.

[ThePhysicist]

I 100% agree with what Z98 wrote above.

From all the software projects I have ever worked on or compiled (or tried to) myself, or even looked at the sources, both professional and non-professional, ReactOS has by far the most versatile (compile on linux, Windows, Mac, with gcc, clang, VS, WDK, using make, nmake, ninja, CodeBlocks, VisualStudio, WDK, debugging with KDBG, GDB, WinDbg) and most comfortable (just download ONE dedicated build environment and go. Or download 1 tool (Cmake) and use your MS compiler of choice. No manual configuring mess, no figuring out packet or header dependencies, nothing. Basically just 2 simple commands: configure, make/nmake/ninja/...) build system. And as for VS integration: it is more or less complete. The only drawback is that it will only support one language currently: english. Other than that it is 100% done. Yes, you can compile the entire project from the IDE if you like. And no, you will not be able to run it in the VS debugger. Use WinDbg. That's what it's for. Few years ago there was nothing else. And in 2 more years, what do you want? That you can remote debug with your iPhone from within facebook, while it keeps twittering the debug messages???

What we have created here is a fucking masterpiece and setting industry standards. Claiming it would be insufficient is an insult and a sign of complete cluelessness.

And regarding people who are not willing to develop, because they cannot use ONLY VS: Every developer who has ever done any kind of Windows kernel mode development knows how to use WinDbg. And if he's smart enough he is able to launch it and connect to the OS with a single click. If that is too uncomfortable for him, he's not a kernel developer at all. Look at linux guys. Their tools are by far worse. And yet a large number hack on the kernel.

What we REALLY need is a magic hat, where we can pull out 1000 code-rabbits that keep fixing bugs simply by hopping over a huge keyboard.

[hto]

Claiming it would be insufficient is an insult and a sign of complete cluelessness.

I don't think it should be insulting — actually, BlackRabbit tries to give you, the devs, some good suggestions…

Code: Select all

[quote="BlackRabbit"]
Could someone please tell me how to use the editor to add the name of the author of a quote?
[/quote]

[DOSGuy]

I think everybody is right! I certainly agree with BlackRabbit that you have to make things easy for your volunteers. At work, I'm forced to use some tools that I wouldn't choose to use otherwise. I have to use DB2 for some projects even though I would rather use PostgreSQL. Oh well, I'm getting paid! But if I was volunteering my time and the project forced me to use a language or tool that I don't like, I would be far less likely to contribute. I definitely have to disagree with Z98 on that point: it's not a lack of character or an attitude problem to choose your volunteer projects based on the tools you prefer to work with. Your time is your own and no one has a right to tell you how you should spend it, or what your priorities should be.

It also sounds, from ThePhysicist's description, that ReactOS already does an extremely good job of letting developers use whatever tool they want. So yay!

I guess that kind of ends that debate. So, as before, the answer to the original question is that there won't be a 0.3.15 until some important issues are resolved, and in the meantime, everyone is free to download the latest build if they want to see the progress that's been made since 0.3.14. Isn't it great when everything works out so well?

[fred02]

Hmm, that is correct. I must be thinking of something else that was restricted to only Windows 8.

Perhaps you were thinking about debugging over network? This seems to be 8-only feature.
Actually my point was that only debugging Seven's SP1 kernel or later is supported from VS2012. XP, 2003, Vista are not, so basically VS support brings nothing on the debugging side. Furthermore, I doubt that the debug protocol is open, so modifying ROS to support it would not be possible either.

Isn't it great when everything works out so well?

Totally agree.

[Z98]

If the lack of a familiar tool is enough to stop you from contributing to a project, then I am skeptical if you were ever actually that interested in the project. OS development is not application development. It comes with its own set of tools. To do any OS development means you need to use the available tools or write the tools yourself if they do not exist. That is the nature of the work. Not trying to use the available tools does not come off very well.

A desire to improve tools is perfectly fine. The project's team members have been systematically doing that over all the years the project has existed. To predicate your own participation on tool improvement however is not going to get one much sympathy, since it carries the implication that the work that has been done is not good enough for you. The claim that improved tooling will help development is a given, otherwise we would not have bothered with the CMake transition and Amine would not have bothered with all his work to get VS support to the point it is at. But he and the other devs that wanted these improvements actually took it upon themselves to bring those things to reality. To say that you or someone else will not participate until more is done does not endear one to the people who are already working on the project.

[DOSGuy]

In case there was any confusion, I wasn't suggesting that I would personally contribute to ReactOS if certain conditions were met. I have utterly no ability to contribute, as far as I know. I simply think that it is perfectly reasonable for any volunteer to choose to contribute or not contribute for any reason, and no one has a right to judge them for it. It would be different if it was an obligation, but volunteering never is.

I'm sorry that a moral/philosophical debate has distracted from the technical debate that I think was resolved rather nicely.

[BlackRabbit]

I guess I should clarify what I meant by using Visual Studio to do debugging. I meant debugging primarily ReactOS user-mode components as they execute inside a VM, while a host machine runs, say, Windows 7 and Visual Studio. During the edit/compile/link/deploy/execute/debug cycle, the ReactOS component (EXE/DLL/etc.) would be pushed from the host machine to the target VM where ReactOS is running, automatically, by Visual Studio, and launched, automatically, by Visual Studio. Then, breakpoints would be set in the Visual Studio source code on the host machine, and triggered as the executable executes on the target machine. I asked in IRC once if this is what is being done now, and I think the answer was "no", but I could be mistaken.

This feature would benefit lesser-skilled and/or time-constrained contributors.

[fred02]

During the edit/compile/link/deploy/execute/debug cycle, the ReactOS component (EXE/DLL/etc.) would be pushed from the host machine to the target VM where ReactOS is running, automatically, by Visual Studio, and launched, automatically, by Visual Studio. Then, breakpoints would be set in the Visual Studio source code on the host machine, and triggered as the executable executes on the target machine. I asked in IRC once if this is what is being done now, and I think the answer was "no", but I could be mistaken.

Is this even possible with a non Microsoft OS? Even on Windows only Seven SP1 or 8 are supported by VS2012. Have not looked for VS2010 and earlier.

[BlackRabbit]

Is this even possible with a non Microsoft OS? Even on Windows only Seven SP1 or 8 are supported by VS2012. Have not looked for VS2010 and earlier.

My first guess would be yes, because I have been using this technique since Visual Studio 2005, and the mechanism by which it is achieved on Windows is entirely based upon user-mode components.

In a nutshell:

• I use Visual Studio 2005/2008/2010/etc. on a source physical machine running Windows 7.
• I run either Windows XP, Windows Vista, or Windows 7 inside a target virtual machine. In some cases, I run Windows CE on a target physical machine or target virtual machine.
• I finish my edit/compile/link/deploy/execute/debug cycle by clicking the green Start Debugging (F5) arrow inside Visual Studio.
• On Windows CE, the deployment is done automatically, meaning, Visual Studio actually copies the newly-built EXE from the Windows 7 source machine to the Windows CE target machine at the moment that I hit the green Start Debugging (F5) arrow. I have a feeling this automatic-copy-from-source-to-target of the EXE can be achieved with a "Big Windows" source and a "Big Windows" target also, but I have not tried to do this yet. Typically what I do is configure Visual Studio on the source machine so that it attaches to the EXE on the target machine at the moment that I hit the green Start Debugging (F5) arrow, which means that the EXE on the target machine must be started manually before hitting Start Debugging (F5) .
• In both cases, automatic, or manual deployment, the key to actual debugging is MSVSMON.EXE. This is a small program that runs on the target physical or target virtual machine and lurks-in-wait to receive commands from Visual Studio on the source machine. Visual Studio tells it to load the EXE that is to be debugged by invoking CreateProcess against the EXE on the target machine. Visual Studio can also tell MSVSMON.EXE to attach to an already-executing process on the target machine.
• The mechanism by which MSVSMON.EXE attaches to a process is the Windows Debugger API.

With regard to ReactOS, there are some interesting facts:

• MSVSMON.EXE is a user-mode component.
• The Windows Debugger API is a user-mode component.
• MSVSMON.EXE uses the Windows Debugger API, and no kernel-mode code, to achieve debugging. I have copied MSVSMON.EXE and its associated DLL's to unstable Windows machines in moments of desperation to debug them. It works.
• ReactOS appears to have implemented the Windows Debugger API. See reactos\dll\win32\kernel32\debug.
• It is possible to write a debugger for Windows using only user-mode code. This, in fact, is the whole purpose of the Windows Debugger API, to facilitate writing a debugger application without having to implement any kernel-mode code.
• Because the Visual-Studio-To-MSVSMON.EXE control channel uses TCP, it is should be possible to debug a Windows application over the Internet. This is useful for those situations where a customer has a frustrating, hard-to-reproduce bug, One day, the debug manifests, and the customer immediately calls you on the phone, gives you IP address/etc., and you can start debugging that crashed application as it executes on the customer's machine right from within Visual Studio. I have never tried this, but I looked at the architecture, and I see no reason why it would not work.

[Black_Fox]

[*]I run either Windows XP, Windows Vista, or Windows 7 inside a target virtual machine. In some cases, I run Windows CE on a target physical machine or target virtual machine.

Which virtual machines/virtual machine disk files are supported?

I found some info about it here (is linked in the question) and here so that I can see that at least VIrtualBox and VMWare are supported.