Ros-dev

ros-dev@reactos.org

5790 discussions

FLISOL 2010
by Raúl Avila Catalá 10 Feb '10

10 Feb '10

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++

10 19

[HAL]: Regression in Real Hardware relates to HAL changes
by victor martinez 10 Feb '10

10 Feb '10

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

1 0

RosBE 1.5 is here - Mandatory update!
by Colin Finck 09 Feb '10

09 Feb '10

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

1 0

Re: [ros-dev] [ros-diffs] [sir_richard] 45525: [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 ==.
by Hervé Poussineau 09 Feb '10

09 Feb '10

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é

1 0

Trap handler rewrite
by Timo Kreuzer 06 Feb '10

06 Feb '10

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

2 1

Fwd: Mail delivery failed: returning message to sender
by Andrew Faulds 05 Feb '10

05 Feb '10

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. 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. 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 document= ation. <div class=3D"gmail_quote">2010/2/5 Ra=FAl Avila Catal=E1 <<a href=3D"mailto:raul08012@cha.jovenclub.cu">raul08012(a)cha.jovenc= lub.cu</a>> <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 discharge from tub makes to him impossible for the limited bandwidth that<b= r> 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<br= > and some manuals ( in Spanish )... 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 the Internet can obtain " the alternative of Windows ". 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> R++ _______________________________________________ Ros-dev mailing list <a href=3D"mailto:Ros-dev@reactos.org">Ros-dev(a)reactos.org</a> <a href=3D"http://www.reactos.org/mailman/listinfo/ros-dev" target=3D"_blan= k">http://www.reactos.org/mailman/listinfo/ros-dev</a> </blockquote></div> --000e0cd1124eef34f0047edf0ac2--

1 0

Debugging at the next level...
by Timo Kreuzer 05 Feb '10

05 Feb '10

Source level debugging thanks to MSVC and pdb files. Only the line numbers seem to be a bit off.

4 3

ros-amd64-bringup! Surprise! No Region Leaks!
by James Tabor 05 Feb '10

05 Feb '10

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

3 5

Re: [ros-dev] [ros-diffs] [tkreuzer] 45433: [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.
by Steven Edwards 05 Feb '10

05 Feb '10

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

1 0

Kernel Crash per Rev 45401
by James Tabor 05 Feb '10

05 Feb '10

Seems to be very common. *** Fatal System Error: 0x0000007f (0x00000008,0x00000000,0x00000000,0x00000000) Entered debugger on embedded INT3 at 0x0008:0x808c6708. kdb:> bt Eip: <ntoskrnl.exe:c6709 (lib/rtl/i386/debug_asm.S:42 (RtlpBreakWithStatusInstruction))> Frames: <ntoskrnl.exe:9e6d (ntoskrnl/ke/bug.c:1110 (KeBugCheckWithTf@24))> <ntoskrnl.exe:35d7 (ntoskrnl/ke/i386/exp.c:1170 (KeRaiseUserException@4))> <ntoskrnl.exe:60cb (ntoskrnl/ke/i386/traphdlr.c:741 (@KiTrap09Handler@4))> <00000000> kdb:>

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev