I don't know how you guys develop or release ReactOS,
but I have never gotten a single release to compile
cleanly.
First I tried 0.2.6, and I had to edit GCC inline
assembly to get it to compile, and use various hacks
to get it to work.
Last night I tried 0.2.7, which I had to force to
compile with multiple declarations (by editing C++
files in tools/rbuild to disable the -Werror flag),
force to link by 'make VERBOSE=full' and then manually
copying the command line and adding
'obj-i386/hal/hal/libhal.a', and then after a few more
hours, ntoskrnl.exe would not link (several thousand
missing symbols).
I'm gonna get 0.2.8 now and try again, with the
Windows version of mingw (been using Linux so far).
Just in case, would someone explain to me how you guys
get it to compile? And how do you expect anyone to
develop an OS that is practically uncompilable?
Damjan
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
Hi,
I realize maybe some of you are aware of these, but it seems that we
just keep adding more and more regressions and there hasn't really been
an effort to fix them... We don't have a TC anymore and now the tree is
becoming as bad as before, which just proves the point of how badly this
project needed a TC.
I've just booted ROS for the first time in a month and I'm surprised at
the number of new things that have cropped up. The start menu became
huge, the registry is not cleanly dereferenced at shutdown (causing it
to get damaged and that makes freeldr display the "Codepage error"),
dhcp still crashes on first-boot since networking isn't installed, the
16x16 icons look like crap since alphablending was implemented, all
sorts of drivers "fail to load' on startup, RPC displays messages about
"Buffer overflows", umpnpmgr tries to copy invalid drivers, shutdown
still doesn't work on my QEMU,... and this is only what I've noticed
after 2 minutes.
Anyways, I don't want to nitpick, just to bring these issues up to
attention in case noobdy is aware of them.
Best regards,
Alex Ionescu
Hi,
since some time, I'm not able to install ReactOS on real hardware.
Freeldr fails at the first boot after the second stage setup. The error
message is 'Couldn't open CodePage registry key'. I've add some debug
messages to freeldr. Freeldr isn't able to open the key
'\Registry\Machine\SYSTEM\CurrentControlSet'. If I rename umpnpmgr.exe
between usetup and the second stage setup, ReactOS boots without any
problems. If I rename umpnpmgr.exe back, ReactOS fails on the second
boot with umpnpmgr.exe.
- Hartmut
I have interesting in working on the following programs:
C:\WINDOWS\system32\tree.exe
C:\WINDOWS\system32\gettype.exe(win2k3)
C:\WINDOWS\system32\findstr.exe
C:\WINDOWS\system32\w32tm.exe
and if I'm feeling extra fiesty maybe C:\WINDOWS\system32\osk.exe
Now my question is where i should put these, rospapps or maybe
reactos\subsys\system\ ?
Brandon
> From: blight(a)svn.reactos.com
>
> Implement (Int)EngAlphaBlend and 8, 16, 24 and 32 bpp DIB
> AlphaBlend functions. AlphaBlend() should work now.
Great work. Not sure if you realized it, but this helps Firefox a lot.
Screenshot with these changes applied: http://www.reactos.nl/pics/ff2.png
(the "before" screenshot is at http://www.reactos.nl/pics/ff1.png see the
difference in the toolbars)
Thanks again, Gé.
After changes r18883/r18912 umpnpmgr.exe (and eventlog.exe) don't start
anymore. The problem is that they try to connect to the service control
manager using a named pipe (advapi32/service/sctrl.c function
ScConnectControlPipe). Before opening the pipe, a call is made to
WaitNamedPipe() to see if the pipe exists. This call currently fails,
resulting in failure of ScConnectControlPipe(), resulting in failure of
umpnpmgr.exe, resulting in network drivers not being installed, resulting in
no network connectivity.
WaitNamedPipe() NtOpenFile()s the pipe and then issues a FSCTL_PIPE_WAIT
ioctl. The problem is that this end of the pipe is now connected to the
server end (which is already listening) during the call to NtOpenFile() (in
function NpfsCreate(), setting the PipeStatus to FILE_PIPE_CONNECTED_STATE.
NpfsWaitPipe first checks the PipeStatus and bails out if it's not 0
(passive waiting state). So, in our case NpfsWaitPipe fails, 'cause the pipe
is already connected. The patch below just makes NpfsWaitPipe return success
in case it's already connected, which solves the umpnpmgr problem. However,
I don't think it's the correct solution, after the FSCTL_PIPE_WAIT ioctl
returns WaitNamedPipe() will close its end, so the server end sees an
unexpected close.
I have no clue how to proceed, and to be honest I'm not interested in
solving it myself. I'd rather see the author of the original patch take his
responsibility and fix the regression he introduced.
GvG.
Hi!
Blight: I have a little question: why are you importing Mesa3d 6.2
sources, when there is a new stable version 6.4 out there? Maybe I
something misunderstood (I know almost nothing about OpenGL sources and
implementation in ReactOS), so there is a reason - in that case can you
explain it, please? Thank you very much.
Best regards,
Jirka
Hi,
I've changed rbuild a little bit, that it can run on msys (on windows).
The major changes are:
- The separator (slash or back slash), exepostfix and exeprefix are
initialized from environment variables.
- The separators in the path for the system command are always converted
for the host system.
- Our own build utilities must convert paths itself (bin2res).
It exist some problems with absolute paths on msys, because msys uses
'/c/foo/bar' and windows 'c:\foo\bar' or 'c:/foo/bar'.
I've tested the patch on msys and on windows. I cannot test the patch on
linux.
Currently, msys is the only way to use all cpus or cores for the build
process on windows.
- Hartmut
