Just as a reminder: we can put registry stuff, that is related to a
special module, into a separate file together with the module itself
now. This one looks a bit like it should go into the the themeui folder.
Am 18.04.2015 um 11:52 schrieb akhaldi(a)svn.reactos.org:
> Modified: trunk/reactos/boot/bootdata/hivecls.inf
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/hivecls.inf?…
> ==============================================================================
> --- trunk/reactos/boot/bootdata/hivecls.inf [iso-8859-1] (original)
> +++ trunk/reactos/boot/bootdata/hivecls.inf [iso-8859-1] Sat Apr 18 09:52:23 2015
> @@ -265,6 +265,18 @@
> HKCR,"sysfile","NoOpen",0x00000000,""
> HKCR,"sysfile","FriendlyTypeName",0x00020000,"@%SystemRoot%\system32\shell32.dll,-171"
> HKCR,"sysfile\DefaultIcon","",0x00020000,"%SystemRoot%\system32\shell32.dll,-154"
> +
> +; MS Styles (Themes)
> +HKCR,".msstyles","",0x00000000,"msstylesfile"
> +HKCR,"msstylesfile","",0x00000000,"Visual Style File"
> +HKCR,"msstylesfile\DefaultIcon","","0x00020000","%SystemRoot%\system32\themeui.dll,-1"
> +HKCR,"msstylesfile\shell\open\command","",0x00000000,"%SystemRoot%\system32\rundll32.exe shell32.dll,Control_RunDLL %SystemRoot%\system32\desk.cpl desk,@Appearance /Action:OpenMSTheme file:""%1"""
> +
> +; Theme File
> +HKCR,".theme","",0x00000000,"themefile"
> +HKCR,"themefile","",0x00000000,"Theme File"
> +HKCR,"themefile\DefaultIcon","","0x00020000","%SystemRoot%\system32\themeui.dll,-1"
> +HKCR,"themefile\shell\open\command","",0x00000000,"%SystemRoot%\system32\rundll32.exe shell32.dll,Control_RunDLL %SystemRoot%\system32\desk.cpl desk,@Appearance /Action:OpenTheme /file:""%1"""
>
> ; URL shortcuts (e.g. used in favorites folder of IExplorer)
> HKCR,".url","",0x00000000,"InternetShortcut"
>
>
The comment "# Retrieve the full path to the generated file of the
'freeldr_pe' target" Doesn't explain why it is done.
It rather looks like someone is doing something pointless and
documenting in a comment that he's doing the pointless.
${CMAKE_CURRENT_BINARY_DIR} should be the "full path to the generated file". So it seems completely pointless to add extra magic to get that file path. Your commit message implies that this change fixes VSSolution builds, but it also doesn't explain it. In fact I don't even understand that sentence.
If you don't add a proper comment to that thing, why it is needed, I
promise I will have forgotten about this in a year and remove it again. :)
Thanks,
Timo
Am 04.04.2015 um 22:33 schrieb spetreolle(a)svn.reactos.org:
> Author: spetreolle
> Date: Sat Apr 4 20:33:18 2015
> New Revision: 67053
>
> URL: http://svn.reactos.org/svn/reactos?rev=67053&view=rev
> Log:
> [FREELDR]
> In a quest to better registry,
> don't break VSSolution builds.
> freeldr_pe is not in the same directory and copy doesn't care if you ask to concatenate C:\tomatoes, it already has the first file.
>
> Modified:
> trunk/reactos/boot/freeldr/freeldr/CMakeLists.txt
>
> Modified: trunk/reactos/boot/freeldr/freeldr/CMakeLists.txt
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/CMake…
> ==============================================================================
> --- trunk/reactos/boot/freeldr/freeldr/CMakeLists.txt [iso-8859-1] (original)
> +++ trunk/reactos/boot/freeldr/freeldr/CMakeLists.txt [iso-8859-1] Sat Apr 4 20:33:18 2015
> @@ -226,10 +226,13 @@
> add_dependencies(freeldr_pe asm)
> add_dependencies(freeldr_pe_dbg asm)
>
> +# Retrieve the full path to the generated file of the 'freeldr_pe' target
> +get_target_property(_freeldr_pe_output_file freeldr_pe LOCATION)
> +
> concatenate_files(
> ${CMAKE_CURRENT_BINARY_DIR}/freeldr.sys
> ${CMAKE_CURRENT_BINARY_DIR}/frldr16.bin
> - ${CMAKE_CURRENT_BINARY_DIR}/freeldr_pe.dll)
> + ${_freeldr_pe_output_file})
>
> add_custom_target(freeldr ALL DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/freeldr.sys)
>
> @@ -240,7 +243,8 @@
> concatenate_files(
> ${CMAKE_CURRENT_BINARY_DIR}/setupldr.sys
> ${CMAKE_CURRENT_BINARY_DIR}/frldr16.bin
> - ${CMAKE_CURRENT_BINARY_DIR}/freeldr_pe.dll)
> + ${_freeldr_pe_output_file})
>
> add_custom_target(setupldr ALL DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/setupldr.sys)
> add_cd_file(TARGET setupldr FILE ${CMAKE_CURRENT_BINARY_DIR}/setupldr.sys DESTINATION loader NO_CAB FOR bootcd regtest)
> +
>
>
>
Dear all,
On the 3rd of April 2015, the old.reactos.org website will be taken
offline after several years of good services.
If you have anything to do on it (like gathering data or whatever)
please make sure you do before that date.
With my best regards,
--
Pierre Schweitzer <pierre(a)reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
On 03/26/2015 03:52 PM, hbelusca(a)svn.reactos.org wrote:
> Modified: trunk/reactos/subsystems/mvdm/ntvdm/dos/dos32krnl/bios.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/mvdm/ntvdm/dos/…
> ==============================================================================
> --- trunk/reactos/subsystems/mvdm/ntvdm/dos/dos32krnl/bios.c [iso-8859-1] (original)
> +++ trunk/reactos/subsystems/mvdm/ntvdm/dos/dos32krnl/bios.c [iso-8859-1] Thu Mar 26 14:52:16 2015
> @@ -56,6 +56,13 @@
> BOOLEAN DosCheckInput(VOID)
> {
> PDOS_SFT_ENTRY SftEntry = DosGetSftEntry(DOS_INPUT_HANDLE);
> +
> + if (SftEntry == NULL)
> + {
> + /* Invalid handle */
> + DosLastError = ERROR_INVALID_HANDLE; // ERROR_FILE_NOT_FOUND
Hum... Why?
Is the error code wrong and should be ERROR_FILE_NOT_FOUND? And then,
why setting this other error code?
Or is the error code right, and then, what's the purpose of such comment?
Or do you have a doubt about the right error code to use? Be it one or
the other?
I come back to my eternal comment: don't comment for yourself. Comment
for the others, you're not alone here. So, make it explicit.
Cheers,
--
Pierre Schweitzer <pierre(a)reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
Hey,
Win2k3 is end of support in 6 months, which will mean that the symbol
server will go down (as it has done for XP).
At the very least, we should scrape the symbol server so we can
continue to check and debug.
Or move to NT6...
Hello,
Let me invite you to the monthly status meeting taking place today 26th
of March, 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.
If someone still is not getting passwords sent before a meeting - please
email Pierre before the meeting started to get one.
Please send agenda proposals to me before the meeting, so that we can
start with a proposed agenda.
And join Mumble!
Regards,
Aleksey Bragin
Timo and C++??
Hell must be a bit chilly today :)
-----Original Message-----
From: Ros-diffs [mailto:ros-diffs-bounces@reactos.org] On Behalf Of tkreuzer(a)svn.reactos.org
Sent: 25 March 2015 22:38
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [tkreuzer] 66893: [WIN32K] Rewrite brush code in C++
Author: tkreuzer
Date: Wed Mar 25 22:38:20 2015
New Revision: 66893
URL: http://svn.reactos.org/svn/reactos?rev=66893&view=rev
Log:
[WIN32K]
Rewrite brush code in C++
Dear all,
Due to DB maintenance, Jira & Fisheye will be down in a few minutes.
There's no ETA for up status.
Sorry for the caused inconvenience,
--
Pierre Schweitzer <pierre(a)reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
Thank you, with revision 66721 everything is ok with building ReactOS
> Hi Fedor,
>
>> Hi. I am trying to compile ReactOS on my macbook with OSX 10.10 on it, but I got an error. Building tools compiled quite well (with some warmings, but I think that it is ok), but when I call "ninja all? I got error:
> Can you please try with r66700 and report back?
>
> Cheers,
> Amine.
dreimer(a)svn.reactos.org wrote:
> [RAPPS] lack of a proxy configuration by Peter Hater.
I don't think we need a separate proxy configuration per application.
We should rather keep things consistent and always use the system
proxy set in the "Internet Options" control panel applet.
Unless someone has any objections, I suggest reverting this.
- Colin
Hi. I am trying to compile ReactOS on my macbook with OSX 10.10 on it, but I got an error. Building tools compiled quite well (with some warmings, but I think that it is ok), but when I call "ninja all» I got error:
bash-3.2$ cd ../../output-MinGW-i386/reactos
bash-3.2$ ninja
[544/8381] Building C object dll/openg...Files/mesa_main.dir/api_arrayelt.c.obj
FAILED: /usr/local/RosBE/i386/bin/i686-w64-mingw32-gcc -DBUILD_GL32 -DFEATURE_GL=1 -DKDBG=1 -DOPENGL32_USE_TLS -DUSE_3DNOW_ASM -DUSE_COMPILER_EXCEPTIONS -DUSE_MMX_ASM -DUSE_SSE_ASM -DUSE_X86_ASM -DWIN32 -DWINVER=0x502 -D_DLL -D_GDI32_ -D_GLAPI_NO_EXPORTS -D_M_IX86 -D_SEH_ENABLE_TRACE -D_SETUPAPI_VER=0x502 -D_USE_32BIT_TIME_T -D_USE_PSEH3=1 -D_WIN32_IE=0x600 -D_WIN32_WINDOWS=0x502 -D_WIN32_WINNT=0x502 -D_WINDOWS -D_X86_ -D__REACTOS__ -D__i386__ -D_inline=__inline -Di386 -Wa,--compress-debug-sections -pipe -fms-extensions -fno-strict-aliasing -mstackrealign -Wold-style-declaration -Wdeclaration-after-statement -fdebug-prefix-map="/Users/lobster/documents/RosBE/reactos"=ReactOS -gdwarf-2 -gstrict-dwarf -femit-struct-debug-detailed=none -feliminate-unused-debug-symbols -march=pentium -mtune=i686 -Werror -Wall -Wpointer-arith -Wno-char-subscripts -Wno-multichar -Wno-unused-value -Wno-maybe-uninitialized -Wno-error=unused-but-set-variable -Wno-error=type-limits -O1 -fno-optimize-sibling-calls -fno-omit-frame-pointer -mpreferred-stack-boundary=3 -fno-set-stack-executable -Winvalid-pch -Werror=invalid-pch -g -Idll/opengl/mesa/main -I../../dll/opengl/mesa/main -I../../include -I../../include/psdk -I../../include/dxsdk -Iinclude -Iinclude/psdk -Iinclude/dxsdk -Iinclude/reactos -I../../include/crt -I../../include/ddk -I../../include/ndk -I../../include/reactos -I../../include/reactos/libs -I../../dll/opengl/mesa/. -Wno-error -Wno-type-limits -include /Users/lobster/documents/RosBE/reactos/output-MinGW-i386/reactos/dll/opengl/mesa/main/mesa_main_pch.h -MMD -MT dll/opengl/mesa/main/CMakeFiles/mesa_main.dir/api_arrayelt.c.obj -MF dll/opengl/mesa/main/CMakeFiles/mesa_main.dir/api_arrayelt.c.obj.d -o dll/opengl/mesa/main/CMakeFiles/mesa_main.dir/api_arrayelt.c.obj -c ../../dll/opengl/mesa/main/api_arrayelt.c
cc1: warning: /Users/lobster/documents/RosBE/reactos/output-MinGW-i386/reactos/dll/opengl/mesa/main/mesa_main_pch.h.gch: had text segment at different address [enabled by default]
cc1: error: one or more PCH files were found, but they were invalid
cc1: fatal error: /Users/lobster/documents/RosBE/reactos/output-MinGW-i386/reactos/dll/opengl/mesa/main/mesa_main_pch.h: No such file or directory
compilation terminated.
…
…
and so on
What I am doing wrong? I have googled, but I don’t found anything relevant
Thanks
Allright, so NTVDM is evil.
Pretty good choice, as I wouldn't want to taint kernel or other
important part of the system by 66666 commit made on Friday 13th... ;-)
Regards,
Aleksey Bragin
On 13.03.2015 20:57, aandrejevic(a)svn.reactos.org wrote:
> Author: aandrejevic
> Date: Fri Mar 13 17:57:51 2015
> New Revision: 66666
>
> URL: http://svn.reactos.org/svn/reactos?rev=66666&view=rev
> Log:
> [NTVDM][FAST486]
> - Implement VDDInstallMemoryHook and VDDDeInstallMemoryHook using page guards.
> - Implement another API for memory hooks that should be faster than page guards
> (for NTVDM only).
> - Adjust the VGA and EMS memory handlers to use this method.
> - In Fast486, implement a method that will allow us to "rewind" the current instruction,
> in case it was interrupted by a memory hook page fault.
> - Use a memory hook to protect the BIOS ROM from being written to.
>
dreimer(a)svn.reactos.org wrote:
> [RAPPS] lack of a proxy configuration by Peter Hater.
I don't think we need a separate proxy configuration per application.
We should rather keep things consistent and always use the system
proxy set in the "Internet Options" control panel applet.
Unless someone has any objections, I suggest reverting this.
- Colin
Hi,
Here's the promised suggestion regarding how we handle versioning
problems in reactos. It has some relationship to the tree restructure.
Since some time we now run into issues with our targeted Windows
version. This is both wine dlls, as well as applications that refuse to
run due to reactos being limited to Windows server 2003 SP2.
I think many of us, me included, see more in ReactOS than an academic
research project, or a nice way for 3rd party companies to cheaply get
insight into how the Windows kernel works. So we are interested in
making it an actually useful operating system. To achieve this goal, it
is obviously important to make it run modern Windows applications.
The current approach of pure Windows 2003 Server SP2 compatibility on
user mode side is a dead end. Our target OS version is starting to
become a fossil. With time more and more applications will simply refuse
to work on it. Even wine DLLs start to require Vista APIs and their
number will most likely increase.
So what can we do? It is obvious, that we cannot instantaniously switch
all user mode to Windows 7/8/10 compatibility, due to the amount of
required work, especially regarding missing kernel features.
The wine approach is just adding whatever is needed, creating a Windows
version chimera. It has already been discussed here and shown to be a
problem, since it can easily fool applications into believing they run
on Vista or Windows 7, making them demand all the modern features, which
we cannot provide, thus failing to run, while they would run flawlessly,
when being provided a pure Windows 2003 environment, restricting itself
to this functionality. So this is also not a very good way, either.
So the conclusion is, that we need a mechanism, that allows us to
control this, providing individual applications with what they require,
while leaving others in a more restricted environment. And at the same
time allowing our internal/wine DLLs to make use of higher version
functionality.
Suggested approach:
1. We need a method to specify which application should be run in which
environment. We should probably use the same mechanism that is used on
Windows. Compatibility information is stored in a registry key
HKCU\Software\Microsodt\Windows NT\CurrentVersion\AppCompatFlags\... The
trick is to make this easy / transparent for the user. A right-click ->
properties -> compatibility approach should for now probably be the
easiest thing, even if it requires the user to actively make this
setting. A larger app compatibility database would be nice, but it would
be difficult to figure out what application is being run. And it's also
a problem to maintain such a list. Potential solutions: detect failures
to load due to missing imports and app crashes and invoke a
"compatibility assistent" in that case. Detect first-run of a new
application and try to identify it, either based on a hash or based on
PE version information.
2. We need a way to provide the application transparently with the
environment we want to give it. In terms of DLL exports this could be
done on the loader side, making it chose the right DLL, potentially
adding a suffix to the DLL name or selecting a different folder other
than system32. While this will most likely work good in the majority of
cases, it is not 100% transparent. Therefore a mechanism in the kernel,
using file system redirection, like it already exists on 64 bit Windows
for WoW64, seems to be a more promising approach. The file system
redirection would redirect system32 into merged folders, containing the
version specific DLLs, while everything that is not existing in this
folder will be taken from the original system32. Potential naming
scheme: system32.601 system32.602, etc.
3. We need a method to create and maintain the required DLLs for
different OS versions. Preferably avoiding bloat by sharing common code
in common "parent" DLLs. But also allowing to still plug the DLLs into
the related Windows version for testing. This can be tricky. I suggest a
DLL import forwarding scheme. This is both to avoid bloat, i.e. avoid to
compile and deploy all full blown DLLs for all OS versions, as well as
creating a better organized system. So each DLL, lets say ADVAPI32, as
located in different version specific system32 folders, would
mainly/only consist of forwarders to a "parent" DLL. On Windows we can
see this being developed similarly, using "api sets" and redirections
made by the loader. Cloning this mechanism 1:1 might not be the right
thing though, since it does not address all our requirements. So instead
I suggest proving our own custom "parent DLLs". While these could be
organized the same way as on Windows 2003, this is probably not optimal.
Instead I suggest merging stuff together into 1 or few DLLs (similar to
how stuff was combined in kernelbase.dll)
This might looks like this (note, that the names are just quickly made
up names, I don't claim that they are good)
- user32/gdi32 -> ros-win32-core.dll
- kernel32/advapi32 -> ros-kernel-base.dll
- msvcr* -> ros-crt.dll
- ntdll -> ros-ntdll (the kernel would need to load this one)
This also allows our DLLs to make use of higher version APIs, by linking
them to the parent DLL.
Now this obviously introduces a problem when trying to run individual
DLLs within a Windows system. To still be able to do this for testing
purposes, we need to make sure that they still run there.
First, if they import from a custom ros-* DLL, it won't run on Windows
without that DLL. So we need the possibility to either statically link
these functions, or compile a "helper DLL", that contains these
functions, so our DLLs can be run on Windows.
If we used a common parent DLL, this also creates the problem of DLL
initialization. e.g. the DLL parent for kernel32 and advapi32 would do
the initialization for both of these, so this would not be suitable to
use when replacing only one of the DLLs. Instead DLL initialization
could be done by calling a specific initialization function in the
parent DLL from the child DLL. So kernel32!DllMain would call
ros-kernel-base!DllMain_kernel32, passing the original parameters as
well as a version number, that the parent DLL can use to do version
specific initialization. This way The parent DLL would only do the
kernel32 initialization, when the related kernel32 child DLL was used,
the advapi32 initialization would not be done.
There is still a problem: relocation. So we would need to make sure we
chose base addresses that still allow us to plug the stuff into Windows
without causing everything to relocate, which often simply doesn't work.
As an alternative, we should provide a compile time switch to compile
specific DLLs in a self-contained way.
In terms of structure we could use the MS api-sets as a base for static
libraries. Then we can link these either into the parent DLLs like
ros-kernel-base.dll or - when a compile switch is given - to link
together fully self contained DLLs.
I am really not interested in answers like "This is not what WIndows
does!", "THIS CANNOT WORK!!!", "You are a ***** even suggesting this",
"What if application x parses the import table and disassembles the DLL
to hook into internal functions, ...":
I am only interested in *constructive* comments.
Everything else: -> /dev/null
Thanks,
Timo
On 2015-03-10 11:10, akhaldi(a)svn.reactos.org wrote:
> +if(NOT MSVC)
> + add_target_compile_flags(advapi32_winetest "-Wno-format")
> +endif()
Why are we getting format warnings? Is __WINESRC__ not set correctly?