Ros-dev

ros-dev@reactos.org

5790 discussions

Re: [ros-dev] [ros-diffs] 07/18: [WIN32K:NTUSER] Get rid of the cached window station Name member, and instead just use the name stored in the NT Object's header. CORE-11933 and PR #621.
by Timo Kreuzer 10 Dec '18

10 Dec '18

Why did you remove an abstraction and create additional dependencies on internal implementation details? Win32k is not supposed to directly access internal kernel structures! The headers and macros shouldn't even be in NDK. Please revert or fix this. And while you are at it, put an "#ifdef _NTOSKRNL_" around the stuff in NDK to prevent people from using it. Thanks, Timo Am 19.08.2018 um 22:16 schrieb Hermès Bélusca-Maïto: > https://git.reactos.org/?p=reactos.git;a=commitdiff;h=43e2ab208a2d3d50b12b4… > > commit 43e2ab208a2d3d50b12b4689347f57ca83568dd9 > Author: Hermès Bélusca-Maïto <hermes.belusca-maito(a)reactos.org> > AuthorDate: Sun Jun 17 19:40:32 2018 +0200 > Commit: Hermès Bélusca-Maïto <hermes.belusca-maito(a)reactos.org> > CommitDate: Sun Aug 19 22:18:32 2018 +0200 > > [WIN32K:NTUSER] Get rid of the cached window station Name member, and instead just use the name stored in the NT Object's header. > CORE-11933 and PR #621. > > - Remove the related hack-FIXMEs; > - Adjust NtUserGetObjectInformation() in accordance. > - Retrieve the window-station/desktop object type string in NtUserGetObjectInformation() > also from the NT Object's header. > > Also simplify the UOI_FLAGS case of NtUserGetObjectInformation() by reading > the handle inheritance information directly from the OBJECT_HANDLE_INFORMATION > structure returned by ObReferenceObjectByHandle(). > --- > win32ss/user/ntuser/sysparams.c | 3 +- > win32ss/user/ntuser/winsta.c | 106 +++++++++++++++++++--------------------- > win32ss/user/ntuser/winsta.h | 1 - > 3 files changed, 51 insertions(+), 59 deletions(-) > > diff --git a/win32ss/user/ntuser/sysparams.c b/win32ss/user/ntuser/sysparams.c > index 7eedc028de..d0badba00e 100644 > --- a/win32ss/user/ntuser/sysparams.c > +++ b/win32ss/user/ntuser/sysparams.c > @@ -33,7 +33,8 @@ BOOL g_PaintDesktopVersion = FALSE; > } \ > else \ > { \ > - ERR("NtUserSystemParametersInfo requires interactive window station (current is %wZ)\n", &GetW32ProcessInfo()->prpwinsta->Name); \ > + ERR("NtUserSystemParametersInfo requires interactive window station (current is %wZ)\n", \ > + &(OBJECT_HEADER_TO_NAME_INFO(OBJECT_TO_OBJECT_HEADER(GetW32ProcessInfo()->prpwinsta))->Name)); \ > } \ > EngSetLastError(err); \ > return 0; \ > diff --git a/win32ss/user/ntuser/winsta.c b/win32ss/user/ntuser/winsta.c > index f373b1cedf..ba1b1eb57d 100644 > --- a/win32ss/user/ntuser/winsta.c > +++ b/win32ss/user/ntuser/winsta.c > @@ -114,8 +114,6 @@ IntWinStaObjectDelete( > > RtlDestroyAtomTable(WinSta->AtomTable); > > - RtlFreeUnicodeString(&WinSta->Name); > - > return STATUS_SUCCESS; > } > > @@ -449,8 +447,6 @@ IntCreateWindowStation( > RtlZeroMemory(WindowStationObject, sizeof(WINSTATION_OBJECT)); > > InitializeListHead(&WindowStationObject->DesktopListHead); > - WindowStationObject->Name = *ObjectAttributes->ObjectName; > - ObjectAttributes->ObjectName = NULL; // FIXME! (see NtUserCreateWindowStation()) > WindowStationObject->dwSessionId = NtCurrentPeb()->SessionId; > Status = RtlCreateAtomTable(37, &WindowStationObject->AtomTable); > if (!NT_SUCCESS(Status)) > @@ -491,7 +487,7 @@ IntCreateWindowStation( > } > > TRACE("IntCreateWindowStation created object 0x%p with name %wZ handle 0x%p\n", > - WindowStationObject, &WindowStationObject->Name, WindowStation); > + WindowStationObject, ObjectAttributes->ObjectName, WindowStation); > > *phWinSta = WindowStation; > return STATUS_SUCCESS; > @@ -582,23 +578,7 @@ NtUserCreateWindowStation( > return NULL; > } > > - WindowStationName.Length = wcslen(ServiceWinStaName) * sizeof(WCHAR); > - WindowStationName.MaximumLength = > - WindowStationName.Length + sizeof(UNICODE_NULL); > - WindowStationName.Buffer = > - ExAllocatePoolWithTag(PagedPool, > - WindowStationName.MaximumLength, > - TAG_STRING); > - if (!WindowStationName.Buffer) > - { > - Status = STATUS_NO_MEMORY; > - ERR("Impossible to build a valid window station name, Status 0x%08lx\n", Status); > - SetLastNtError(Status); > - return NULL; > - } > - RtlStringCbCopyW(WindowStationName.Buffer, > - WindowStationName.MaximumLength, > - ServiceWinStaName); > + RtlInitUnicodeString(&WindowStationName, ServiceWinStaName); > LocalObjectAttributes.ObjectName = &WindowStationName; > AccessMode = KernelMode; > } > @@ -615,12 +595,7 @@ NtUserCreateWindowStation( > Unknown5, > Unknown6); > > - // FIXME! Because in some situations we store the allocated window station name > - // inside the window station, we must not free it now! We know this fact when > - // IntCreateWindowStation() sets LocalObjectAttributes.ObjectName to NULL. > - // This hack must be removed once we just use the stored Ob name instead > - // (in which case we will always free the allocated name here). > - if (LocalObjectAttributes.ObjectName) > + if ((AccessMode == UserMode) && LocalObjectAttributes.ObjectName) > ExFreePoolWithTag(LocalObjectAttributes.ObjectName->Buffer, TAG_STRING); > > if (NT_SUCCESS(Status)) > @@ -802,7 +777,11 @@ NtUserGetObjectInformation( > NTSTATUS Status; > PWINSTATION_OBJECT WinStaObject = NULL; > PDESKTOP DesktopObject = NULL; > + POBJECT_HEADER ObjectHeader; > + POBJECT_HEADER_NAME_INFO NameInfo; > + OBJECT_HANDLE_INFORMATION HandleInfo; > USEROBJECTFLAGS ObjectFlags; > + PUNICODE_STRING pStrNameU = NULL; > PVOID pvData = NULL; > SIZE_T nDataSize = 0; > > @@ -820,13 +799,13 @@ NtUserGetObjectInformation( > _SEH2_END; > > /* Try window station */ > - TRACE("Trying to open window station %p\n", hObject); > + TRACE("Trying to open window station 0x%p\n", hObject); > Status = ObReferenceObjectByHandle(hObject, > 0, > ExWindowStationObjectType, > UserMode, > (PVOID*)&WinStaObject, > - NULL); > + &HandleInfo); > > if (Status == STATUS_OBJECT_TYPE_MISMATCH) > { > @@ -852,23 +831,8 @@ NtUserGetObjectInformation( > { > case UOI_FLAGS: > { > - OBJECT_HANDLE_ATTRIBUTE_INFORMATION HandleInfo; > - ULONG BytesWritten; > - > ObjectFlags.fReserved = FALSE; > - > - /* Check whether this handle is inheritable */ > - Status = ZwQueryObject(hObject, > - ObjectHandleFlagInformation, > - &HandleInfo, > - sizeof(OBJECT_HANDLE_ATTRIBUTE_INFORMATION), > - &BytesWritten); > - if (!NT_SUCCESS(Status)) > - { > - ERR("ZwQueryObject failed, Status 0x%08lx\n", Status); > - break; > - } > - ObjectFlags.fInherit = HandleInfo.Inherit; > + ObjectFlags.fInherit = !!(HandleInfo.HandleAttributes & OBJ_INHERIT); > > ObjectFlags.dwFlags = 0; > if (WinStaObject != NULL) > @@ -893,11 +857,24 @@ NtUserGetObjectInformation( > > case UOI_NAME: > { > - // FIXME: Use either ObQueryNameString() or read directly that name inside the Object section! > if (WinStaObject != NULL) > { > - pvData = WinStaObject->Name.Buffer; > - nDataSize = WinStaObject->Name.Length + sizeof(WCHAR); > + ObjectHeader = OBJECT_TO_OBJECT_HEADER(WinStaObject); > + NameInfo = OBJECT_HEADER_TO_NAME_INFO(ObjectHeader); > + > + if (NameInfo && (NameInfo->Name.Length > 0)) > + { > + /* Named window station */ > + pStrNameU = &NameInfo->Name; > + nDataSize = pStrNameU->Length + sizeof(UNICODE_NULL); > + } > + else > + { > + /* Unnamed window station (should never happen!) */ > + ASSERT(FALSE); > + pStrNameU = NULL; > + nDataSize = sizeof(UNICODE_NULL); > + } > Status = STATUS_SUCCESS; > } > else if (DesktopObject != NULL) > @@ -917,14 +894,16 @@ NtUserGetObjectInformation( > { > if (WinStaObject != NULL) > { > - pvData = L"WindowStation"; > - nDataSize = sizeof(L"WindowStation"); > + ObjectHeader = OBJECT_TO_OBJECT_HEADER(WinStaObject); > + pStrNameU = &ObjectHeader->Type->Name; > + nDataSize = pStrNameU->Length + sizeof(UNICODE_NULL); > Status = STATUS_SUCCESS; > } > else if (DesktopObject != NULL) > { > - pvData = L"Desktop"; > - nDataSize = sizeof(L"Desktop"); > + ObjectHeader = OBJECT_TO_OBJECT_HEADER(DesktopObject); > + pStrNameU = &ObjectHeader->Type->Name; > + nDataSize = pStrNameU->Length + sizeof(UNICODE_NULL); > Status = STATUS_SUCCESS; > } > else > @@ -954,10 +933,25 @@ Exit: > *nLengthNeeded = nDataSize; > > /* Try to copy data to caller */ > - if (Status == STATUS_SUCCESS) > + if (Status == STATUS_SUCCESS && (nDataSize > 0)) > { > TRACE("Trying to copy data to caller (len = %lu, len needed = %lu)\n", nLength, nDataSize); > - RtlCopyMemory(pvInformation, pvData, nDataSize); > + if (pvData) > + { > + /* Copy the data */ > + RtlCopyMemory(pvInformation, pvData, nDataSize); > + } > + else if (pStrNameU) > + { > + /* Copy and NULL-terminate the string */ > + RtlCopyMemory(pvInformation, pStrNameU->Buffer, pStrNameU->Length); > + ((PWCHAR)pvInformation)[pStrNameU->Length / sizeof(WCHAR)] = UNICODE_NULL; > + } > + else > + { > + /* Zero the memory */ > + RtlZeroMemory(pvInformation, nDataSize); > + } > } > } > _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > @@ -1026,8 +1020,6 @@ NtUserSetObjectInformation( > } > > > - > - > HWINSTA FASTCALL > UserGetProcessWindowStation(VOID) > { > diff --git a/win32ss/user/ntuser/winsta.h b/win32ss/user/ntuser/winsta.h > index 085f3bcb26..19b1479ec0 100644 > --- a/win32ss/user/ntuser/winsta.h > +++ b/win32ss/user/ntuser/winsta.h > @@ -15,7 +15,6 @@ typedef struct _WINSTATION_OBJECT > { > DWORD dwSessionId; > > - UNICODE_STRING Name; > LIST_ENTRY DesktopListHead; > PRTL_ATOM_TABLE AtomTable; > HANDLE ShellWindow; > >

1 0

USB meta bug
by Javier Agustìn Fernàndez Arroyo 09 Dec '18

09 Dec '18

hello all, There are lots of USB related reports, and i´m about creating a master one, which blocks all of those... what do you think?

2 1

Doxygen migrated - now with a reasonable search feature!
by Colin Finck 09 Dec '18

09 Dec '18

Hi all! Good news! I've just migrated the last of our existing services, Doxygen, to a new server that is a lot faster and more reliable. But I also had a look at the often criticized search feature and enabled the alternative EXTERNAL_SEARCH in the Doxyfile and on the server. This doubled the runtime for Doxygen due to the additional indexing, but the result is well worth the effort! A simple search for a universal function like "Sleep" now instantly yields all results, but with the definition in "winbase.h" and the declaration in "kernel32/client/synch.c" at the very top! Results are also a lot more readable and distributed over multiple pages. Just try it yourself: https://doxygen.reactos.org/search.html?query=Sleep Hope you'll like it as much as I do! :) We can now start tweaking the extra settings, e.g. whether we need "Referenced by" and other information. ReactOS is already known to many due to our Doxygen popping up whenever they google a Windows API. This step should improve the usefulness of our documentation even further and turn the ReactOS codebase into *the* public reference about Windows internals again! I hope it also motivates you to take care of Doxygen-compatible comments during your coding :) Cheers, Colin

2 1

Re: [ros-dev] iso.reactos.org migrated to new server
by hermes.belusca＠sfr.fr 05 Dec '18

05 Dec '18

‌Hi, In case this happens to be indeed a problem, the additional stuff to add to the build scripts would be to upload these bootcdregtest ISOs to iso.reactos.org, while using now the local copy on the build machine network. Best, Hermes <div class="gl_quote" style="margin-top: 20px; padding-top: 5px;">De : "Colin Finck" A : "'ReactOS Development List'" Envoyé: mercredi 5 décembre 2018 20:01 Objet : [ros-dev] iso.reactos.org migrated to new server   <div class="gl_quoted">Hi all! iso.reactos.org, the file server used by our build machines and the source for https://reactos.org/getbuilds, has been migrated to new hardware at a different location today. You should experience better transfer rates due to the increased bandwidth, and a higher availability. The new hardware also offers more disk space and redundancy to keep our precious ISOs absolutely safe :) Unfortunately, the new iso.reactos.org is no longer right next to the build machines. This has several consequences: If I had left the build scripts as-is, the build machines would have uploaded the bootcdregtest ISOs to iso.reactos.org, just to download them multiple times for each Testbot a minute later. This would be an excessive waste of ISP bandwidth and would have delayed the entire testing process. Therefore, I changed the build scripts to keep the bootcdregtest ISOs within the local build machine network. However, the downside is that bootcdregtest ISOs are no longer available via iso.reactos.org. Please let me know if this is a problem for you and needs a solution. In the past, bootcdregtest ISOs were only available for a week and not accessible via GetBuilds either, so I have no idea how popular they are. Cheers, Colin _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://reactos.org/mailman/listinfo/ros-dev</div> <div class="gl_quoted"> </div> </div>

1 0

"[shell32] Shell dialog issues" .- CORE-10481
by Javier Agustìn Fernàndez Arroyo 02 Dec '18

02 Dec '18

Are you sure its better to follow Win behavior on this? I think its a enhancement, specially if there are many open windows at a given time.... it saves time!

4 4

ReactOS 0.5 Planning
by Colin Finck 30 Nov '18

30 Nov '18

Hi all! Planning the ReactOS 0.5 release and establishing a new roadmap was one of the points on the agenda of yesterday's meeting. This is still an ongoing process. Please make up your minds about what a ReactOS 0.5 release must offer in your opinion and write it down to https://reactos.org/wiki/0.5.0 To get a realistic roadmap, it is important that we define a responsible person for each task. It should be the person having the most in-depth knowledge about the status of the affected ReactOS components. Don't worry, we won't put any pressure on you to complete the task soon. But we need someone who can give a detailed report about the current status. If nobody can be the responsible person for a certain task, having it for 0.5 is not realistic and it eventually needs to be removed from the roadmap. But that's for later! Let's first add all points we consider important until the end of the year. If you can already add yourself as the responsible person, even better! :) Cheers, Colin

5 4

Google Summer of Code 2019
by Colin Finck 29 Nov '18

29 Nov '18

Hi all! While there is still some time until the February 6, 2019 application deadline for projects, we should already begin planning our GSoC participation now! As today's meeting already has a long agenda, I delibereately didn't add GSoC to it. But I've already created https://reactos.org/wiki/Google_Summer_of_Code_2019 and https://reactos.org/wiki/Google_Summer_of_Code_2019_Ideas Please decide whether you want to be a GSoC org admin or mentor and add your ideas to the list or remove deprecated ones. My experience from the Mentor Summit tells me that proper planning and advertising can make a huge difference for our 2019 participation and will certainly get us more students :) Cheers, Colin

4 3

Re: [ros-dev] Status Meeting (November 2018)
by Can Tasan 29 Nov '18

29 Nov '18

While there's a discussion of 0.5 release plan, here are some candidate topics: * MM/CC work, to reduce BSoDs and enable further development * PNP work. vgal has done some work on both HAL and PNP to fix device issues. Also many Windows Server 2003 drivers are usable now. Progressing this and finally integrating into ReactOS is essential at some point. * Driver issues * System corruption after hard resets or BSoDs * Further Win32 work to get many programs usable (I can extensively test Word 2003 if there's help!) * Getting rid of old fastfat (and progressing NTFS further?) * Robust networking (adding WPA support, fixing bugs...) * Installer support for old programs and WoW16 (there's two resources: Win3mu is now open-source and otya128's winevdm) * Further DirectX work (or just syncs from Wine) and some video work to get more games playable? * Sound? * And other things you add or I forgot. Best regards, Can

1 0

Status Meeting (November 2018)
by Colin Finck 29 Nov '18

29 Nov '18

Hi all! Let me invite you to the November 2018 meeting, taking place next Thursday, November 29, 2018 at 19:00 UTC. Invited members will again receive their credentials shortly before the meeting. This will be the first meeting since August and I hope we get some more topics than just the obligatory Status Reports. Please send your proposals by replying to this mail. Best regards, Colin

5 9

Re: [ros-dev] Status Meeting (November 2018)
by Serge Gautherie 29 Nov '18

29 Nov '18

On 29/11/2018 00:35, Thomas Mueller wrote: > My hard drives are all partitioned GPT, and lack of support for USB and GPT has kept me away from doing anything regarding ReactOS. Where would I put it? Meantime solution: in a virtual machine. --

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev