Hello,
My name is Neeraj Yadav. I am an undergraduate student of Indian Institute
of Technology, Delhi studying Textile Engineering.Besides my regular studies
I have interest in Multimedia, Networking, Network-Programming and
Security.I have a decent knowledge of C and C++ programming.I am familiar
with git and svn.I am familiar with Linux, windows and Symbian APIs.I have
experience of UI design with Qt.
ReactOS is coming as my new interest and luckily this year ReactOS has been
selected as a mentoring organisation.I find myself appropriate for SSH
server implementation and Audio Mixer Project.
Windows doesn't do any access checks in ProbeForRead, it only checks the
range and alignment. The MmUserProbeAddress access is used to raise an
exception with the appropriate parameters. So the old version was
correct (except for the misleading comment maybe)
Am 21.03.2011 15:43, schrieb rharabien(a)svn.reactos.org:
> Author: rharabien
> Date: Mon Mar 21 14:43:56 2011
> New Revision: 51108
>
> URL: http://svn.reactos.org/svn/reactos?rev=51108&view=rev
> Log:
> Fix ProbeForRead. It wasn't ever checking if memory can be accessed. Thanks to big-endian it wasn't breaking MmUserProbeAddress as well. Code is now nearly the same as in ProbeForWrite. It shouldn't break anything. If it does, it's not bug in this code. :)
>
> Modified:
> trunk/reactos/ntoskrnl/ex/exintrin.c
>
> Modified: trunk/reactos/ntoskrnl/ex/exintrin.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ex/exintrin.c?rev…
> ==============================================================================
> --- trunk/reactos/ntoskrnl/ex/exintrin.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/ex/exintrin.c [iso-8859-1] Mon Mar 21 14:43:56 2011
> @@ -103,6 +103,8 @@
> IN SIZE_T Length,
> IN ULONG Alignment)
> {
> + ULONG_PTR Last, Current = (ULONG_PTR)Address;
> + CHAR Temp;
> PAGED_CODE();
>
> /* Only probe if we have a valid length */
> @@ -115,18 +117,31 @@
> (Alignment == 8) ||
> (Alignment == 16));
>
> - /* Check for correct alignment */
> - if (((ULONG_PTR)Address& (Alignment - 1)) != 0)
> + /* Check the alignment */
> + if ((Current& (Alignment - 1)) != 0)
> {
> /* Incorrect alignment */
> ExRaiseDatatypeMisalignment();
> }
> - else if (((ULONG_PTR)Address + Length)< (ULONG_PTR)Address ||
> - ((ULONG_PTR)Address + Length)> (ULONG_PTR)MmUserProbeAddress)
> +
> + /* Get the end address */
> + Last = Current + Length - 1;
> + if ((Last< Current) || (Last>= (ULONG_PTR)MmUserProbeAddress))
> + {
> + /* Raise an access violation */
> + ExRaiseAccessViolation();
> + }
> +
> + /* Round down to the last page */
> + Last = PAGE_ROUND_DOWN(Last) + PAGE_SIZE;
> + do
> {
> /* Attempt a read */
> - *(volatile CHAR* const)MmUserProbeAddress = 0;
> - }
> + Temp = *(volatile CHAR*)Current;
> +
> + /* Go to the next address */
> + Current = PAGE_ROUND_DOWN(Current) + PAGE_SIZE;
> + } while (Current != Last);
> }
> }
>
>
>
>
Hi,
both doxygen.reactos.org & iso.reactos.org are down (which results in daily builds isos not being uploaded).
Anyone able to fix them?
Regards,
P. Schweitzer
Hi,
currently working on HAL and HAL targets (ACPI, MP, UP and so on), I discovered a quite bad issue in our build process.
Just look at the function HalInitSystem@8 (halinit.c), depending on the build target we don't add the same code (look at CONFIG_SMP, which is only defined for HAL MP). But, currently, as we are building using HAL library for reducing code redudancy, this halinit.c file is only built ONCE. So, build targets aren't taken into account (MP, ACPI).
So, two choices, or we break that model, and forget about lib, and just keep base .rbuild (hal.rbuild, halacpi.rbuild, and so forth) with all files defined in those.
Or with find something smarter better such as rebuilding the lib with the new flags for each build?
Or finding a way to include .rbuild files in other rbuild files?
I'm not really sure about the way to proceed, that's why I "release" that question to the whole ML. Furthermore, could CMAKE be any use here? To facilitate the process?
Regards,
P. Schweitzer
Hello RoS developers,
I introduce myself. I'm Guillaume Touron, I'm a French engineering student
at National School of Computer Science and Applied Mathematics with
specialization in information systems and security. Apart from my studies I
am interested in OS development, Windows internals and application security
(vulnerabilities, reverse engineering, rootkits...). I read a lot about how
Windows internals work (kernel data structures...) and Windows security. I
have also some experience in NT driver development and kernel debugger
(WinDBG).
For many months now, I study RoS source code, and especially ntoskrnl
source. This includes object manager, i/o manager, security layer,
traps/exceptions management... I checkouted source code and installed RoS
build environment and I'm ready to begin development. I also took a look at
Se* kernel exported APIs, and tried to understand how security checks were
performed. That's why I'm interested in RoS GSoC Idea 'Security Controls'.
Indeed, implementing this feature would be a good start to add multiuser
experience in RoS which is currently missing, and to manage efficiently
users and groups. I think I know what is needed to complete this project
successfully and I'm ready to write a detailed presentation/proposal to
explain what I understand and what would be my goals. I also did GSoC 2010
last year for Honeynet Project on network security area, but I'm more
interested in kernel development.
Finally, few questions : What should I do to propose in a formal way my
proposal to RoS community ? Is it an obligation to have already send some
patches or can we begin development as a new contributor ? Who can I
contact to speak about technical details ?
Thank you very much.
I have been doing some investigation on theming. I have been looking
into comctl32.
One of the issues is that windows version 5 of the control has not
theming and uses SxS so that applications that use version 6 will get
themed controls.
Currently comctl only has one version and applies theming regardless
of the version the application requests.
I have spoken on the Wine mailing list and the only person that
replied did not want to use SxS. I assume to make it easier to
maintain(though i don't understand why common parts cant share the
same files and build 2 dlls). I was wondering what React OS developers
think is the best choice.
The second issue is that if comctl32 version 6 is loaded in windows it
takes control of components that are usually in user32. Someone said
this was called ( window class redirection). I can't really find any
information on it. Though isn't this just registering the class except
from comctl32? or does this cause a race condition(with the last one
one loaded taking control)? is this is how "window class redirection"
is different?
Also the last thing is. Should sub classing be used? You should be
able to load another window proc method even from user32 and call it
when it is suitable from new control. I would imagine this could cause
issues when the default procedure can't handle something as the new
control would.
Any advise would be much appreciated.
Dear colleagues
I am very pleased to inform you that a new builder has been just made
operational. Named Patch_x86_GCCWin Debug, you can see it waterfall right
now. Based on x86 RBuild trunk, its capable of downloading a patch from
bugzilla, applying it to trunk, building reactos testcd and running
winetests on it via VBox sysreg.
To use it, just pass revision, as well as Parameter 1, name id, value:
attachement id.
For example, http://www.reactos.org/bugzilla/attachment.cgi?id=5989
name: id, value: 5989
Just the same way you use source for vbox retesting. Right now test ISOs are
stored, named with x86_Patch, revision and patch id. Logs itself will be
also stored (when i bugfix them)
If any issues arise, please mail me or catch me on irc.