Hi for all the ReactOS community, soon brings near to him the FLISOL2010
and want to take the CD that appears in the ReactOS page, since the
discharge from tub makes to him impossible for the limited bandwidth that
has in the island...
Please if some interested party in collaborating, it need a CD that it
contains the operative system ( in Spanish ), the source code of ReactOS
and some manuals ( in Spanish )...
I, will make oneself responsible for make copy them and distribute it for
the happening, in order that the Cuban community that has not access to
the Internet can obtain " the alternative of Windows ".
They can me write directly to my address of post: raul08012(a)cha.jovenclub.cu
R++
Hi,
One big regression has been detected due to the HAL changes:
Scenario: Real Hardware. One CDROM attached to IDE in Slave Mode in its own.
What happens: It bugchecks since 45324.Latest working revision known 45319.
DebugLog: http://www.reactos.org/paste/index.php/6511/
Reporter: Caemyr.
Suspicious revisions in the range (45319-45324):
45320: [HAL]: Rewrite IRQL handling. (sir_richard)
45324: [HAL]: fix HalEndSystemInterrupt prototype.(spetreolle)
Also there are users reporting problems(maybe not related) with CDRom under Vbox.
Please look at it.
Thanks :)
PS: Sorry for double posting.But i prefer this in a new thread.
_________________________________________________________________
Los auténticos Hotmail y Messenger en tu Blackberry con Movistar. ¡Descárgatelos ya!
http://serviciosmoviles.es.msn.com/messenger/blackberry.aspx
Hi folks,
Finally, the new version 1.5 of the ReactOS Build Environment has been
finished. The new releases for Windows and Unix are available at
http://reactos.org/wiki/Build_Environment.
With the new version, we're finally moving to newer toolchain versions
(Binutils 2.20.51-20091222, GCC 4.4.3).
These allow us to get rid of many old hacks, but also require some new
modifications to the source. Unfortunately, these changes are incompatible
to our current build environment, so the update to 1.5 is mandatory.
I've also taken the chance to get rid of some other hacks, which had
required a united TRUNK and RosBE update (like calling the makefile
"makefile.auto" instead of "makefile-i386.auto" just for the i386
architecture).
The patch for these changes is available at
http://www.reactos.org/bugzilla/show_bug.cgi?id=4810 and was tested and
improved for months now.
I've been told to commit it very soon to not delay the migration to RosBE
1.5 once again. Therefore, please prepare yourselves with the new RosBE as
soon as possible.
Best regards,
Colin
Hi,
sir_richard(a)svn.reactos.org a écrit :
> Author: sir_richard
> Date: Tue Feb 9 04:05:49 2010
> New Revision: 45525
>
> URL: http://svn.reactos.org/svn/reactos?rev=45525&view=rev
> Log:
> [MISC]: Build fixes to sync up with latest changes.
> [SETUPLDR]: Do not build on ARM. On a side note, I offer a bountry for "if ARCH != ARM" support in .rbuild files, instead of only allowing ==.
>
I think <ifnot property="ARCH" value="arm"> ... </ifnot> will fit your needs
Hervé
No doubt the new code is a huge advantage over the old code. Still there
are some issues in my opinion.
Currently the trap handlers are generated inside C code by a macro
called KiTrap(), located in trap_x.h.
This macro creates a C function, that uses KiTrapStub inline function to
create the actual entry stub. KiTrapStub is 90% pure gcc inline assembly.
At the end it does a jmp to the real C handler.
Most C handlers will start processing with an inline function
KiEnterTrap, which is C code with inline assembly functions like
KiSetSaneSegments, Ke386GetFs. KiTrap06Handler/Trap0DHandler are
exceptions, they use KiIsV8086TrapSafe to determine in inline assembly
if we have a v86 trap.
In this case KiEnterV86Trap is used instead of KiEnterTrap. KiTrap02 is
also an exception, it's a pure C handler
Now what's wrong?
1.) The gcc inline assembly is very compiler specific and MSVC
unfriendly. The old method using GAS specific asm files was at least
linkable with MSVC code. The new code needs porting.
2.) The current C code makes assumptions about what the compiler will
do, ignoring the ABI, which requires that you do not change ds/es in C
code, not even temporarily and that the direction flag is clear on
function entry. The compiler might at any place use ds/es for whatever
it likes. It must be a valid flat segment. Only using stack variables
might work on the current gcc, but might fail on other compilers. A good
example would be MSVC's use of __security_cookie, which is referenced on
function entry through ds. I remember that not having cleared the
direction flag in a trap handler caused strange random bugs in the past,
we should avoid making this mistake again. KiTrapStub even changes esp
inside C code (in cases where the function is entered without valid esp)
Suggested modifications:
Implement the trap entry functions in a pure assembly file, using
assembly macros which would combine KiTrapStub and the segment handling
part of KiEnterTrap.
Trap exit could possibly be done this way as well. On the amd64 branch
the C handlers return a status value back to the assembly stub, but a
jump or call could be done as well.
It would be possible to use ML for these assembly files as well. This
works fine in the amd64 branch.
Also strictly stick to C ABI instead of using compiler extensions and
making assumptions about how the compiler works.
It would improve portability, make the code safe and also more readable.
And we would not really add more assembly, just move the current inline
assembly to a pure assembly file.
Possible performance disadvantages: I don't see any. We might end up
with a jmp or call instruction more, but we can possibly safe this
somewhere else.
And maybe finally someone deletes the disgusting Ke386SetDs()... ;-)
Regards,
Timo
Hmm... either his email address is invalid, the server is playing up or it
filters out UK addresses...
---------- Forwarded message ----------
From: Mail Delivery System <Mailer-Daemon(a)jovenclub.cu>
Date: Fri, Feb 5, 2010 at 6:58 PM
Subject: Mail delivery failed: returning message to sender
To: ajfweb(a)googlemail.com
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
cl2raul(a)cha.jovenclub.cu
SMTP error from remote mail server after RCPT TO:<
cl2raul(a)cha.jovenclub.cu>:
host 192.168.54.3 [192.168.54.3]: 550 5.1.1 <cl2raul(a)cha.jovenclub.cu>:
Recipient address rejected: User unknown in local recipient table
------ This is a copy of the message, including all the headers. ------
Return-path: <ajfweb(a)googlemail.com>
Received: from [192.168.250.1] (helo=mx1.jovenclub.cu)
by tinored.jovenclub.cu with esmtp (Exim 4.63)
(envelope-from <ajfweb(a)googlemail.com>)
id 1NdTNq-000HgO-6D
for cl2raul(a)cha.jovenclub.cu; Fri, 05 Feb 2010 18:58:26 +0000
Received: from mailnull by mx1.jovenclub.cu with spam-scanned (Exim 4.63
(FreeBSD))
(envelope-from <ajfweb(a)googlemail.com>)
id 1NdTNq-000IDE-7k
for cl2raul(a)cha.jovenclub.cu; Fri, 05 Feb 2010 18:58:28 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mx1.jovenclub.cu
X-Spam-Level:
X-Spam-Status: No, score=-1.2 required=4.0 tests=ALL_TRUSTED,HTML_MESSAGE,
MAILTO_TO_SPAM_ADDR autolearn=ham version=3.1.6
Received: from mail-pz0-f182.google.com ([209.85.222.182])
by mx1.jovenclub.cu with esmtp (Exim 4.63 (FreeBSD))
(envelope-from <ajfweb(a)googlemail.com>)
id 1NdTNn-000ICP-09
for cl2raul(a)cha.jovenclub.cu; Fri, 05 Feb 2010 18:58:26 +0000
Received: by pzk12 with SMTP id 12so4356424pzk.13
for <cl2raul(a)cha.jovenclub.cu>; Fri, 05 Feb 2010 10:58:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlemail.com; s=gamma;
h=domainkey-signature:mime-version:received:in-reply-to:references
:from:date:message-id:subject:to:content-type;
bh=Qjk7GMbRPg6inIkmDQ9DobZkrya+x133yYcrqGKOV/s=;
b=E7Ib+hPZq0DnQoANH+Nm+wXSRntTlNmh6rFqQQzQl9/mUB4U/lfGq2/2DAeL/3CSi4
qDexVPr9cJgfYJQgbrWenSF0AStaHKKPXnx8cLdXbgmTKuS/NxH3vp1wTE1PJmWwEA71
1OWpVC6onFv/M3rFvazpXkBl5Qj7IJk1wr7Hw=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=googlemail.com; s=gamma;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:content-type;
b=iY13PwPYzh1Na4Qq70qyWEjChhA0VmqlvPgD9zjgwXB+PtIWJzISeq/Fa928RmuhLb
y1mOwDTK3ucwm6AZ03TdGRwUV87eHbPn8AW16r8gdvIbzn6cPg8g+p6dBk9B9jP5YrCv
hQY2IrCYgkLpRmsV1iyzmhxm0EJ4NDBHnP3Gc=
MIME-Version: 1.0
Received: by 10.141.90.15 with SMTP id s15mr2119324rvl.137.1265396333097;
Fri,
05 Feb 2010 10:58:53 -0800 (PST)
In-Reply-To: <
41245.192.168.54.4.1265395610.squirrel(a)webmail.cha.jovenclub.cu>
References: <41245.192.168.54.4.1265395610.squirrel(a)webmail.cha.jovenclub.cu
>
From: Andrew Faulds <ajfweb(a)googlemail.com>
Date: Fri, 5 Feb 2010 18:58:33 +0000
Message-ID: <bac4c08c1002051058i494abe2oe655dd2a5ab4c9f1(a)mail.gmail.com>
Subject: Re: [ros-dev] FLISOL 2010
To: cl2raul(a)cha.jovenclub.cu, ReactOS Development List <ros-dev(a)reactos.org>
Content-Type: multipart/alternative; boundary=000e0cd1124eef34f0047edf0ac2
--000e0cd1124eef34f0047edf0ac2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Please do bear in mind ReactOS is in ALPHA, i.e. not suitable for normal
use.
If you want such a CD, my advice would be to download the debug version of
reactos from the website and source code then burn the two files (the ISO
and the zip file) to a CD.
ReactOS has one CD if I remember correctly, that does all languages (If I'm
wrong please correct me)
Also, AFAIK ReactOS has no manuals, it has SOME documentation in the wiki,
but overall it lacks much documentation.
2010/2/5 Ra=FAl Avila Catal=E1 <raul08012(a)cha.jovenclub.cu>
> Hi for all the ReactOS community, soon brings near to him the FLISOL2010
> and want to take the CD that appears in the ReactOS page, since the
> discharge from tub makes to him impossible for the limited bandwidth that
> has in the island...
>
> Please if some interested party in collaborating, it need a CD that it
> contains the operative system ( in Spanish ), the source code of ReactOS
> and some manuals ( in Spanish )...
>
> I, will make oneself responsible for make copy them and distribute it for
> the happening, in order that the Cuban community that has not access to
> the Internet can obtain " the alternative of Windows ".
>
> They can me write directly to my address of post:
> raul08012(a)cha.jovenclub.cu
>
>
> R++
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
--000e0cd1124eef34f0047edf0ac2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Please do bear in mind ReactOS is in ALPHA, i.e. not suitable for normal us=
e.<br>If you want such a CD, my advice would be to download the debug versi=
on of reactos from the website and source code then burn the two files (the=
ISO and the zip file) to a CD.<br>
<br>ReactOS has one CD if I remember correctly, that does all languages (If=
I'm wrong please correct me)<br><br>Also, AFAIK ReactOS has no manuals=
, it has SOME documentation in the wiki, but overall it lacks much document=
ation.<br>
<br><div class=3D"gmail_quote">2010/2/5 Ra=FAl Avila Catal=E1 <span dir=3D"=
ltr"><<a href=3D"mailto:raul08012@cha.jovenclub.cu">raul08012(a)cha.jovenc=
lub.cu</a>></span><br><blockquote class=3D"gmail_quote" style=3D"margin:=
0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left=
: 1ex;">
Hi for all the ReactOS community, soon brings near to him the FLISOL2010<br=
>
and want to take the CD that appears in the ReactOS page, since the<br>
discharge from tub makes to him impossible for the limited bandwidth that<b=
r>
has in the island...<br>
<br>
Please if some interested party in collaborating, it need a CD that it<br>
contains the operative system ( in Spanish ), the source code of ReactOS<br=
>
and some manuals ( in Spanish )...<br>
<br>
I, will make oneself responsible for make copy them and distribute it for<b=
r>
the happening, in order that the Cuban community that has not access to<br>
the Internet can obtain " the alternative of Windows ".<br>
<br>
They can me write directly to my address of post: <a href=3D"mailto:raul080=
12(a)cha.jovenclub.cu">raul08012(a)cha.jovenclub.cu</a><br>
<br>
<br>
R++<br>
<br>
<br>
_______________________________________________<br>
Ros-dev mailing list<br>
<a href=3D"mailto:Ros-dev@reactos.org">Ros-dev(a)reactos.org</a><br>
<a href=3D"http://www.reactos.org/mailman/listinfo/ros-dev" target=3D"_blan=
k">http://www.reactos.org/mailman/listinfo/ros-dev</a><br>
</blockquote></div><br>
--000e0cd1124eef34f0047edf0ac2--
Since this is true and the ros-amd64-bringup tree is up to date with
the region and WND code I committed without the assumed fixes to the
region leaks in my working tree,,,,,,,,,,, Also to note I was looking
for a ghost,,,,, wasting my TIME!,,,,
Is it possible to build ros-amd64-bringup in 32 bit mode?
So,,,,, I can continue my work and commit my updates to head knowing
I'm not the FFFf ff uf problem!
FYFI: I just finished a point to point compare and the only
differences are kernel changes!
Thanks,
James
On Thu, Feb 4, 2010 at 10:05 PM, <tkreuzer(a)svn.reactos.org> wrote:
> Author: tkreuzer
> Date: Fri Feb 5 04:05:51 2010
> New Revision: 45433
>
> URL: http://svn.reactos.org/svn/reactos?rev=45433&view=rev
> Log:
> [NTOS]
> On MSVC implement _lgdt, __sgdt, __lldt, __sldt, __ltr and __str as assembly functions, because there is no inline assembly.
> The MSVC/ML64 built kernel now boots and WinDbg connects.
And there was much rejoicing ;)
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
