ReactOS Roadmap: version 0.3.11

[PetruDimitriu]

The wiki's roadmap page says: Usability effort: flawless browsing in Firefox 3, no winetest crashes Just wondering, what are now the main things devs are working on?

[Haos]

Sound by janderwald, kernel32 winetests, changes in Mm due to ARM port, general rbuild maintenance towards MSVC adaptation, window message rewrite, brush rewrite, aicom still working on net, recently bit of explorer-new refurbishment and fixing bugs whenever they pop out. See svn log for details.

[ericy]

One thing I would like to request is that someone work on windbg and cdb and fix reactos so that these are stable and usable debuggers.

I spent some time playing with ReactOS, and I have a list of close to 30 issues. A few of them I have seen discussed, most I have not. Some would in fact be difficult to repro, and I would like to get in with a debugger and see what the heck is going on myself so that I could write up far more useful and descriptive bug reports. Most of the applications that I would like to test have been built with VS, so using gdb isn't really a good option..

[PetruDimitriu]

general rbuild maintenance towards MSVC adaptation

Why? The actual compiler doesn't do its job well?

window message rewrite

That is how windows work, show and react, right? I would love to have some ugly visual bugs fixed.

[Z98]

The ROS developers do not think very much of GCC's performance and code generation quality.

[Haos]

@Petru

You are not really that long with us to witness any gcc-related suffering, but believe me, it exists. For example, its a source of our reluctance towards any c++ code.

[Black_Fox]

Some compression algos authors on the other hand think that GCC >=4.3 (IIRC) produces code in some ways relatively comparable to Intel compiler, which is considered elite...

[hto]

GCC 4.4.1 will be released next week. But ReactOS still uses GCC 4.1.3…

[doomonyou]

Sound by janderwald, kernel32 winetests, changes in Mm due to ARM port, general rbuild maintenance towards MSVC adaptation, window message rewrite, brush rewrite, aicom still working on net, recently bit of explorer-new refurbishment and fixing bugs whenever they pop out. See svn log for details.

Eagerly awaiting sound and explorer-new.

[Lone_Rifle]

As of r41986 the following winetests crash:
mlang:mlang
netapi32:access
user32:listbox
oleaut32:olepicture
setupapi:devinst
shell32:shelllink
user32:listbox
wininet:http
wininet:internet
ws2:sock

and the following time out:
ntdll:exception
ntdll:port
urlmon:protocol
urlmon:url
user32:menu
user32:win
winhttp:notification
winhttp:http
winhttp:ftp

[Lone_Rifle]

One thing I would like to request is that someone work on windbg and cdb and fix reactos so that these are stable and usable debuggers.

I spent some time playing with ReactOS, and I have a list of close to 30 issues. A few of them I have seen discussed, most I have not. Some would in fact be difficult to repro, and I would like to get in with a debugger and see what the heck is going on myself so that I could write up far more useful and descriptive bug reports. Most of the applications that I would like to test have been built with VS, so using gdb isn't really a good option..

Currently as an interim measure we have RosDbg and Kdbg, both found on the wiki.

[PetruDimitriu]

user32:listbox

Ouch... So if even window controls crash, then I guess you should really follow the roadmap and do a usability effort...

[Smiley]

user32:listbox

Ouch... So if even window controls crash, then I guess you should really follow the roadmap and do a usability effort...

the fact that the test crashes doesn't mean that it every app that uses a listbox will crash. Also note that this crash appeared lately

EDIT: the devs already fixed this issue

[ericy]

Currently as an interim measure we have RosDbg and Kdbg, both found on the wiki.

Yeah, I know. But to use it, it seems like you have to be in a position to do your own custom build with special flags set, and for those of us who don't really have the time that is a pretty big hurdle.

Really what I was looking for is a usable user-mode debugger of some sort. Something I can use to attach to a hung process, for example. Or perhaps just run something that is misbehaving to get a better sense of what the underlying failure mode is - the objective being to be able to write more detailed bug reports.

I picked windbg because it is available and lightweight, and if the thing you are debugging was built with MSVC, you have symbols which make it all the easier to debug.

I suppose I should put some mingw32 binaries on the thing - I suppose gdb would work, but debugging at the assembly level with no symbols is kind of tedious.

[hto]

Really what I was looking for is a usable user-mode debugger of some sort. Something I can use to attach to a hung process, for example. Or perhaps just run something that is misbehaving to get a better sense of what the underlying failure mode is - the objective being to be able to write more detailed bug reports.

Maybe OllyDbg (though I don't know does it work or not).