When will 0.3.15 release?

[BlackRabbit]

Which virtual machines/virtual machine disk files are supported?

All of them.

After all, Visual Studio, running on the source host machine, communicates with MSVSMON.EXE, running on the target guest machine, over TCP/IP, so whether the target machine is physical or virtual [VirtualPC, VirtualBox, VMWare, etc.] does not matter.

[fireball]

Which virtual machines/virtual machine disk files are supported?

All of them.

After all, Visual Studio, running on the source host machine, communicates with MSVSMON.EXE, running on the target guest machine, over TCP/IP, so whether the target machine is physical or virtual [VirtualPC, VirtualBox, VMWare, etc.] does not matter.

So, does that work in ReactOS now?

[BlackRabbit]

So, does that work in ReactOS now?

Apparently not. Visual Studio is able to "connect" to MSVSMON.EXE, but after connection, Visual Studio displays the following error:

[ external image ]

This error is obviously not true, because I can see inside MSVSMON.EXE that the connection was in fact made.

[Z98]

How do you know msvsmon is actually implemented? The entire thing could be a placeholder right now.

[BlackRabbit]

How do you know msvsmon is actually implemented? The entire thing could be a placeholder right now.

msvsmon.exe is a download from Microsoft, so by definition, it is already completely implemented. Microsoft allows the programmer to use msvsmon.exe for "debugging and testing purposes", per its EULA. Microsoft expects the developer to copy msvsmon.exe to the machine where the program-under-debug is executing.

A more relevant question might be:

Is the Windows Debugger API completely implemented by ReactOS?, since msvsmon.exe utilizes the Windows Debugger API to achieve its functionality.

I guess a quick way to find out is to ask Alex:

Code: Select all

/*
 * PROJECT:         ReactOS Win32 Base API
 * LICENSE:         GPL - See COPYING in the top level directory
 * FILE:            dll/win32/kernel32/debug/debugger.c
 * PURPOSE:         Wrappers for the NT Debug Implementation
 * PROGRAMMERS:     Alex Ionescu (alex.ionescu@reactos.org)
 */

[Z98]

A quicker way would be to just look through the source code.

[BlackRabbit]

Well, I did.

There is too much code in user-mode:

reactos\dll\win32\kernel32\client\debugger.c

and kernel-mode:

reactos\ntoskrnl\dbgk\dbgkobj.c

...for the code to be place-holders. On the other hand, that does not mean that it has been debugged and is stable. That is what I wanted to ask Alex: whether the code that he wrote is sufficiently stable to support remote debugging. I sent an email to him asking him that.

[Zc456]

Judging by the present status of the daily builds, and thread on build 58487, weather or not we'll get 0.3.15 or 0.4 remains blurry. As many of the developers have said, it's best to follow the commits. Since 0.3.14, a lot of progress has been made. That's all anyone can say, at the moment.

[vicmarcal]

0.3.15 wont be released before this happens: http://reactos.org/forum/viewtopic.php?f=2&t=12410
S this depends heavinly in you...

[gonzoMD]

0.3.15 wont be released before this happens: http://reactos.org/forum/viewtopic.php?f=2&t=12410
S this depends heavinly in you...

Don't you think that it is better to wait for Hermès' CSRSS thing and Eric's Log On process story?
they are both very far progressed, as far as my knowledge reaches out.
So all the devs could help out to add more functionality shell-/user32 and win32k to get more apps compatible and a better look'n'feel (explorer_new, theming issues) on the way to 0.4.

[Black_Fox]

If we do some preliminary testing now, it will be much easier to find out where the regressions came from, if it was trunk development or if it's regression added in with merge. If the merges were done now without any testing, we wouldn't know if it regressed in r55000 or now

[Z98]

Point releases beyond the bump from 0.3 to 0.4 don't depend on any particular piece of functionality getting done. They only depend on things not breaking too horrifically in between them.

[vicmarcal]

0.3.15 wont be released before this happens: http://reactos.org/forum/viewtopic.php?f=2&t=12410
S this depends heavinly in you...

Don't you think that it is better to wait for Hermès' CSRSS thing and Eric's Log On process story?
they are both very far progressed, as far as my knowledge reaches out.
So all the devs could help out to add more functionality shell-/user32 and win32k to get more apps compatible and a better look'n'feel (explorer_new, theming issues) on the way to 0.4.

I'd prefer to release without Csrss and Logon just to focus in compatibility behavior and check for regressions during all this year.
After releasing 0.3.15 I would add the Csrss and the Logon plus some winesyncs and a couple of MM fixes and voila... 0.4.0

[gonzoMD]

0.3.15 wont be released before this happens: http://reactos.org/forum/viewtopic.php?f=2&t=12410
S this depends heavinly in you...

Don't you think that it is better to wait for Hermès' CSRSS thing and Eric's Log On process story?
they are both very far progressed, as far as my knowledge reaches out.
So all the devs could help out to add more functionality shell-/user32 and win32k to get more apps compatible and a better look'n'feel (explorer_new, theming issues) on the way to 0.4.

I'd prefer to release without Csrss and Logon just to focus in compatibility behavior and check for regressions during all this year.
After releasing 0.3.15 I would add the Csrss and the Logon plus some winesyncs and a couple of MM fixes and voila... 0.4.0

but not w/o explorer_new, full theming support, graphic glitch fixes etc. because the wiki says it will be an overall look and feel release?
I think a new minor point release may contain some significant changes but can be a little unstable though, because for the further fixes, there are the 0.4.x releases.

[vicmarcal]

but not w/o explorer_new, full theming support, graphic glitch fixes etc. because the wiki says it will be an overall look and feel release?
I think a new minor point release may contain some significant changes but can be a little unstable though, because for the further fixes, there are the 0.4.x releases.

Imho, we are expecting too much from a 0.4.0 release. I mean: If we want 0.4.0 to have USB, full theming,csrss,login features, explorer-new, complete MM, etc...what do we expect to release on 0.5.0(the first Beta release)?It's like if we want to release everything on 0.4.0...without thinking that there is 0.5.0, 0.6.0, 0.7.0, 0.8.0, 0.9.0 and 1.0 and its subseries to completness..
It's time to move from 0.3.0 series once and for all!!!
Which are my arguments about moving from 0.3.0 to 0.4.0?
My main argument: A software product must move towards a new decimal version (0.2->0.3 or 0.3->0.4) when a major functionality is added. 0.3.14 means that in terms of functionality and features, 0.3.14 behaves similar to 0.3.0 series.But this isn't true at all:
1) 0.3.0 didnt have any sound support.
2) 0.3.0 didnt have any usb support.
3) 0.3.0 didnt have any sata support.
4) 0.3.0 didnt have any network cards support.
5) 0.3.0 didnt have a good video cards support.
6) 0.3.0 didnt even support VBOX!!! (download ReactOS 0.3.0, you'll see that you can't install it in VirtualBox)
7) 0.3.0 software compatibility sucks. This is related not just to our own compatibility development but also to Wine's improvements in 10 years.

For me just the addition of USB, or SATA or Sound or VBOX support should have rised our number from 0.3.0 to 0.4.0.
But if anyone has doubts about how 0.3.0 sucks compared to 0.3.14 he can just download it and try any of the GoldenApps from Testing Central there. Just 3 were working from 30.
Why am I so stubborn about moving once and for all towards 0.4.0?
Because from the PR point of view, the 0.3.X series is unfair related to our current status and because we can't live forever in the 0.3.X world unless we are expecting to jump from 0.3.0 to 1.0