[ros-kernel] ReactOS 0.2.1 RC1 sources == Nightmare
Waldo Alvarez Cañizares
wac at lab.matcom.uh.cu
Thu Feb 26 18:46:18 CET 2004
I have it and is installed in my system (And used the binaries, I didn't compiled). I have the proper make and everything. Are you sure all of them are local to me?. I'll check my environment as yes, it could be broken somehow but What about the crashes? Those sources where compiled before?
Best Regards
Waldo Alvarez
________________________________
From: ros-kernel-bounces at reactos.com on behalf of Casper Hornstrup
Sent: Thu 2/26/2004 4:14 PM
To: 'ReactOS Kernel List'
Subject: RE: [ros-kernel] ReactOS 0.2.1 RC1 sources == Nightmare
You are not using GCC 3.3.1 or later. Please go here to setup a usable mingw
environment:
http://www.reactos.com/reactos_developer_site/resources/download_the_recomme
nded_compiler
________________________________
From: ros-kernel-bounces at reactos.com
[mailto:ros-kernel-bounces at reactos.com] On Behalf Of Waldo Alvarez Cañizares
Sent: 26. februar 2004 21:49
To: ReactOS Kernel List
Subject: [ros-kernel] ReactOS 0.2.1 RC1 sources == Nightmare
Make clean does not works, it has the same effect as typing make
Some errors because of SEH in some tools (seems that a compiler with
SEH is a need now make sure it is documented) some stuff about getopts
showed up
Well I picked up my old "fixed" utilities free of try catch blocks
and with getopt
listview.c: In function `LISTVIEW_GetItemT':
listview.c:5043: parse error before "LVITEMW"
listview.c:5048: parse error before "LVITEMW"
listview.c: In function `LISTVIEW_InsertItemT':
listview.c:6082: parse error before "LVITEMW"
listview.c:6087: parse error before "LVITEMW"
make[1]: *** [listview.o] Error 1
make[1]: Leaving directory `C:/reactos-0.2.1RC1-source/lib/comctl32'
make: *** [comctl32] Error 2
oh well I took this from stddef.h
#define offsetof(s,m) (size_t)&(((s*)NULL)->m)
and inserted it there, well that works anyway :) but some header is
probably missing
I saw this too there at the beginning of listview.c
/* make sure you set this to 0 for production use! */
#define DEBUG_RANGES 1
I think this should be redirected to some .h so switching between
production debug comes to be an easy task. I have seen too much software out
there containing debug stuff even final and even commercial software. GPL
does not escapes. Ahh and windows contains it too. And please document it, I
have seen things like this in other places in all sorts of sizes and colors
it seems developers are lost sometimes about this (I am included in the list
too) Doing thinks like that will go unnoticed for a production build. I'm
talking about production because in my opinion that date is near.
well everything continued normally (although I saw some warnings
somewhere about an invalid pointer somewhere passed to a DbgPrint) to build
until this:
In file included from wine/cpp.c:36:
wine/msvcrt/stdlib.h:166: syntax error before "void"
make[1]: *** [wine/cpp.o] Error 1
make[1]: Leaving directory `C:/reactos-0.2.1RC1-source/lib/msvcrt'
make: *** [msvcrt] Error 2
The line is this:
_CRTIMP void __cdecl _swab (const char*, char*, size_t);
ovbiusly _CRTIMP wasn't defined anywhere I remember I had to "fix"
this in some earlier release but i forgot to tell.
ThIs is the only .h that contains it inside all the reactos sources.
Well I deleted it to keep going
Now comes this warning
In file included from memlockbytes.c:38:
ifs.h:28: warning: redefinition of `OLECHAR16'
../../include/wine/wtypes.h:6: warning: `OLECHAR16' previously
declared here
ifs.h:29: warning: redefinition of `LPOLESTR16'
../../include/wine/wtypes.h:8: warning: `LPOLESTR16' previously
declared here
ifs.h:30: warning: redefinition of `LPCOLESTR16'
../../include/wine/wtypes.h:10: warning: `LPCOLESTR16' previously
declared here
some stuff and this
oleproxy.c:243: warning: initialization from incompatible pointer
type
oleproxy.c:248: warning: initialization from incompatible pointer
type
oleproxy.c: In function `IRpcProxyBufferImpl_AddRef':
oleproxy.c:286: parse error before "CFProxy"
oleproxy.c: In function `IRpcProxyBufferImpl_Release':
oleproxy.c:291: parse error before "CFProxy"
oleproxy.c: In function `IRpcProxyBufferImpl_Connect':
oleproxy.c:302: parse error before "CFProxy"
oleproxy.c: In function `IRpcProxyBufferImpl_Disconnect':
oleproxy.c:309: parse error before "CFProxy"
oleproxy.c: In function `CFProxy_AddRef':
oleproxy.c:331: parse error before "CFProxy"
oleproxy.c: In function `CFProxy_Release':
oleproxy.c:337: parse error before "CFProxy"
oleproxy.c: In function `CFProxy_CreateInstance':
oleproxy.c:351: parse error before "CFProxy"
make[1]: *** [oleproxy.o] Error 1
make[1]: Leaving directory `C:/reactos-0.2.1RC1-source/lib/ole32'
make: *** [ole32] Error 2
again
#define offsetof(s,m) (size_t)&(((s*)NULL)->m)
this time was a little bit harder since offsetof was within a macro
thanks god i hitted thIs stone first, otherwise probably would have taken me
a lot of time to realize.
now again this time a link error
make[1]: Entering directory `C:/reactos-0.2.1RC1-source/lib/version'
windres -D__REACTOS__ -D_WIN32_IE=0x600 -D_WIN32_WINNT=0x501
--include-dir ../
../include --include-dir ../../include version.rc -o version.coff
gcc -fno-builtin -Wall -D_DISABLE_TIDENTS -D__USE_W32API
-D__REACTOS__ -D_WIN32_
IE=0x600 -D_WIN32_WINNT=0x501 -DWINVER=0x501 -I../../include/wine
-I./ -I../../
include -pipe -march=i386 -D_M_IX86 -c misc/libmain.c -o
misc/libmain.o
gcc -fno-builtin -Wall -D_DISABLE_TIDENTS -D__USE_W32API
-D__REACTOS__ -D_WIN32_
IE=0x600 -D_WIN32_WINNT=0x501 -DWINVER=0x501 -I../../include/wine
-I./ -I../../
include -pipe -march=i386 -D_M_IX86 -c misc/stubs.c -o misc/stubs.o
gcc -fno-builtin -Wall -D_DISABLE_TIDENTS -D__USE_W32API
-D__REACTOS__ -D_WIN32_
IE=0x600 -D_WIN32_WINNT=0x501 -DWINVER=0x501 -I../../include/wine
-I./ -I../../
include -pipe -march=i386 -D_M_IX86 -c info.c -o info.o
gcc -fno-builtin -Wall -D_DISABLE_TIDENTS -D__USE_W32API
-D__REACTOS__ -D_WIN32_
IE=0x600 -D_WIN32_WINNT=0x501 -DWINVER=0x501 -I../../include/wine
-I./ -I../../
include -pipe -march=i386 -D_M_IX86 -c install.c -o install.o
gcc -fno-builtin -Wall -D_DISABLE_TIDENTS -D__USE_W32API
-D__REACTOS__ -D_WIN32_
IE=0x600 -D_WIN32_WINNT=0x501 -DWINVER=0x501 -I../../include/wine
-I./ -I../../
include -pipe -march=i386 -D_M_IX86 -c resource.c -o resource.o
gcc -Wl,--base-file,base.tmp \
-Wl,--entry,_DllMain at 12 \
-nostdlib -nostartfiles -mdll -Wl,--image-base,0x77a90000 \
-o junk.tmp \
./version.coff misc/libmain.o misc/stubs.o info.o install.o
resource.o .
./../dk/w32/lib/libwine.a ../../dk/w32/lib/kernel32.a
../../dk/w32/lib/ntdll.a
info.o(.text+0x4d):info.c: undefined reference to `L176'
make[1]: *** [version.nostrip.dll] Error 1
make[1]: Leaving directory `C:/reactos-0.2.1RC1-source/lib/version'
make: *** [version] Error 2
now what is that L176 with such a cryptic name? Grrrr
Ok the third time searching all over the sources to find this
thingie
No luck this time. Well at least I could not find the ansi string
anywhere except in info.o
also files are identical to those in ROS 0.2.0 that was compiling (I
did a diff). So the problem is not here. That L176 looks like a zlib name
but who knows? Zlib does not contains this name.
Ok this time the victim is the makefile I have the binary compiled
already from a previus release and sources are identical. Hmmm
So I excluded it from the build in the makefile at the root of the
sources tree.
utility/window.cpp: In member function `virtual LRESULT
ChildWindow::WndProc(unsigned int, unsigned int, long int)':
utility/window.cpp:443: warning: unused variable `ClientRect rt'
utility/window.cpp: In member function `void
ResizeManager::HandleSize(int,
int)':
utility/window.cpp:726: warning: unused variable `ClientRect
clnt_rect'
...
-DNDEBUG -Os -DUNICODE -c -o quicklaunch.o taskbar/quicklaunch.cpp
taskbar/quicklaunch.cpp: In function `static HWND__*
QuickLaunchBar::Create(HWND__*)':
taskbar/quicklaunch.cpp:81: warning: unused variable `ClientRect
clnt'
...
c:/mingw/bin/../lib/gcc-lib/mingw32/3.2/../../../libstdc++.a(fstream-inst.o)
(.te
xt$_ZNSt13basic_fstreamIcSt11char_traitsIcEE7is_openEv+0x87):fstream-inst.cc
: un
defined reference to `_Unwind_SjLj_Resume'
make[1]: *** [explorer.exe] Error 1
make[1]: Leaving directory
`C:/reactos-0.2.1RC1-source/subsys/system/explorer'
make: *** [explorer] Error 2
again more reasons to document the need for SEH in the compiler my
g++ can't link this well at least compiles :)
Hohoho this file i386-stub-win32.c in explorer. I have a question.
Isn't the compiler task to handle exceptions and save/restore registers
during the catch block?
Ok Explorer excluded from the build (i'm happy with a resonable bug
free cmd anyway)
so makefile the victim again
g++ -fexceptions -g -O0 -DWIN32 -D_DEBUG -D_WINDOWS -D_MBCS -W
-D__USE_W32API -W
all -Werror -I./ -I../../../include -pipe -march=i386 -D_M_IX86 -c
patblt.cpp -o
patblt.o
g++ -Wl,--subsystem,windows \
-Wl,--entry,_WinMainCRTStartup \
-o patblt.nostrip.exe \
patblt.o ../../../dk/w32/lib/kernel32.a
../../../dk/w32/lib/user32.a ..
/../../dk/w32/lib/gdi32.a
patblt.o(.eh_frame+0x12):patblt.cpp: undefined reference to
`__gxx_personality_v
0'
c:/mingw/bin/../lib/gcc-lib/mingw32/3.2/../../../libstdc++.a(eh_terminate.o)
(.te
xt+0x34):eh_terminate.cc: undefined reference to
`_Unwind_SjLj_Register'
c:/mingw/bin/../lib/gcc-lib/mingw32/3.2/../../../libstdc++.a(eh_personality.
o)(.
text+0x503):eh_personality.cc: undefined reference to
`_Unwind_SjLj_Register'
c:/mingw/bin/../lib/gcc-lib/mingw32/3.2/../../../libstdc++.a(eh_personality.
o)(.
....
exceptions again
at this time I'm already tired of so much sh... and killing that app
is OK for me
makefile with it again
g++ -Wl,--subsystem,windows \
-Wl,--entry,_WinMainCRTStartup \
-o primitives.nostrip.exe \
primitives.o mk_font.o ../../../dk/w32/lib/kernel32.a
../../../dk/w32/l
ib/user32.a ../../../dk/w32/lib/gdi32.a
primitives.o(.eh_frame+0x11):primitives.cpp: undefined reference to
`__gxx_perso
nality_v0'
mk_font.o(.eh_frame+0x11): In function
`ZN4font8MakeFontEP5HDC__PKcihm':
C:/reactos-0.2.1RC1-source/apps/tests/primitives/mk_font.cpp:30:
undefined refer
ence to `__gxx_personality_v0'
make[2]: *** [primitives.nostrip.exe] Error 1
make[2]: Leaving directory
`C:/reactos-0.2.1RC1-source/apps/tests/primitives'
make[1]: *** [primitives] Error 2
make[1]: Leaving directory `C:/reactos-0.2.1RC1-source/apps/tests'
make: *** [tests] Error 2
Ok I commented this line
#include <cassert>
in both files and commented asserts
Fine finally I built it :))
I runned welcome.exe just to test on top of windows
I got a message back
The procedure entry point InterlockedDecrement could not be located
in the dynamic link library ntdll.dll
Well seems that windows's ntdll does not exports this function and
that welcome.exe is using it.
Isn't supposed that welcome get's executed on top of window when the
autorun opens up the CD content?
make install does not puts the cute lena.bmp and some other media
needed by tests
i packed the binaries and putted them In a winzip selfextractor and
as it was 5 Mb I created an iso and attached it to VMWare
bang a crash (this was a heavily modified 0.2.0)
i copied the exe to the virtual hard dIsk just to avoid some bug in
the CD drivers and again
(objects/gdiobj.c:307) Can't delete hObj:0x000001ae,
type:0x007f0000, flag:0
(KERNEL32:file/dir.c:170) NtPathU '\??\C:\newros\system32\config'
(KERNEL32:file/dir.c:170) NtPathU '\??\C:\newros\system32\drivers'
(mm/section.c:1487) Trying to page out not-present page at
(9,0x77F80000).
KeBugCheck at mm/section.c:1488
Bug detected (code 0 param 0 0 0 0)
The bug code is undefined. Please use an existing code instead.
Pid: 1 <SYSTEM> Thrd: c19d0478 Tid: 14
Frames: <ntoskrnl.exe: 973b>
<ntoskrnl.exe: 49c97>
<ntoskrnl.exe: 501d7>
<ntoskrnl.exe: eaee>
<ntoskrnl.exe: 4fac9>
<ntoskrnl.exe: 3170>
ExceptionRecord->ExceptionAddress = 0xc0005474
KeBugCheckWithTf at ke/catch.c:168
Bug detected (code 1e param 0 0 0 0)
KMODE_EXCEPTION_NOT_HANDLED
Recursive bug check halting now
just in case (I didn't touched section.c)
Fine I incremented ram to 36 MB, no luck
Fine 92 Mb to prevent as much as possible the memory balancer from
working
At that time everything i typed was pure garbage even in edIt boxes
and cmd line.
about 280 files extracted ok but went nowhere. I suspected that was
only edit boxes wrecked but no it was the code handling keyboard, behaviour
I never saw before and I used this binaries a lot.
Fine booted the new ros :)
Oops I forgot I didn't have explorer
mkhive again
Later I tried strechtblt (lena wrecked) and when I maximize
strechtblt the maximize button stays in the maximized state if you click
again it draws the 2 little windows instead of the big window it should
show. Is a minor glitch but should be fixed.
Entering and leaving graphics does not restore previous text on the
screen and as someone mentioned later the cursor is lost
seems to be aproblem somewhere in the hal (it appears and gets
erased later)
ahh well some playing with hives to make WinZip run in my new ros
(manual installation)
now i got back in the vmware console i built (I something similar in
tools) some message lIke shell could not be found
hmm userInit the victim this time
no luck
so I renamed cmd.exe as explorer.exe ohh yess (maybe the second
stage setup changed my shell to explorer back)
now I cd to d:(where is my virtual cd drive) and tryed to copy quake
2 files. no luck
I get this when copying the huge pak0.pak
(misc.c:135) Vfat is entered at irql = 1
(misc.c:135) Vfat is entered at irql = 1
(misc.c:135) Vfat is entered at irql = 1
(misc.c:135) Vfat is entered at irql = 1
I zipped and splitted the file into tiny 500Kb pieces and hitted
again
Trying to page out not-present page at ...
in section.c so the bug is this release too
So I would put this bug in bugzilla (Crash writting/reading large
files)
sometimes pressing the up arrow button after coming from graphics
puts the text somewhere else in the screen
again this should be in the hal
another one typing del . in cmd.exe prints in the screen:
Unknown error! Error code: 0x5
0 files deleted
and I'm used to type this in windows to wipe out quickly entire
directories
fine I ended up creating an ISO with quake II packed inside an sfx
zipped file and coping the file with Free-dos using microsoft's ms-dos cd
drivers. I unpacked them with ReactOS and a everything went OK.
Hope this helps fix all kind of bugs/undocummented requierements
etc.
Regards
Waldo Alvarez
_______________________________________________
Ros-kernel mailing list
Ros-kernel at reactos.com
http://reactos.com/mailman/listinfo/ros-kernel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 29296 bytes
Desc: not available
Url : http://reactos.com:8080/pipermail/ros-kernel/attachments/20040226/205a564f/attachment-0001.bin
More information about the Ros-kernel
mailing list