Hi,
Please think twice before committing to the ReactOS repo.
The most recent example is the format/lang/uk-UA.rc changes that have
absolutely nothing to do with the "Russian translation update by Sergey
Stopkin." commit log.
When you do that, you'll always be committing while being calm and in
control of what you're sending. The svn history is a responsibility
shared between the ReactOS developers.
Regards,
Amine.
Le 06/10/2016 à 21:01, hbelusca(a)svn.reactos.org a écrit :
> Author: hbelusca
> Date: Thu Oct 6 19:01:33 2016
> New Revision: 72922
>
> URL: http://svn.reactos.org/svn/reactos?rev=72922&view=rev
> Log:
> [KD]
> - When enabling or disabling the kernel debugger and setting the KdDebuggerEnabled flag, also update the corresponding user-mode flag in SharedUserData->KdDebuggerEnabled.
> - Turn KdpGetMemorySizeInMBs into a INIT_FUNCTION.
> - Print kernel command line & ARC paths even in debug log file mode.
>
> [KD64]
> WinKD: Also print our nice ReactOS debug header (version, # of processors & memory MB, kernel command line and ARC paths).
>
> Modified:
> trunk/reactos/ntoskrnl/kd/kdinit.c
> trunk/reactos/ntoskrnl/kd/kdio.c
> trunk/reactos/ntoskrnl/kd/kdmain.c
> trunk/reactos/ntoskrnl/kd64/kdapi.c
> trunk/reactos/ntoskrnl/kd64/kdinit.c
>
> Modified: trunk/reactos/ntoskrnl/kd/kdio.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/kd/kdio.c?rev=729…
> ==============================================================================
> --- trunk/reactos/ntoskrnl/kd/kdio.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/kd/kdio.c [iso-8859-1] Thu Oct 6 19:01:33 2016
> @@ -240,10 +243,15 @@
> KeInitializeSpinLock(&KdpDebugLogSpinLock);
>
> /* Display separator + ReactOS version at start of the debug log */
> - DPRINT1("---------------------------------------------------------------\n");
> + DPRINT1("-----------------------------------------------------\n");
This specific change has likely broken any testbot running sysreg2 and
vmware or vbox.
Why was this change even needed?
--
Pierre Schweitzer <pierre at reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
On 2016-10-05 11:33, akhaldi(a)svn.reactos.org wrote:
> --- trunk/rostests/apitests/ws2_32/getnameinfo.c (added)
> +++ trunk/rostests/apitests/ws2_32/getnameinfo.c [iso-8859-1] Wed Oct 5 09:33:03 2016
> @@ -0,0 +1,99 @@
> +/*
> + * PROJECT: ReactOS api tests
> + * LICENSE: GPLv2+ - See COPYING in the top level directory
> + * PURPOSE: Test for getaddrinfo
> + * PROGRAMMER: Thomas Faber <thomas.faber(a)reactos.org>
> + */
Thanks for the credit, but I don't think I deserve it ;)
Good afternoon gentlemen...
Seems the list server has gone on a vacation.
Still waiting on the digest where Hermes added to Thomas answer..
Anyway Hermes pasted his answer to my mailbox (thank you) and so..
One more step is required in addition to the answers from Thomas and
Hermes..
A small patch in 'base/setup/usetup/bootsup.c', which contains the code
that writes 'freeldr.ini' to the HD during install. Without patching in
the desired
COM port there, trace is lost after ROS installation reboots from HD.
Perhaps we should have a wiki page to cover this ?
And/or perhaps we should make it easier to make this mod,
by moving the hard coded strings from bootsup.c into
an ini file or whatever ?
Anyway, I got my install trace, and posted a clip concerning
the Gecko breakage to CORE-12011.
Best Regards
L.
Hello,
Let me invite you to the monthly status meeting taking place this
Thursday, 29th of September, 19:00 UTC.
IRC service will only be started shortly before the meeting. Your
participation passwords and server address will be emailed to you
shortly before the meeting starts, and they are going to be different
once again as they are not stored in any database. Hopefully it's not
much of inconvenience.
Or we'll do it in #reactos-meeting on Freenode, depeonds on our admins.
Please send agenda proposals to me before the meeting so we don't waste
time trying to setup the agenda directly during the meeting.
Regards,
Aleksey Bragin
Thanks Thomas,
Yes and No...
I added Options=/DEBUG /DEBUGPORT=COM2 /BAUDRATE=115200 /SOS / KDSERIAL
which ended up on the BootCD all right, but it seems KD is never brought
in, or doesn't
use the settings from freeldr.ini on the BootCD, so no trace :/
(Ok, /SOS was perhaps a bit over the top, but anyway.)
Do you know where the source is for what becomes 'freeldr.ini' on the HD
after installation? If I can modify that, I can at least get a trace on
the later
phases of installation, after ROS boots from HD.
Then I might get a hint on why the Wine Gecko installer is broken.
(It waits forever for whatever it might be.. Lucky it can be canceled.)
Speaking of which, shouldn't the Wine Gecko installer be included
in the RosApps list so one can install it later? ATM it isn't.
Best Regards
L.
On 2016-09-27 19.00, Thomas Faber <thomas.faber(a)reactos.org> wrote:
> You should be able to simply add an
> Options=...
> line to the [Setup] section in boot/bootdata/bootcd.ini to modify
> the setup's freeldr options. That file becomes freeldr.ini in the root
> dir of the BootCD.
>
>
> On 2016-09-27 12:21, Love Nystrom wrote:
>> >Good afternoon gentlemen..
>> >
>> >Can anyone tell me at what point during ROS installation KD becomes
>> >operative?
>> >And if there is a way to change the default KD COM port from COM1 to COM2
>> >in order to trace KD output during installation?
>> >
>> >(I run my ROS tests on VMware with a com0com connection from ReactOS COM2
>> >to my host machine, which works fine after install is complete and I can
>> >edit freeldr.ini,
>> >but I'd like to be able to collect KD output during installation as well.)
>> >
>> >(COM1 is not an option, since it's a physical port on both host and guest.)
>> >
>> >Do I have to patch KD itself ?
>> >
>> >Best Regards
>> >L.
--
There is one thing stronger than all the armies in the world,
and that's an idea whose time has come. [Victor Hugo]
Good afternoon gentlemen..
Can anyone tell me at what point during ROS installation KD becomes
operative?
And if there is a way to change the default KD COM port from COM1 to COM2
in order to trace KD output during installation?
(I run my ROS tests on VMware with a com0com connection from ReactOS COM2
to my host machine, which works fine after install is complete and I can
edit freeldr.ini,
but I'd like to be able to collect KD output during installation as well.)
(COM1 is not an option, since it's a physical port on both host and guest.)
Do I have to patch KD itself ?
Best Regards
L.
Agreed..
When the assignment and assert are separated by a call
of X distance, the assert is certainly warranted.
Just not as it stands in ke_x.h
Perhaps you could factorize as suggested, Dmitri?
Best regards
L.
On 2016-09-26 10.28, ros-dev-request(a)reactos.org wrote:
> Rationale is simple:
>
> The real headers contain a KeEnterCriticalRegionThread function, which
> has this assert, and a KeEnterCriticalRegion function, which calls
> that function with KeGetCurrentThread() at input. This is an
> optimization such that if you already have the current thread of
> interest somewhere, you can call KeEnterCriticalRegionThread and avoid
> reading from FS or GS again. ReactOS combines these two functions in
> one, and as such the ASSERT appears pointless. Factoring the functions
> would've been the correct approach -- not removing the ASSERT.
>
> Best regards,
> Alex Ionescu
--
There is one thing stronger than all the armies in the world,
and that's an idea whose time has come. [Victor Hugo]
Agreed..
When the assignment and assert are separated by a call
of X distance, the assert is certainly warranted.
Just not as it stands in ke_x.h
Perhaps you could factorize as suggested, Dmitri?
Best regards
L.
On 2016-09-26 10.28, ros-dev-request(a)reactos.org wrote:
> Rationale is simple:
>
> The real headers contain a KeEnterCriticalRegionThread function, which
> has this assert, and a KeEnterCriticalRegion function, which calls
> that function with KeGetCurrentThread() at input. This is an
> optimization such that if you already have the current thread of
> interest somewhere, you can call KeEnterCriticalRegionThread and avoid
> reading from FS or GS again. ReactOS combines these two functions in
> one, and as such the ASSERT appears pointless. Factoring the functions
> would've been the correct approach -- not removing the ASSERT.
>
> Best regards,
> Alex Ionescu
--
There is one thing stronger than all the armies in the world,
and that's an idea whose time has come. [Victor Hugo]
Rationale is simple:
The real headers contain a KeEnterCriticalRegionThread function, which has
this assert, and a KeEnterCriticalRegion function, which calls that
function with KeGetCurrentThread() at input. This is an optimization such
that if you already have the current thread of interest somewhere, you can
call KeEnterCriticalRegionThread and avoid reading from FS or GS again.
ReactOS combines these two functions in one, and as such the ASSERT appears
pointless. Factoring the functions would've been the correct approach --
not removing the ASSERT.
Best regards,
Alex Ionescu
On Sun, Sep 25, 2016 at 8:13 PM, Love Nystrom <love.nystrom(a)gmail.com>
wrote:
> I don't want to trod on anyone's tail, but
> assigning _Thread = KeGetCurrentThread(), and
> then asserting _Thread == KeGetCurrentThread()
> on the next line does seem excessively myopic, yes ?
>
> Unless you expect KeGetCurrentThread() to be fubar
> and return rand(), in which case the assert should be removed
> when KeGetCurrentThread() gets it's head on straight.
>
> As to the talent, or lack thereof, of MS programmers,
> we might talk about it if we ever have a table with some
> beer on it between us.
>
> They're not *all* wrong.. no ;)
> L.
>
> On 2016-09-24 23.23, ros-dev-request(a)reactos.org wrote:
>
> Subject:
> Re: [ros-dev] [ros-diffs] [dchapyshev] 72787: [NTOSKRNL] Remove unneeded
> sanity checks
>
> From:
> Alex Ionescu <ionucu(a)videotron.ca> <ionucu(a)videotron.ca>
>
> Date:
> 2016-09-24 21.29
>
> To:
> ReactOS Development List <ros-dev(a)reactos.org> <ros-dev(a)reactos.org>
>
> CC:
> Linda Wang <ros-diffs(a)reactos.org> <ros-diffs(a)reactos.org>
>
> Thanks for removing stuff that exists in the NT kernel as sanity
> checks -- the entire MS dev team must be wrong, thanks for correcting
> them all :)
>
> Make sure not to ask "anyone can explain these checks? they seem
> useless to me" when removing stuff like this.
> Best regards,
> Alex Ionescu
>
>
> On Sat, Sep 24, 2016 at 2:30 AM, <dchapyshev(a)svn.reactos.org> <dchapyshev(a)svn.reactos.org> wrote:
>
> > Author: dchapyshev> Date: Sat Sep 24 09:30:06 2016> New Revision: 72787>> URL: http://svn.reactos.org/svn/reactos?rev=72787&view=rev> Log:> [NTOSKRNL] Remove unneeded sanity checks>> Modified:> trunk/reactos/ntoskrnl/include/internal/ke_x.h>> Modified: trunk/reactos/ntoskrnl/include/internal/ke_x.h> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/internal/…> ==============================================================================> --- trunk/reactos/ntoskrnl/include/internal/ke_x.h [iso-8859-1] (original)> +++ trunk/reactos/ntoskrnl/include/internal/ke_x.h [iso-8859-1] Sat Sep 24 09:30:06 2016> @@ -25,7 +25,6 @@> \> /* Sanity checks */ \> ASSERT(KeGetCurrentIrql() <= APC_LEVEL); \> - ASSERT(_Thread == KeGetCurrentThread()); \> ASSERT((_Thread->SpecialApcDisable <= 0) && \> (_Thread->SpecialApcDisable != -32768)); \> \> @@ -42,7 +41,6 @@> \> /* Sanity checks */ \> ASSERT(KeGetCurrentIrql() <= APC_LEVEL); \> - ASSERT(_Thread == KeGetCurrentThread()); \> ASSERT(_Thread->SpecialApcDisable < 0); \> \> /* Leave region and check if APCs are OK now */ \> @@ -66,7 +64,6 @@> PKTHREAD _Thread = KeGetCurrentThread(); \> \> /* Sanity checks */ \> - ASSERT(_Thread == KeGetCurrentThread()); \> ASSERT((_Thread->KernelApcDisable <= 0) && \> (_Thread->KernelApcDisable != -32768)); \> \> @@ -82,7 +79,6 @@> PKTHREAD _Thread = KeGetCurrentThread(); \> \> /* Sanity checks */ \> - ASSERT(_Thread == KeGetCurrentThread()); \> ASSERT(_Thread->KernelApcDisable < 0); \> \> /* Enable Kernel APCs */ \>>
>
>
> --
> There is one thing stronger than all the armies in the world,
> and that's an idea whose time has come. [Victor Hugo]
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
I don't want to trod on anyone's tail, but
assigning _Thread = KeGetCurrentThread(), and
then asserting _Thread == KeGetCurrentThread()
on the next line does seem excessively myopic, yes ?
Unless you expect KeGetCurrentThread() to be fubar
and return rand(), in which case the assert should be removed
when KeGetCurrentThread() gets it's head on straight.
As to the talent, or lack thereof, of MS programmers,
we might talk about it if we ever have a table with some
beer on it between us.
They're not *all* wrong.. no ;)
L.
On 2016-09-24 23.23, ros-dev-request(a)reactos.org wrote:
> Subject:
> Re: [ros-dev] [ros-diffs] [dchapyshev] 72787: [NTOSKRNL] Remove
> unneeded sanity checks
> From:
> Alex Ionescu <ionucu(a)videotron.ca>
> Date:
> 2016-09-24 21.29
>
> To:
> ReactOS Development List <ros-dev(a)reactos.org>
> CC:
> Linda Wang <ros-diffs(a)reactos.org>
>
>
> Thanks for removing stuff that exists in the NT kernel as sanity
> checks -- the entire MS dev team must be wrong, thanks for correcting
> them all:)
>
> Make sure not to ask "anyone can explain these checks? they seem
> useless to me" when removing stuff like this.
> Best regards,
> Alex Ionescu
>
>
> On Sat, Sep 24, 2016 at 2:30 AM,<dchapyshev(a)svn.reactos.org> wrote:
>> >Author: dchapyshev
>> >Date: Sat Sep 24 09:30:06 2016
>> >New Revision: 72787
>> >
>> >URL:http://svn.reactos.org/svn/reactos?rev=72787&view=rev
>> >Log:
>> >[NTOSKRNL] Remove unneeded sanity checks
>> >
>> >Modified:
>> > trunk/reactos/ntoskrnl/include/internal/ke_x.h
>> >
>> >Modified: trunk/reactos/ntoskrnl/include/internal/ke_x.h
>> >URL:http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/inter…
>> >==============================================================================
>> >--- trunk/reactos/ntoskrnl/include/internal/ke_x.h [iso-8859-1] (original)
>> >+++ trunk/reactos/ntoskrnl/include/internal/ke_x.h [iso-8859-1] Sat Sep 24 09:30:06 2016
>> >@@ -25,7 +25,6 @@
>> > \
>> > /* Sanity checks */ \
>> > ASSERT(KeGetCurrentIrql() <= APC_LEVEL); \
>> >- ASSERT(_Thread == KeGetCurrentThread()); \
>> > ASSERT((_Thread->SpecialApcDisable <= 0) && \
>> > (_Thread->SpecialApcDisable != -32768)); \
>> > \
>> >@@ -42,7 +41,6 @@
>> > \
>> > /* Sanity checks */ \
>> > ASSERT(KeGetCurrentIrql() <= APC_LEVEL); \
>> >- ASSERT(_Thread == KeGetCurrentThread()); \
>> > ASSERT(_Thread->SpecialApcDisable < 0); \
>> > \
>> > /* Leave region and check if APCs are OK now */ \
>> >@@ -66,7 +64,6 @@
>> > PKTHREAD _Thread = KeGetCurrentThread(); \
>> > \
>> > /* Sanity checks */ \
>> >- ASSERT(_Thread == KeGetCurrentThread()); \
>> > ASSERT((_Thread->KernelApcDisable <= 0) && \
>> > (_Thread->KernelApcDisable != -32768)); \
>> > \
>> >@@ -82,7 +79,6 @@
>> > PKTHREAD _Thread = KeGetCurrentThread(); \
>> > \
>> > /* Sanity checks */ \
>> >- ASSERT(_Thread == KeGetCurrentThread()); \
>> > ASSERT(_Thread->KernelApcDisable < 0); \
>> > \
>> > /* Enable Kernel APCs */ \
>> >
>> >
--
There is one thing stronger than all the armies in the world,
and that's an idea whose time has come. [Victor Hugo]
Don't change code when runtime conditions evolve.Just give more RAM to the bot and it's over.
Envoyé depuis Yahoo Mail pour Android
Le jeu. j sept. PM à 18:01, Thomas Faber (JIRA)<noreply(a)reactos.org> a écrit :
[ https://jira.reactos.org/browse/CORE-12020?page=com.atlassian.jira.plugin.s… ]
Thomas Faber commented on CORE-12020:
-------------------------------------
First stage is extremely heavy on memory due to inf parsing. One thing that helped in a similar situation was to separate caroots.inf from registry.inf and have it parsed separately. We should probably do that in trunk...
> We're not able to perform DPH test runs anymore
> -----------------------------------------------
>
> Key: CORE-12020
> URL: https://jira.reactos.org/browse/CORE-12020
> Project: Core ReactOS
> Issue Type: Bug
> Reporter: Amine Khaldi
> Assignee: Bug Zilla
> Labels: REGRESSION
>
> https://build.reactos.org/builders/Test%20KVM/builds/15147/steps/test/logs/…
> https://jira.reactos.org/secure/attachment/37125/ was used with patchbot.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
Ros-bugs mailing list
Ros-bugs(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-bugs
Hi all,
Back in April, our server farm used for building had to leave its
hosting site (cf.
https://reactos.org/archives/public/ros-dev/2016-April/017775.html). A
single server was set up at the new site and I estimated to have our old
server farm back up by May or June.
Unfortunately, this still hasn't happened. Our server farm is still at
its old location and I cannot give a timeframe when it will finally be
shipped to the new location.
As we cannot wait forever for this to happen, I put up the old Windows
Home Server VM on our single new server and reintegrated it into
BuildBot ("Test WHS" builder).
Its performance won't match the former one for sure. Instead of 4GB of
RAM, it's currently at mere 1GB and it builds on HDD instead of
RAM-Disk. Nevertheless, it should be fully operational at least.
If this works out well, I'll see if I can also get our Win7 builder up
again. This would give us "Build GCCWin_x86", "Build MSVC_x64" and
"Build MSVC_x86".
I cannot resurrect the VMware and VBox testers right now though. This
will definitely need another machine. Will look after this in October.
Maybe we can also get a RAM upgrade for the existing machine to enable
building on RAM Disks again.
Cheers,
Colin
On 2016-08-28 19.00, ros-dev-request(a)reactos.org wrote:
> Subject:
> Re: [ros-dev] [ros-diffs] [gadamopoulos] 72398: [SHELL32] - Fail to
> delete any file if one is invalid. - Patch by andy-123 CORE-9959
> From:
> Thomas Faber <thomas.faber(a)reactos.org>
> Date:
> 2016-08-28 15.42
>
> To:
> ros-dev(a)reactos.org
>
>
> On 2016-08-20 11:43,gadamopoulos@svn.reactos.org wrote:
>> >--- trunk/reactos/dll/win32/shell32/shlfileop.cpp [iso-8859-1] (original)
>> >+++ trunk/reactos/dll/win32/shell32/shlfileop.cpp [iso-8859-1] Sat Aug 20 09:43:09 2016
>> >@@ -1480,6 +1480,19 @@
>> > return 0;
>> > }
>> >
>> >+ /* Check files. Do not delete one if one file does not exists */
>> >+ for (i = 0; i < flFrom->dwNumFiles; i++)
>> >+ {
>> >+ fileEntry = &flFrom->feFiles[i];
>> >+
>> >+ if ((HANDLE)fileEntry->attributes == INVALID_HANDLE_VALUE)
> What's wrong with INVALID_FILE_ATTRIBUTES?
Fully agree with Thomas.. That is wrong.. Attributes are not handles.
Further, this replicates the unacceptable behavior of the Windows shell,
whereby an entire list of files is dropped when just one fail.
I've argued, some years ago, that such lists should be continued,
ideally adding failed files to a "failed" list to be presented to the user.
You can *not* make any valid assumption of whether other files in the list
will fail just because one of them doesn't exist, or cant be moved because
it's locked, or whatever.
That you are currently writing on this code gives you a good opportunity
to make our shell better than Microsoft's in this regard.
Best Regards
// Neo
>
>> >+ {
>> >+ // This is a windows 2003 server specific value which has been removed.
>> >+ // Later versions of windows return ERROR_FILE_NOT_FOUND.
>> >+ return ERROR_SHELL_INTERNAL_FILE_NOT_FOUND;
>> >+ }
>> >+ }
>> >+
>> > for (i = 0; i < flFrom->dwNumFiles; i++)
>> > {
>> > bPathExists = TRUE;
--
There is one thing stronger than all the armies in the world,
and that's an idea whose time has come. [Victor Hugo]
I've seen like 4 people change this stuff recently and not one of them
got it 100% right.
So here are the rules for how to use probes and SEH:
* Probe pointers before accessing them. This ensures you're not reading
kernel mode memory (and does pretty much nothing else)
* Never access user mode pointers outside of SEH. The application
controls its address space, so protection, physical memory mapping
and contents can change out from under you at any point. For most
purposes, MmProbeAndLockPages is the only way to get around this.
* Sometimes there is no alternative to copying data to kernel memory.
If there is a pointer stored in user mode memory, you need a copy of
it because you can't rely on it not changing after your probe (even
if you lock down the memory).
* In case of an exception you usually want to return the exception code.
There are exceptions (heh) to this rule, but if you think you've
found one, better be sure and show it with a test.
* If you make a pool allocation whose size is directly influenced by
user mode input, there's a good chance you'll want to use
ExAllocatePoolWithQuotaTag
In particular this means:
* Probing something or accessing it once does not save you from using
SEH every single time you access the user mode memory
* Probing UserModePointer->StructMemberPointer is never correct, you
need to make a copy of the struct or that particular member, since
the memory can change
* The ProbeForReadUnicodeString function is not useful unless you use
its return value
Hope this helps. Thanks for hanging in there.
-T
On 2016-09-11 18:13, dchapyshev(a)svn.reactos.org wrote:
> Author: dchapyshev
> Date: Sun Sep 11 16:13:46 2016
> New Revision: 72655
>
> URL: http://svn.reactos.org/svn/reactos?rev=72655&view=rev
> Log:
> [NtUser] Try to fix tests for user32:EnumDisplaySettings
>
> Modified:
> trunk/reactos/win32ss/user/ntuser/display.c
>
> Modified: trunk/reactos/win32ss/user/ntuser/display.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/displa…
> ==============================================================================
> --- trunk/reactos/win32ss/user/ntuser/display.c [iso-8859-1] (original)
> +++ trunk/reactos/win32ss/user/ntuser/display.c [iso-8859-1] Sun Sep 11 16:13:46 2016
> @@ -443,7 +443,7 @@
> {
> /* No device found */
> ERR("No PDEV found!\n");
> - return STATUS_UNSUCCESSFUL;
> + return STATUS_INVALID_PARAMETER_1;
> }
>
> *ppdm = ppdev->pdmwDev;
> @@ -474,7 +474,7 @@
> {
> /* No device found */
> ERR("No device found!\n");
> - return STATUS_UNSUCCESSFUL;
> + return STATUS_INVALID_PARAMETER_1;
> }
>
> iFoundMode = 0;
> @@ -571,13 +571,18 @@
>
> _SEH2_TRY
> {
> - ProbeForWrite(lpDevMode, sizeof(DEVMODEW), 1);
> + ProbeForRead(lpDevMode, sizeof(DEVMODEW), 1);
> +
> + cbSize = lpDevMode->dmSize;
> + cbExtra = lpDevMode->dmDriverExtra;
> +
> + ProbeForWrite(lpDevMode, cbSize + cbExtra, 1);
> }
> _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER)
> {
> _SEH2_YIELD(return _SEH2_GetExceptionCode());
> }
> - _SEH2_END
> + _SEH2_END;
>
> if (lpDevMode->dmSize != sizeof(DEVMODEW))
> {
> @@ -586,31 +591,30 @@
>
> if (pustrDevice)
> {
> - if (pustrDevice->Buffer == NULL || pustrDevice->Length == 0)
> - {
> - Status = STATUS_INVALID_PARAMETER_1;
> - }
> -
> /* Initialize destination string */
> RtlInitEmptyUnicodeString(&ustrDevice, awcDevice, sizeof(awcDevice));
>
> _SEH2_TRY
> {
> /* Probe the UNICODE_STRING and the buffer */
> - ProbeForRead(pustrDevice, sizeof(UNICODE_STRING), 1);
> - ProbeForRead(pustrDevice->Buffer, pustrDevice->Length, 1);
> + ProbeForReadUnicodeString(pustrDevice);
> +
> + if (!pustrDevice->Length || !pustrDevice->Buffer)
> + ExRaiseStatus(STATUS_NO_MEMORY);
> +
> + ProbeForRead(pustrDevice->Buffer, pustrDevice->Length, sizeof(UCHAR));
>
> /* Copy the string */
> RtlCopyUnicodeString(&ustrDevice, pustrDevice);
> }
> _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER)
> {
> - _SEH2_YIELD(return _SEH2_GetExceptionCode());
> - }
> - _SEH2_END
> + _SEH2_YIELD(return STATUS_INVALID_PARAMETER_1);
> + }
> + _SEH2_END;
>
> pustrDevice = &ustrDevice;
> - }
> + }
>
> /* Acquire global USER lock */
> UserEnterShared();
> @@ -642,11 +646,6 @@
> /* Copy some information back */
> _SEH2_TRY
> {
> - ProbeForRead(lpDevMode, sizeof(DEVMODEW), 1);
> - cbSize = lpDevMode->dmSize;
> - cbExtra = lpDevMode->dmDriverExtra;
> -
> - ProbeForWrite(lpDevMode, cbSize + cbExtra, 1);
> /* Output what we got */
> RtlCopyMemory(lpDevMode, pdm, min(cbSize, pdm->dmSize));
>
> @@ -663,13 +662,6 @@
> Status = _SEH2_GetExceptionCode();
> }
> _SEH2_END;
> - }
> - else
> - {
> - if (Status == STATUS_UNSUCCESSFUL)
> - {
> - Status = STATUS_INVALID_PARAMETER_1;
> - }
> }
>
> return Status;
>
>