Hi,
I'm trying to compile ros on ros with the current svn tree. It isn't possible. After some time, it fails with a message cannot execute 'bla bla'. The build does corrupt the file system. If I run chkdsk from w2k I get many messages about multiple files like 'wrc.ex'. It seems that something is wrong with the string functions.
- Hartmut
http://reactos.com/bugzilla/show_bug.cgi?id=756 ??
On 9/6/05, Hartmut Birr osexpert@gmail.com wrote:
Hi,
I'm trying to compile ros on ros with the current svn tree. It isn't possible. After some time, it fails with a message cannot execute 'bla bla'. The build does corrupt the file system. If I run chkdsk from w2k I get many messages about multiple files like 'wrc.ex'. It seems that something is wrong with the string functions.
- Hartmut
Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
Hartmut Birr wrote:
Hi,
I'm trying to compile ros on ros with the current svn tree. It isn't possible. After some time, it fails with a message cannot execute 'bla bla'. The build does corrupt the file system. If I run chkdsk from w2k I get many messages about multiple files like 'wrc.ex'. It seems that something is wrong with the string functions.
- Hartmut
Hi,
Revision 17718 should fix this. It was a small typo on my part, sorry.
Best regards, Alex Ionescu
PS. Filip: do you ever *read* my patches when you review them? ;-)
Alex Ionescu wrote:
Hi,
Revision 17718 should fix this. It was a small typo on my part, sorry.
Have you looked to RtlUnicodeStringToAnsiSize and RtlUnicodeStringToOemSize? They do simply the same and cannot fix the bug.
PS. Filip: do you ever *read* my patches when you review them? ;-)
Do you ever *test* your own patches before you commit them? ;-)
- Hartmut
Hartmut Birr wrote:
Alex Ionescu wrote:
Hi,
Revision 17718 should fix this. It was a small typo on my part, sorry.
Have you looked to RtlUnicodeStringToAnsiSize and RtlUnicodeStringToOemSize? They do simply the same and cannot fix the bug.
I don't understand what you mean? Those macros are re-written from the IFS, they can't be wrong... I must be misunderstanding you.
PS. Filip: do you ever *read* my patches when you review them? ;-)
Do you ever *test* your own patches before you commit them? ;-)
Sure... testing this patch (which took me about 2 hours) revealed two things to me: 1) The string routines were returning the wrong size, breaking countless applications 2) ANSI_NULL was not defined correctly, also causing possibly many bugs.
but I have to admit, I don't compile ros-on-ros, so I didn't catch those two typos. I don't think any of the developers here do except for you... Just like almost nobody here does release builds, and I'm always the one that has to fix the build :)
- Hartmut
Best regards, Alex Ionescu
Alex Ionescu wrote:
Hartmut Birr wrote:
Have you looked to RtlUnicodeStringToAnsiSize and RtlUnicodeStringToOemSize? They do simply the same and cannot fix the bug.
I don't understand what you mean? Those macros are re-written from the IFS, they can't be wrong... I must be misunderstanding you.
RtlUnicodeStringToAnsiSize uses either the Length value from given string or calls RtlxUnicodeStringToAnsiSize which calls RtlUnicodeToMultiByteSize. RtlUnicodeStringToOemSize uses either the Length value from given string or calls RtlxUnicodeStringToOemSize which calls RtlUnicodeToMultiByteSize. Multibyte code pages are not implemented. Both functions return the Length value from given string. That's why replacing RtlUnicodeStringToAnsiSize with RtlUnicodeStringToOemSize has no effect and cannot fix the bug.
- Hartmut