I was compiling ReactOS 0.2.5 today. I typed "make" and it went swimmingly
when it threw this up at me:
kernel32: [CC] misc/console.c
make (e=2): The system cannot find the file specified.
make [1]: ***[misc/time.o] Error 2
make: ***[kernel32] Error 2
The system's a Compaq Deskpro 4000, with C: being a 1.25 GB hard-drive and
with 64 MB.
What do people suggest I do? (Besides updating to 0.2.6?)
Wesley Parish
--
Clinersterton beademung, with all of love - RIP James Blish
-----
Mau e ki, he aha te mea nui?
You ask, what is the most important thing?
Maku e ki, he tangata, he tangata, he tangata.
I reply, it is people, it is people, it is people.
Hi all,
When did the floppy detection stop working? I can not read the floppy driver.
Thanks,
James
PS,
I lost 2/3 of my email, I have no references atm.
Hi,
I would update the cache_manager_rewrite branch with all changes from
the main tree. I'm using the merge command to add the changes to my
local tree. It fails allways with revision 13667. I can merge all
changes up to revision 13666. But I get an error with revision 13667:
E:\Sandbox\ros_cache\reactos\tools>d:\programme\subversion\bin\svn.exe
merge -r13566:13667 svn://svn.reactos.com/trunk/reactos/tools
D winebuild\res32.c
D winebuild\spec32.c
D winebuild\res16.c
D winebuild\utils.c
D winebuild\Makefile.in
D winebuild\spec16.c
D winebuild\mkstemps.c
D winebuild\build.h
D winebuild\import.c
D winebuild\relay.c
D winebuild\winehq2ros.patch
D winebuild\winglue.h
D winebuild\winebuild.man.in
D winebuild\main.c
D winebuild\parser.c
D winebuild\Makefile
D winebuild
svn: Revision 13667 doesn't match existing revision 13567 in 'winebuild'
What can I do to solve this problem?
- Hartmut
Agreed.
It'll be good for publicity too.
Regular minor releases are better than infrequent major releases.
Gedi.
-----Original Message-----
From: Jason Filby [mailto:jason.filby@gmail.com]
Sent: 23 February 2005 17:57
To: ReactOS Development List
Subject: [ros-dev] Release 0.2.6
Hi all
The consensus on IRC appears to be that we need another 0.2.x release.
The reason is that 0.3 is our "network" release and there's still some
work to do to justify this.
Everyone agree?
Cheers
Jason
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
Hi,
A little background info. I have a dell Latitude c610 with a P3m 1ghz CPU, 256Megs of Ram and a 20
Gig hard disk. ATI Mobile Radeon Graphics chip with 16megs of Vram.
When I try to boot ReactOS the screen always go black after freeldr loads the drivers and
everything even if /NOGUIBOOT is selected and bootvid.sys is removed from the system. The screen
never goes blue and the kernel never gets a point where HalDisplayString or the kernel debugger
will work. I have added a function to my ke\main.c to manually write to the screen in text mode
and have been using that to try to debug the boot process. The problem is that it never
consistantly crashes at one line of code. It always seems to be around a call to KeLowerIrql but
depending on where I stick my debug statements it will change. Whats odd is that it will fail 100%
of the time in the same place depending on where I move my debug statements. The only thing I can
figure is that but writting to the display its interupting which is changing the failure location.
The farthest in the boot process I can get is the call to KeLowerIrql that happens around the
calls to SeInit1 and SeInit2.
Thanks
Steven
__________________________________
Do you Yahoo!?
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250
> -----Original Message-----
> From: ros-dev-bounces(a)reactos.com
> [mailto:ros-dev-bounces@reactos.com] On Behalf Of Karim Liman-Tinguiri
> Sent: 24. februar 2005 12:34
> To: ReactOS Development List
> Subject: Re: [ros-dev] Release 0.2.6
>
> Greetings everyone,
>
> I totally agree with Murphy and I believe we should launch another
> 0.2.x release before the next 0.3 release. I think before we can
> launch a 0.3 release, we need to have a solid support for Win32
> drivers: networking doesn't limit to LAN-Ethernet, but it also
> includes PPP and modem connection (analogic and broadband).
>
> With the growing amounts of winmodems, Win32 driver support must
> definitely be implemented before claiming "networking
> support": this is one of the weaker points of Linux: driver
> compatibility (though lots of efforts are being made by manufacturers
> and hackers), many drivers are still only available on the windows
> platform. It'd be much cheaper, programming-effort wise, to natively
> support windows driver than try to port them to ReactOS, (I'm not even
> mentionning the case of closed-source drivers and undocumented
> hardware).
>
> As is stated in the status page of the library "Driver Support At the
> moment, work to support 3rd party drivers (Microsoft Windows
> compatible) is restricted. The focus is more on only basic drivers
> that are written in conjunction with the various kernel facilities." ;
> there's not much 3rd party Microsft Driver support. It'd definitely
> have to be implemented before
> 0.3 release.
That would be nice, but it's not practical since nobody has volunteered
to work on it and thus it will not get implemented any time soon. If you
will work on it or can find someone who will and can give a rough
timeframe for its completion (say 5-6 months), I might vote for a delay
of a 0.3 release.
Casper
Rolf Kalbermatter wrote:
>This is rubish.
>
Yes ^ 3 ( that is Yes cubed)
Let us all get back on track of this discussion. Must ReactOS and MinGW
use the Wine set of headers.
1. ReactOS & MinGW are by themselves GPL, So they are more strict than
Wine's header set
2. Headers are out of the scope for License as Rolf explained.
Or to be more precise they are the boundary put by the License.
"From this API down you are in Library territory".
The header is the Line drawn by the Library writer, as what is
public API. A GPL program is an LGPL library with the trivial public
header of:
<c> int main(int argc ,char* argc[]) ; // use only </c>
3. Wine Headers are description of the Win32 API by Microsoft, so what
the hell are you talking about.
And back to the subject. I have proved that Wine-headers are not only,
nice-to-have, but a must in a gcc compilation environment on Windows,
like MinGW or Cygwin. Could/did any one see if ReactOS has every thing
they need in wine-headers and if not patch in the diff.
So is it accepted than!
Free Life
Boaz
