With the question continually arising regarding the binutils issue, would it
not be an idea to have an build announcement section on the site where notes
can be placed for all to see.
A lot of people don't use IRC or read the mailing list, so it might also be
useful to keep people updated with the happenings in SVN too. e.g. when
accept was committed, current status of USB, etc.
Gedi
************************************************************************
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
ion(a)svn.reactos.com wrote:
>SYSENTER support, INT2E Optimization, new Syscall Table/Stub generator and svn:ignore fixes. Please read associated Mailing List Post.
>
>
>Added files:
>trunk/reactos/tools/nci/
>trunk/reactos/tools/nci/makefile
>trunk/reactos/tools/nci/ncitool.c
>trunk/reactos/tools/nci/sysfuncs.lst
>trunk/reactos/tools/nci/w32ksvc.db
>
>Updated files:
>trunk/reactos/Makefile
>trunk/reactos/config
>trunk/reactos/include/napi/shared_data.h
>trunk/reactos/ntoskrnl/Makefile
>trunk/reactos/ntoskrnl/include/internal/i386/ke.h
>trunk/reactos/ntoskrnl/include/internal/i386/ps.h
>trunk/reactos/ntoskrnl/ke/i386/bthread.S
>trunk/reactos/ntoskrnl/ke/i386/exp.c
>trunk/reactos/ntoskrnl/ke/i386/gdt.c
>trunk/reactos/ntoskrnl/ke/i386/kernel.c
>trunk/reactos/ntoskrnl/ke/i386/stkswitch.S
>trunk/reactos/ntoskrnl/ke/i386/syscall.S
>trunk/reactos/ntoskrnl/ke/i386/usercall.c
>trunk/reactos/ntoskrnl/ke/kthread.c
>trunk/reactos/ntoskrnl/ke/process.c
>trunk/reactos/ntoskrnl/ps/i386/continue.c
>trunk/reactos/subsys/system/vmwinst/vmwinst.c
>
>Deleted files:
>trunk/reactos/iface/
>
>
>
First and foremost, I would really like to thank all the people behind
the scenes of this patch; Filip Navara, for the initial implementation
and thoughts, and his consistent help, Art Yerkes for his invaluable
testing, and everyone else who lent a hand (too many people to list here).
This patch improves by around 15-20% (tested but not scientific) the
speed of ReactOS on all hardware and virtual machines. Furthermore, it
improves speed by over 50% (tested but not scientific) on hardware
supporting the SYSENTER/SYSEXIT call pair.
On VMWare however, due to causes still under investigation,
SYSENTER/SYSEXIT must be disabled, or else there is a 3X slowdown.
Vmwinst takes care of writing the Windows-compatible Value in the
Registry, and it is read before choosing which kind of call to execute.
This means that vmware is able to take advantage of the ~20% speedup,
but not of all the full capability of this patch.
It also combines the previous iface tools into a single, much more
dynamic and small utility, which I called NCITool (Native Call Interface
Tool). Although it is almost final, I still have to set-up the macros
for portability and msvc compatibility, so this is a known issue (note
however that the previous version suffered from the same
incompatibilies). I will fix it during the week. I would like to thank
Emanuelle and KJK::Hyperion for the original tool, and most of the
parsing code has remained intact, apart from some code-duplication
removal and simplification.
The following two issues remain in this patch, which I will look at this
week as well:
1) SMP. I have not tested SYSENTER on an SMP machine, and I believe that
the MSRs must be written on other CPUs as well, perhaps using an IPI?
2) Pentium Pro. It erronously reports the SEP flag but does not support
SYSENTER. Code must be added at the related FIXME in order to check for
this.
I have, along with others, tested this patch for more then a week now,
and I have found no visible problems, apart from the VMWare weirdness.
If any problems are noticed due to it, please post accordingly and I
will have a look at it.
Best regards,
Alex Ionescu
gvg(a)svn.reactos.com wrote:
>Implement LOAD_LIBRARY_AS_DATAFILE flag
>
>
>
Typecasting PVOID to ULONG isn't portable...ULONG_PTR is supposed to be
used. Also BOOLEAN should be prefered over BOOL for internal stuff.
Best Regards
Thomas
Hi,
This is Polonium from the irc channel (although I’m not in there all the
time)
Just trying to gather what’s happening with USB support, more specifically
the host controller interfaces that are required to lie below the usb device
drivers.
Is there anyone currently working on this?
If not, are there any programmers who would like to solely focus on
implementing, for example, a universal host controller interface for
ReactOS.
While I do not know much about the topic myself, with ample resources and
team members I may be able to make a good start. Anyone else interested? The
specifications for the interfaces can be found on the Intel website.
Regards
Ryan O’Connor
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.808 / Virus Database: 550 - Release Date: 12/8/2004
WOW!
arty(a)svn.reactos.com wrote:
> Added forgotten .h ext2lib.h
>
>
>
> Added files:
> branches/ext2/reactos/include/fslib/ext2lib.h
>
Does this mean we have ext2 support?
James
Hi,
Attached patch should fix some problems of RtlStoreUlong().
1) store SECONDBYTE of the value correctly.
2) store a ULONG value but not a ULONG_PTR value.
There is RtlStoreUlongPtr() which stores a ULONG_PTR value.
http://msdn.microsoft.com/library/en-us/kmarch/hh/kmarch/k109_2dd28516-e8e4…
--
d_layer
Thank you for your help.I will ask your question at there.
regards,
yang
>
> Hi yang,
> come to irc channel, #reactos, there are many people, and some will
> definately answer your question. When I'm online, I can try to help you
> also.
>
>
> With the best regards,
> Aleksey Bragin (aka "Fireball" on irc).
>
> Probably you need to practice C a little more ;-)
Thank you very much,I will try my best to practice.
>
> I think this depends a lot on which part of the code you want to read. If you
> are trying to understand parts of NTOSKRNL it will be helpful to read at
> least the thing about memory management in the IA32 manual. On the other side
> if you are looking at our Mesa3D copy, you should probably be good at maths.
Now I'm studing about 80x86 assembly. Do you think it work?
>
>
> HTH,
> blight
regards,
yang
Hello everyone!
I am a newbie, now I am a sophomore. I learn the C programming language last year. And one month ago I found this project, and begin to read the source code last three week. But I found there are to many thing that doesn't mention in my book. I can't undertand the source code. Who want to tell me what I had to study and answer some question as a teacher even if some question may be stupid.
Thanks to help a chinese open source software fan.
Regards,
yang