This patch, as it, is really dangerous. MS allows null pointer in its
Read/Write routines, but they are wrapped inside a SEH block, to prevent
nasty things to happen in case of a null pointer dereference.
Here we don't, meaning that a null pointer here will cause major damages.
Furthermore, your commit regressed ntdll:file:
https://reactos.org/sites/all/modules/reactos/testman/compare.php?ids=40042…
Regards,
On 08/07/2015 05:30 AM, aandrejevic(a)svn.reactos.org wrote:
> Author: aandrejevic
> Date: Fri Aug 7 03:30:05 2015
> New Revision: 68607
>
> URL: http://svn.reactos.org/svn/reactos?rev=68607&view=rev
> Log:
> [FASTFAT]
> Irp->UserBuffer being NULL doesn't indicate any error. It could be that the
> caller really wants the result stored at address NULL (which can be valid,
> and is valid by default for programs like NTVDM).
>
>
> Modified:
> trunk/reactos/drivers/filesystems/fastfat/rw.c
>
> Modified: trunk/reactos/drivers/filesystems/fastfat/rw.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfa…
> ==============================================================================
> --- trunk/reactos/drivers/filesystems/fastfat/rw.c [iso-8859-1] (original)
> +++ trunk/reactos/drivers/filesystems/fastfat/rw.c [iso-8859-1] Fri Aug 7 03:30:05 2015
> @@ -656,7 +656,7 @@
> }
>
> Buffer = VfatGetUserBuffer(IrpContext->Irp, BooleanFlagOn(IrpContext->Irp->Flags, IRP_PAGING_IO));
> - if (!Buffer)
> + if (!Buffer && IrpContext->Irp->MdlAddress)
> {
> Status = STATUS_INVALID_USER_BUFFER;
> goto ByeBye;
> @@ -927,7 +927,7 @@
> OldFileSize = Fcb->RFCB.FileSize;
>
> Buffer = VfatGetUserBuffer(IrpContext->Irp, BooleanFlagOn(IrpContext->Irp->Flags, IRP_PAGING_IO));
> - if (!Buffer)
> + if (!Buffer && IrpContext->Irp->MdlAddress)
> {
> Status = STATUS_INVALID_USER_BUFFER;
> goto ByeBye;
>
>
--
Pierre Schweitzer <pierre(a)reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
Hello,
i dont know if this list is the correct place to post this,
I found this software some weeks ago, and i thought it would be interesting
to have it running in ReactOS.
But, according its website, support for Windows XP has been stopped. So
question is, what about asking author to reenable XP support via ReactOS? :)
http://sourceforge.net/projects/vcxsrv/
Dear core developers,
Is it possible to use Windows XP based WDM sound drivers with Reactos
0.4-CLT2015?
Is it possible to make something so specific WDM sound driver can be
incorporated to Live CD so it would work out of The box?
If there is issues with using various sound drivers, how complex would
bew for You to add support for general USB audio device.
Last plea.
Which dlls would had to be redesigned so NVDA screen reader would be used?
Oleacc.dll and other mSAA based libraries?
Thank You very much for Yours answers.
With kindness regards.
Janusz Chmiel
Hello. I am Jared Smudde aka. Pi_User5. I propose that we move most of the icons in trunk into a central folder in the media folder. Some icons will need to stay because they might be application specific. The folder can be called icons and it would be organized according to http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.h…. This way, we can eliminate duplicate icons thus making trunk slightly smaller. It will also make changing ReactOS to a different icon theme much easier. This idea was suggested by gigaherz and I would like to see it done. Thanks!
Jared
Hi
On my issue CORE-9641 <https://jira.reactos.org/browse/CORE-9641> Victor
Martinez made a comment saying that Eric Kohl is currently working on
partitions. If that is the case, what kind of changes are being worked on?
Since I created another issue related to that (CORE-9661
<https://jira.reactos.org/browse/CORE-9661>), if this is already worked
on, I don't want to look into it either, otherwise this would be what I
would fix next.
mfg,
Gerhard Gruber
On Wed, Jun 24, 2015 at 9:26 AM, <cfinck(a)svn.reactos.org> wrote:
> cbSize
Well, you may at least want to validate that your dwOffsets are within
cbSize?
Best regards,
Alex Ionescu
On 2015-06-29 20:26, ekohl(a)svn.reactos.org wrote:
> Modified: trunk/reactos/ntoskrnl/config/cmmapvw.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/config/cmmapvw.c?…
> ==============================================================================
> --- trunk/reactos/ntoskrnl/config/cmmapvw.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/config/cmmapvw.c [iso-8859-1] Mon Jun 29 18:26:56 2015
> @@ -29,3 +29,54 @@
> Hive->PinnedViews = 0;
> Hive->UseCount = 0;
> }
> +
> +VOID
> +NTAPI
> +CmpDestroyHiveViewList(IN PCMHIVE Hive)
> +{
> + PCM_VIEW_OF_FILE CmView;
> + PLIST_ENTRY EntryList;
> +
> + /* Do NOT destroy the views of read-only hives */
> + ASSERT(Hive->Hive.ReadOnly == FALSE);
> +
> + /* Free all the views inside the Pinned View List */
> + EntryList = RemoveHeadList(&Hive->PinViewListHead);
> + while (EntryList != &Hive->PinViewListHead)
In case you haven't found it yourself yet maybe I can speed things up in
identifying the test failures here:
I made RemoveHeadList on an empty list cause a security check failure
a while back because when done unintentionally it can indicate a bug in
the code, while OTOH it's super easy to avoid.
So I'm guessing this is probably the cause, and should use a
while (!IsListEmpty()) RemoveHeadList(); or similar pattern.
If you have strong feelings against this check (which MS's headers
don't do), let me know.
> + {
> + CmView = CONTAINING_RECORD(EntryList, CM_VIEW_OF_FILE, PinViewList);
> +
> + /* FIXME: Unmap the view if it is mapped */
> +
> + ExFreePool(CmView);
> +
> + Hive->PinnedViews--;
> +
> + EntryList = RemoveHeadList(&Hive->PinViewListHead);
> + }
> +
> + /* The Pinned View List should be empty */
> + ASSERT(IsListEmpty(&Hive->PinViewListHead) == TRUE);
> + ASSERT(Hive->PinnedViews == 0);
> +
> + /* Now, free all the views inside the LRU View List */
> + EntryList = RemoveHeadList(&Hive->LRUViewListHead);
> + while (EntryList != &Hive->LRUViewListHead)
> + {
> + CmView = CONTAINING_RECORD(EntryList, CM_VIEW_OF_FILE, LRUViewList);
> +
> + /* FIXME: Unmap the view if it is mapped */
> +
> + ExFreePool(CmView);
> +
> + Hive->MappedViews--;
> +
> + EntryList = RemoveHeadList(&Hive->LRUViewListHead);
> + }
Hello,
Let me invite you to the monthly status meeting taking place 25th of
June, 19:00 UTC, as always.
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.
Please send agenda proposals to me before the meeting.
One point for agenda would be discussion of our upcoming Hackfest in
Aachen, which is going to be awesome (the Hackfest, and hopefully the
discussion too ;))
Regards,
Aleksey Bragin
Join us for the very first ReactOS Hackfest from Friday, 7th August to
Wednesday, 13th August 2015, in the German city of Aachen. Discover
Germany's most-Western city in the direct neighborhood of Belgium and
the Netherlands. Within the historical city center, Aachen offers a
scientific environment and a high density of pubs. Let's catch this
atmosphere to code the week away and achieve great results as a team!
===> It is now time to plan your trip! <===
Flights and Accommodation won't get cheaper.
You find all details on this Wiki page:
https://reactos.org/wiki/ReactOS_Hackfest_2015
Don't forget to add your ideas and travelling details to this page:
https://reactos.org/wiki/ReactOS_Hackfest_2015/Lists
If you have any further questions, just drop me a line by E-Mail or call
me on the mobile phone number I sent to ros-priv.
Looking forward to meet you!
With best regards,
Colin Finck
Hi all,
After some attempts yesterday and today, the VMware Testbots are finally
fixed. Due to a misconfiguration, they were unfortunately testing the
same revision 65663 all the time.
I'm going to delete the duplicate testings for r65663 once I have some
time. Unless somebody is interested in the most detailed information
about randomly failing Wine tests ;)
Cheers,
Colin
Am 14.06.2015 um 18:00 schrieb pschweitzer(a)svn.reactos.org:
> Author: pschweitzer
> Date: Sun Jun 14 16:00:27 2015
> New Revision: 68137
>
>
> - Proc = (1ULL << Processor) >> 0x20;
> + Proc = (1ULL << Processor) >> MAXIMUM_PROCESSORS;
This is effectively the same as "Proc = (Processor ==
MAXIMUM_PROCESSORS);" which is always 0.
Timo
This looks great, but I hope you're aware of the limitations of DllMain.
If the test gets more complex, it might be better to do a separate
CreateRemoteThread call on an exported function after the dll has been
loaded.
Although I guess as long as things work, this is fine ;)
(maybe this is related to the SEH issue you mention in the next commit,
not sure)
On 2015-06-08 19:15, cfinck(a)svn.reactos.org wrote:
> [LOCALSPL_APITEST]
> Write an API-Test for localspl.dll. As the original localspl.dll from Windows Server 2003 relies on proper initialization inside spoolsv.exe, we cannot test it standalone as usual.
> +// Running the tests from the injected DLL and redirecting their output to the pipe.
> +BOOL WINAPI
> +DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
> +{
> + char szTestName[150];
> + DWORD cbRead;
> + FILE* fpStdout;
> + HANDLE hCommandPipe;
> + int iOldStdout;
> +
> + // We only want to run our test once when the DLL is injected to the process.
> + if (fdwReason != DLL_PROCESS_ATTACH)
> + return TRUE;
Quick note: Files that get embedded into binaries or put on the CD
should not use native EOL, but CRLF.
This applies e.g. to inf files, as well as text files that are
resources (which I believe is what these inis are?).
The idea is that in a perfect world the CD image build by a Unix
builder is identical to the one built by a Windows builder.
On 2015-06-06 20:27, akhaldi(a)svn.reactos.org wrote:
> [LAUTUS] Make the text files UTF-8 without BOM, and convert them to UTF-16 LE at compile time. Remove the now unneeded application/octet-stream type property and set native EOL one. CORE-9770
> Propchange: trunk/reactos/media/themes/lautus.msstyles/textfiles/NormalNormal.INI
> ------------------------------------------------------------------------------
> svn:eol-style = native
>
Hi,
The names for our builders / testers don't seem to be optimal to me. And
since they seem to be sorted in the waterfall display alphabetically
now, I suggest renaming them in the following way:
Build_GCCLin_Debug
Build_GCCLin_Release
Build_GCCWin
Build_MSVC_x64
Build_MSVC_x86
Test_KVM
Test_VBox
Test_VMW
Test_VMW_Hybrid
Test_WHS
This way it is much more consistent, limited to actually useful
information and would sort them nicely with builders left and testers right.
Regards,
Timo
Dear all,
We have proceed to a complete reimplementation of authentication server
which serves Jira & Fisheye. The purpose is to rely on something
maintained and stable.
It should not change anything for you on daily usage. 58 accounts have
been left out and will not be able to connect to Jira due to
incompatible account name (using invalid chars). If you happen to be
incapable of log in, please contact me so that I can rename your account.
New accounts cannot be created with such invalid chars any longer.
As a side note, this was a major blocker for our upgrade to Jira 6. If
we do not spot anything wrong with our new authentication mechanism,
then, then the upgrade to Jira 6 should happen in the next days.
With my best regards,
--
Pierre Schweitzer <pierre(a)reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
Hi all,
In order to verify the exact behaviour of localspl.dll on Windows Server
2003, I'm trying to write an API-Test for it. This is no problem for
winspool.drv or even the Print Processor functions of localspl.dll, but
its Print Provider functions pose some serious problems:
* You get a table of function pointers by calling InitializePrintProvidor.
* Instead of just handing over the pointers, this function first calls
many undocumented ones from spoolss.dll, including CacheAddName,
CacheCreateAndAddNode, GetServerPolicy, SplInitializeWinSpoolDrv,
SplIsUpgrade.
* Out of these undocumented functions, GetServerPolicy is the most
problematic one, because it itself relies on a function pointer given by
spoolsv.exe to spoolss.dll in an initialization function. My API-Test is
not spoolsv.exe, so I don't initialize spoolss.dll the same way. Thus,
GetServerPolicy will fail and InitializePrintProvidor as well.
* For now, I worked around this problem by stubbing these functions in
my spoolss.dll. I.e., GetServerPolicy just returns TRUE there and I get
further.
* On top of this, InitializePrintProvidor also makes use of
RevertToPrinterSelf and ImpersonatePrinterClient. To let these functions
succeed, the current thread actually needs to impersonate a user. For
now, I worked around this problem by doing:
OpenProcessToken(GetCurrentProcess(), TOKEN_DUPLICATE, &hToken);
DuplicateToken(hToken, SecurityImpersonation, &hDup);
ImpersonateLoggedOnUser(hDup);
before calling InitializePrintProvidor.
* Finally, this lets InitializePrintProvidor succeed and it gave me the
table of function pointers.
Unfortunately, even simple query functions like fpEnumPrinters do a
RevertToPrinterSelf and then expect to be in the SYSTEM context of
spoolsv.exe. When my API-Test was just run in a usual Administrator user
context under Windows Server 2003, fpEnumPrinters didn't succeed.
For now, I worked around this problem by running my test program as a
service in the SYSTEM context.
With all these problems presented, can you think of any way how I can
now write a reliable API-Test for localspl.dll that could be run
regularly under Windows Server 2003 and ReactOS?
One idea would be to load the system spoolss.dll and then rewire the
GetServerPolicy import to a function that just returns TRUE all the time.
Still then, I have the problem that my API-Test would need to be run in
the SYSTEM security context.
Creative ideas are welcome! :)
Cheers,
Colin
Hey guys,
as some of you might have seen already we now have two copies of the more and more increasing RAPPS DB in trunk. This is:
a) Absolutely unnecessary and does only result in one thing, two differing DBs
b) Shows even more that it’s not useful to have it in trunk at all.
Because of this I start a vote now to get your opinion in completely removing the RAPPS DB from trunk into a subtree like done for many other things, too.
What do you think?
Greetings
Daniel Reimer
Gesendet von Windows Mail