Ros-dev

ros-dev@reactos.org

5790 discussions

Dynamic libxml2/zlib
by Thomas Faber 03 Feb '18

03 Feb '18

Hey Amine, seeing https://jira.reactos.org/browse/CORE-14288 just prompted me to look into static vs dynamic 3rd party libraries, zlib and libxml2 in particular. We use zlib in a bunch of modules these days, and libxml2 is large and used in two, so I'm thinking we should make them dynamic. I just did the experiment for libxml2 and it resulted in at least 0.5MB binary size reduction and 2MB build folder size reduction, so clearly seems worth it.[1] I'll do the test for zlib as well to make sure that's also an improvement. However I was thinking there might be a reason why we build those statically right now. Do you (or anyone else) recall anything that makes switching to dynamic a bad idea? Thanks! -Thomas [1] Raw results: Static libxml2 (MSVC debug with RTC): msxml3.dll - 1887 KB libxslt.dll - 1142 KB libxml2.lib - 4953 KB (build dir only) Dynamic libxml2 (MSVC debug with RTC): msxml3.dll - 799 KB libxslt.dll - 259 KB libxml2.dll - 1592 KB libxml2.lib - 371 KB (build dir only) Static libxml2 (GCC debug with -O1): msxml3.dll - 3856 KB libxslt.dll - 2776 KB liblibxml2.a - 48 KB (build dir only) Dynamic libxml2 (GCC debug with -O1): msxml3.dll - 1505 KB libxslt.dll - 429 KB libxml2.dll - 2553 KB

2 1

Fwd: Re: [ros-diffs] 01/01: [WTSAPI32] Sync with Wine 3.0. CORE-14225
by Erkin Alp Güney 22 Jan '18

22 Jan '18

Aka project Doors! > In the long term, we could leverage the power of Git and fork the WINE > repository on GitHub. We could then apply Wine-Staging patches and our > own changes to that repository. Syncing with upstream would now be > possible by merging commits instead of overwriting files. In the end, > DLLs from that repository could be blindly imported into the ReactOS > repo again. No more maintaining of "wininet_ros.diff" and the like > > I hope we can have a solution before branching for 0.4.8. Otherwise, > I suspect that we will lose many features of 0.4.7 and the recent > history. For instance, DXTn support just got enabled in ReactOS, but it > has always been based on Wine-Staging code. > > > As James used to say: WINE Is Not Enough!

1 0

Re: [ros-dev] [ros-diffs] 01/01: [WTSAPI32] Sync with Wine 3.0. CORE-14225
by Ged Murphy 22 Jan '18

22 Jan '18

Is this really a sync up? It takes implemented functions are returns them to stubs -----Original Message----- From: Ros-diffs [mailto:ros-diffs-bounces@reactos.org] On Behalf Of Amine Khaldi Sent: 21 January 2018 21:02 To: ros-diffs(a)reactos.org Subject: [ros-diffs] 01/01: [WTSAPI32] Sync with Wine 3.0. CORE-14225 https://git.reactos.org/?p=reactos.git;a=commitdiff;h=90f14ccef3d9d344b7021… commit 90f14ccef3d9d344b7021407b4c59a7234a19614 Author: Amine Khaldi <amine.khaldi(a)reactos.org> AuthorDate: Sun Jan 21 22:01:34 2018 +0100 Commit: Amine Khaldi <amine.khaldi(a)reactos.org> CommitDate: Sun Jan 21 22:01:34 2018 +0100 [WTSAPI32] Sync with Wine 3.0. CORE-14225 --- dll/win32/wtsapi32/wtsapi32.c | 95 ++++--------------------------------------- media/doc/README.WINE | 2 +- 2 files changed, 10 insertions(+), 87 deletions(-) diff --git a/dll/win32/wtsapi32/wtsapi32.c b/dll/win32/wtsapi32/wtsapi32.c index a7f4c873d9..92a7396f54 100644 --- a/dll/win32/wtsapi32/wtsapi32.c +++ b/dll/win32/wtsapi32/wtsapi32.c @@ -28,9 +28,6 @@ WINE_DEFAULT_DEBUG_CHANNEL(wtsapi); -/* FIXME: Inspect */ -#define GetCurrentProcessToken() ((HANDLE)~(ULONG_PTR)3) - /************************************************************ * WTSCloseServer (WTSAPI32.@) @@ -99,13 +96,8 @@ BOOL WINAPI WTSEnumerateProcessesA(HANDLE hServer, DWORD Reserved, DWORD Version BOOL WINAPI WTSEnumerateProcessesW(HANDLE hServer, DWORD Reserved, DWORD Version, PWTS_PROCESS_INFOW* ppProcessInfo, DWORD* pCount) { - WTS_PROCESS_INFOW *processInfo; - SYSTEM_PROCESS_INFORMATION *spi; - ULONG size = 0x4000; - void *buf = NULL; - NTSTATUS status; - DWORD count; - WCHAR *name; + FIXME("Stub %p 0x%08x 0x%08x %p %p\n", hServer, Reserved, Version, + ppProcessInfo, pCount); if (!ppProcessInfo || !pCount || Reserved != 0 || Version != 1) { @@ -113,71 +105,9 @@ BOOL WINAPI WTSEnumerateProcessesW(HANDLE hServer, DWORD Reserved, DWORD Version return FALSE; } - if (hServer != WTS_CURRENT_SERVER_HANDLE) - { - SetLastError(ERROR_CALL_NOT_IMPLEMENTED); - return FALSE; - } - - do - { - size *= 2; - HeapFree(GetProcessHeap(), 0, buf); - buf = HeapAlloc(GetProcessHeap(), 0, size); - if (!buf) - { - SetLastError(ERROR_OUTOFMEMORY); - return FALSE; - } - status = NtQuerySystemInformation(SystemProcessInformation, buf, size, NULL); - } - while (status == STATUS_INFO_LENGTH_MISMATCH); - - if (status != STATUS_SUCCESS) - { - HeapFree(GetProcessHeap(), 0, buf); - SetLastError(RtlNtStatusToDosError(status)); - return FALSE; - } - - spi = buf; - count = size = 0; - for (;;) - { - size += sizeof(WTS_PROCESS_INFOW) + spi->ProcessName.Length + sizeof(WCHAR); - count++; - if (spi->NextEntryOffset == 0) break; - spi = (SYSTEM_PROCESS_INFORMATION *)(((PCHAR)spi) + spi->NextEntryOffset); - } - - processInfo = HeapAlloc(GetProcessHeap(), 0, size); - if (!processInfo) - { - HeapFree(GetProcessHeap(), 0, buf); - SetLastError(ERROR_OUTOFMEMORY); - return FALSE; - } - name = (WCHAR *)&processInfo[count]; - - *ppProcessInfo = processInfo; - *pCount = count; - - spi = buf; - while (count--) - { - processInfo->SessionId = 0; - processInfo->ProcessId = HandleToUlong(spi->UniqueProcessId); - processInfo->pProcessName = name; - processInfo->pUserSid = NULL; - memcpy( name, spi->ProcessName.Buffer, spi->ProcessName.Length ); - name[ spi->ProcessName.Length/sizeof(WCHAR) ] = 0; - - processInfo++; - name += (spi->ProcessName.Length + sizeof(WCHAR))/sizeof(WCHAR); - spi = (SYSTEM_PROCESS_INFORMATION *)(((PCHAR)spi) + spi->NextEntryOffset); - } + *pCount = 0; + *ppProcessInfo = NULL; - HeapFree(GetProcessHeap(), 0, buf); return TRUE; } @@ -241,7 +171,9 @@ BOOL WINAPI WTSEnumerateSessionsW(HANDLE hServer, DWORD Reserved, DWORD Version, */ void WINAPI WTSFreeMemory(PVOID pMemory) { - HeapFree(GetProcessHeap(), 0, pMemory); + static int once; + + if (!once++) FIXME("Stub %p\n", pMemory); } /************************************************************ @@ -314,16 +246,7 @@ BOOL WINAPI WTSQuerySessionInformationW( BOOL WINAPI WTSQueryUserToken(ULONG session_id, PHANDLE token) { FIXME("%u %p\n", session_id, token); - - if (!token) - { - SetLastError(ERROR_INVALID_PARAMETER); - return FALSE; - } - - return DuplicateHandle(GetCurrentProcess(), GetCurrentProcessToken(), - GetCurrentProcess(), token, - 0, FALSE, DUPLICATE_SAME_ACCESS); + return FALSE; } /************************************************************ @@ -357,7 +280,7 @@ BOOL WINAPI WTSRegisterSessionNotification(HWND hWnd, DWORD dwFlags) } /************************************************************ - * WTSRegisterSessionNotification (WTSAPI32.@) + * WTSRegisterSessionNotificationEx (WTSAPI32.@) */ BOOL WINAPI WTSRegisterSessionNotificationEx(HANDLE hServer, HWND hWnd, DWORD dwFlags) { diff --git a/media/doc/README.WINE b/media/doc/README.WINE index f366990215..69bf99b9c6 100644 --- a/media/doc/README.WINE +++ b/media/doc/README.WINE @@ -212,7 +212,7 @@ reactos/dll/win32/wmi # Synced to WineStaging-2.9 reactos/dll/win32/wmiutils # Synced to WineStaging-2.9 reactos/dll/win32/wmvcore # Synced to Wine-3.0 reactos/dll/win32/wshom.ocx # Synced to Wine-3.0 -reactos/dll/win32/wtsapi32 # Synced to WineStaging-2.9 +reactos/dll/win32/wtsapi32 # Synced to Wine-3.0 reactos/dll/win32/wuapi # Synced to WineStaging-2.9 reactos/dll/win32/xinput1_1 # Synced to WineStaging-2.9 reactos/dll/win32/xinput1_2 # Synced to WineStaging-2.9

2 1

Making bluescreens more useful
by Thomas Faber 14 Jan '18

14 Jan '18

We often get bug reports with just a screenshot of a bluescreen; we then go ahead and tell people that bluescreens are basically useless, they should get a debug log and a backtrace, and also remember to tell us what version they're using. Since there's actually no reason why bluescreens need to be useless, I thought I'd try to change that. I've attached an example. The source for this quick PoC can be found at https://github.com/ThFabba/reactos/commit/6a9f172b76bd11f763598c16e5d47299e… Thoughts?

12 16

Re: [ros-dev] Making bluescreens more useful
by Hermès BÉLUSCA - MAÏTO 13 Jan '18

13 Jan '18

2 1

First NT6+ application support in ReactOS
by Colin Finck 11 Jan '18

11 Jan '18

Hi all! Starting with build 0.4.8-dev-655-g63a3a2c, ReactOS has first support for NT6+ applications (aka programs written for Windows Vista, Windows 7, etc.). Please retest such applications under ReactOS! As newer Windows APIs are still missing in ReactOS, I would be surprised if a high number of NT6+ applications suddenly works. However, many applications may just be compiled by a new Visual Studio without using any modern APIs. They could work now. My "Hello World" compiled by VS 2017 v141 toolchain printed many messages about missing apiset DLLs in the debug log, but otherwise works well. So the next step should obviously be finishing and integrating Mark's work on the apiset DLLs in https://github.com/learn-more/reactos/commits/apisets But interestingly, the build produced by the v141_xp toolchain also looks for these apiset DLLs. Therefore, it would be possible that an application expects a full NT6 system when finding them. Consequently, application compatibility could be compromised if we just dump all apiset DLLs into ReactOS, applications now expect NT6, but the OS continues to behave like NT5 by default. This is why I suggest detecting an NT6+ application in ntdll to have it auto-apply a shim that lets ReactOS behave like an NT6 OS. The apiset DLLs should only be available in this mode, but not for the NT5 personality of ReactOS. Let's not import the apisets before the ntdll shim work is done in order to preserve our existing application compatibility. Cheers, Colin

4 3

Someone's suggestion on IRC about adapting the PS4 linux loading to boot ReactOS
by David Quintana (gigaherz) 10 Jan '18

10 Jan '18

Quoting directly from IRC: [18:22] (Figarocool): hi! [18:23] (Figarocool): is someone online? [18:23] (@gigaherz): yes [18:23] (Figarocool): you a developer? [18:24] (Figarocool): a loader was developed for a few days to load linux on ps4 [18:24] (Figarocool): https://github.com/fail0verflow/ps4-linux [18:25] (Figarocool): would it be possible to port this to start rectos? it would be something of great visibility for the reactos project [18:25] (Figarocool): loader [18:25] (Figarocool): https://github.com/valentinbreiz/PS4-Linux-Loader [18:25] (Figarocool): on firmware 4.05 [18:25] (Figarocool): ps4 runs on x86 [18:26] (Figarocool): would it be complicated to do this for you? [18:26] (@gigaherz): I don't own a ps4 and I'm not an expert in the reactos booting process, so I'm not the right person to ask [18:27] (Figarocool): could you open a discussion about this? [18:28] (@gigaherz): well this is IRC, just talking about it is already a discussion [18:28] (@gigaherz): but if you want something more "official" [18:28] (@gigaherz): you can post this information on an email to the ros-dev mailing list [18:28] (@gigaherz): (subscribe to the mailing list if you want to see the replies) [18:29] (Thedarkb1): You probably could. [18:33] (CatButts): hmmm [18:33] (CatButts): unlike PC, PS4 is single hardware configuration [18:33] (CatButts): getting ReactOS on a PS4? hmmm, that wouldn't hurt [18:34] (CatButts): [19:25] <Figarocool> it would be something of great visibility for the reactos project [18:34] (Figarocool): check: https://github.com/valentinbreiz/PS4-Linux-Loader [18:34] (Figarocool): loader to load linux (x86) and driver [18:35] (Figarocool): however, since reactos and open would be a great novelty for the knowledge of the os [18:35] (Figarocool): so it could give a lot of novelties in the media aspect [18:35] (Figarocool): you could think about it [18:36] (@gigaherz): the loading process of NT is very different from linux [18:36] (@gigaherz): but as I said, because I'm not the right person to ask [18:36] (@gigaherz): it would be best if you put the information on the mailing list [18:36] (@gigaherz): for all the people interested to read [18:36] (Figarocool): could you open the discussion on the mail? [18:37] (@gigaherz): I think it would be best if someone who is actually interested in it would do so [18:38] (Figarocool): I also say this because of the media aspect [18:39] (Figarocool): since they are now installing linux to use the console as a PC [18:39] (Figarocool): this would be great using reactos [18:39] (Figarocool): being x86 all windows games and more would be compatible

1 0

Re: [ros-dev] RAPPS Database now maintained in https://github.com/reactos/rapps-db
by hermes.belusca＠sfr.fr 08 Jan '18

08 Jan '18

<span style="font-family:arial,helvetica,sans-serif; font-size:12px">Talking of which, what's the status of Victor's website for RAPPS submissions?<br> <br> H.‌</span> <div class="gl_quote" style="margin-top: 20px; padding-top: 5px;">De : gigaherz(a)gmail.com<br> A : ros-dev(a)reactos.org<br> Envoyé: lundi 8 janvier 2018 18:28<br> Objet : Re: [ros-dev] RAPPS Database now maintained in https://github.com/reactos/rapps-db<br>   <div class="gl_quoted"> <div dir="ltr"> <div>\o/ awesome!<br>  </div> It would be more awesome to have a crowdsourced (moderated) compatibility database to generate these from, but until that's done, this is a really good addition.</div> <div class="gmail_extra">  <div class="gmail_quote">On 8 January 2018 at 18:15, Colin Finck <span dir="ltr"><<a href="mailto:colin@reactos.org" target="_blank">colin(a)reactos.org</a>></span> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all!<br> <br> We all wanted the RAPPS Database to leave the main source tree for a<br> long time. When Alexander Shaposhnikov asked me today if it was possible<br> to regenerate the rappmgr.cab on every commit, I took the opportunity<br> and split off the /media/rapps folder (including all history) into its<br> own repository: <a href="https://github.com/reactos/rapps-db" rel="noreferrer" target="_blank">https://github.com/reactos/<wbr>rapps-db</a><br> <br> As a bonus, the public database at<br> <a href="https://svn.reactos.org/packages/rappmgr.cab" rel="noreferrer" target="_blank">https://svn.reactos.org/<wbr>packages/rappmgr.cab</a> is now automatically<br> updated with every commit to that repository.<br> <br> I hope you'll like that change :)<br> <br> <br> Cheers,<br> <br> Colin<br> <br> ______________________________<wbr>_________________<br> Ros-dev mailing list<br> <a href="mailto:Ros-dev@reactos.org">Ros-dev(a)reactos.org</a><br> <a href="http://www.reactos.org/mailman/listinfo/ros-dev" rel="noreferrer" target="_blank">http://www.reactos.org/<wbr>mailman/listinfo/ros-dev</a></blockquote> </div> </div> <br> <br> <br> _______________________________________________<br> Ros-dev mailing list<br> Ros-dev(a)reactos.org<br> http://www.reactos.org/mailman/listinfo/ros-dev</div> <div class="gl_quoted"> </div> </div>

2 1

RAPPS Database now maintained in https://github.com/reactos/rapps-db
by Colin Finck 08 Jan '18

08 Jan '18

Hi all! We all wanted the RAPPS Database to leave the main source tree for a long time. When Alexander Shaposhnikov asked me today if it was possible to regenerate the rappmgr.cab on every commit, I took the opportunity and split off the /media/rapps folder (including all history) into its own repository: https://github.com/reactos/rapps-db As a bonus, the public database at https://svn.reactos.org/packages/rappmgr.cab is now automatically updated with every commit to that repository. I hope you'll like that change :) Cheers, Colin

2 1

Project-tools repository converted to Git - Welcome our 18 new repos!
by Colin Finck 08 Jan '18

08 Jan '18

Hi all, I just finished converting our "project-tools" SVN repo to Git and splitting it up into individual repositories in the process. These repos have already been uploaded to GitHub (https://github.com/reactos), so you can have a look and comment easily. Welcome these 18 new repositories: * ahk_tests * buildbot_config * git-tools * irc * Message_Translator * monitoring * packmgr (Archived) * project-tools-archive (Archived) * Qemu_GUI * reactosdbg * Release_Engineering * RosBE * rosev_ircsystem * rosev_jameicaplugin * RosTE * sysreg2 * sysreg3 (Archived) * vmwaregateway I haven't given anyone write access yet. I think this is acceptable for the moment while we check if there are any outstanding issues with the conversion. Please let me know until January 7. If everything is okay by then, I will add write access again and officially move development away from the project-tools SVN repo. Have a good start into 2018! Colin

3 4

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