Hello,
Let me invite you to the monthly status meeting taking place last
Thursday of this month, 30th of August, 19:00 UTC.
The meeting will be at irc://fezile.reactos.org (Port 6667, no SSL) in
the channel #meeting, if the server works. If not, then an alternative
place will be announced here. Note that the IRC service will only be
started shortly before the meeting. Your participation passwords will be
emailed to you shortly before the meeting starts.
If someone still is not getting passwords sent before a meeting - please
email Colin or Pierre before the meeting started to get one.
In order to save time, let's choose who is going to be the minute taker
on the upcoming meeting. As usual, Z98 is welcome to volunteer.
The agenda will be posted shortly before the meeting, suggestions are
welcome (send them to my email as usual).
With the best regards,
Aleksey Bragin.
Hi,
I don't agree with these changes.
If we need a DllEntry in the lib, then we should use the one that is
provided by mingw-w64 (all this code is 100% mingw-w64). It simply
returns true (thats exactly what the one in MS CRT does) and works for
gcc and MSVC.
Also what's the point of DisableThreadLibraryCalls() here? As you wrote
yourself, no DllMain only means "I have nothing more to initialize than
the CRT". But this disables the CRT thread initializion, too.
There is also no need for weak symbols, we can simply call the stub
DllMain, since it doesn't (shouldn't) do anything.
Regards,
Timo
Am 27.08.2012 01:31, schrieb jgardou(a)svn.reactos.org:
> Author: jgardou
> Date: Sun Aug 26 23:31:49 2012
> New Revision: 57171
>
> URL: http://svn.reactos.org/svn/reactos?rev=57171&view=rev
> Log:
> [MINGWEX]
> - mark DllMain as a weak symbol for GCC.
> - supply a stubbed DllMain for MSVC.
> - DllMain is optional, and some DLLs don't implement it. That doesn't mean that they have no entry point, it means "I have nothing more to initialize than the CRT".
>
> Added:
> trunk/reactos/lib/sdk/crt/startup/mscdllmain.c (with props)
> Modified:
> trunk/reactos/lib/sdk/crt/msvcrtex.cmake
> trunk/reactos/lib/sdk/crt/startup/crtdll.c
>
> Modified: trunk/reactos/lib/sdk/crt/msvcrtex.cmake
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/sdk/crt/msvcrtex.cmake…
> ==============================================================================
> --- trunk/reactos/lib/sdk/crt/msvcrtex.cmake [iso-8859-1] (original)
> +++ trunk/reactos/lib/sdk/crt/msvcrtex.cmake [iso-8859-1] Sun Aug 26 23:31:49 2012
> @@ -66,7 +66,9 @@
> endif()
>
> if(MSVC)
> - list(APPEND MSVCRTEX_SOURCE startup/mscmain.c)
> + list(APPEND MSVCRTEX_SOURCE
> + startup/mscmain.c
> + startup/mscdllmain.c)
> else()
> list(APPEND MSVCRTEX_SOURCE startup/gccmain.c)
> endif()
>
> Modified: trunk/reactos/lib/sdk/crt/startup/crtdll.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/sdk/crt/startup/crtdll…
> ==============================================================================
> --- trunk/reactos/lib/sdk/crt/startup/crtdll.c [iso-8859-1] (original)
> +++ trunk/reactos/lib/sdk/crt/startup/crtdll.c [iso-8859-1] Sun Aug 26 23:31:49 2012
> @@ -50,7 +50,19 @@
>
> extern int mingw_app_type;
>
> +/*
> + * It is possible that a DLL provides no DllMain entry point.
> + * Mark it as a weak symbol for GCC.
> + * Tests show that at link time, MSVC looks for a function first in the object files provided, and then
> + * in the libraries. This means that we must provide a basic implementation in msvcrtex, which will be used
> + * if none is found in the object files provided to link.exe.
> + * This also means that we can't rely on a DllMain function implemented in a static library when linking a DLL.
> + */
> +#ifdef __GNUC__
> +extern WINBOOL WINAPI DllMain (HANDLE hDllHandle, DWORD dwReason, LPVOID lpreserved) __attribute__((weak));
> +#else
> extern WINBOOL WINAPI DllMain (HANDLE hDllHandle, DWORD dwReason, LPVOID lpreserved);
> +#endif
>
> extern WINBOOL WINAPI DllEntryPoint (HANDLE, DWORD, LPVOID);
>
> @@ -198,10 +210,12 @@
> }
> if (dwReason == DLL_PROCESS_ATTACH)
> __main ();
> - retcode = DllMain(hDllHandle,dwReason,lpreserved);
> + if(DllMain)
> + retcode = DllMain(hDllHandle,dwReason,lpreserved);
> if (dwReason == DLL_PROCESS_ATTACH && ! retcode)
> {
> - DllMain (hDllHandle, DLL_PROCESS_DETACH, lpreserved);
> + if(DllMain)
> + DllMain (hDllHandle, DLL_PROCESS_DETACH, lpreserved);
> DllEntryPoint (hDllHandle, DLL_PROCESS_DETACH, lpreserved);
> _CRT_INIT (hDllHandle, DLL_PROCESS_DETACH, lpreserved);
> }
>
> Added: trunk/reactos/lib/sdk/crt/startup/mscdllmain.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/sdk/crt/startup/mscdll…
> ==============================================================================
> --- trunk/reactos/lib/sdk/crt/startup/mscdllmain.c (added)
> +++ trunk/reactos/lib/sdk/crt/startup/mscdllmain.c [iso-8859-1] Sun Aug 26 23:31:49 2012
> @@ -1,0 +1,11 @@
> +#include <oscalls.h>
> +#define _DECL_DLLMAIN
> +#include <process.h>
> +
> +WINBOOL WINAPI DllMain (HANDLE hDllHandle, DWORD dwReason, LPVOID lpreserved)
> +{
> + /* If the DLL provides no DllMain, then chances are that it doesn't bother with thread initialization */
> + if(dwReason == DLL_PROCESS_ATTACH)
> + DisableThreadLibraryCalls(hDllHandle);
> + return TRUE;
> +}
>
> Propchange: trunk/reactos/lib/sdk/crt/startup/mscdllmain.c
> ------------------------------------------------------------------------------
> svn:eol-style = native
>
>
>
Btw, we are using a lot of hardcoded 512 values here for sector size
even though there is a field in fthe Volume structure for that.
Is that correct?
Am 23.08.2012 14:02, schrieb tkreuzer(a)svn.reactos.org:
> Author: tkreuzer
> Date: Thu Aug 23 12:02:30 2012
> New Revision: 57141
>
> URL: http://svn.reactos.org/svn/reactos?rev=57141&view=rev
> Log:
> [FREELDR]
> Improve readability of sector calculation
>
> Modified:
> trunk/reactos/boot/freeldr/freeldr/fs/fat.c
>
> Modified: trunk/reactos/boot/freeldr/freeldr/fs/fat.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/fs/fa…
> ==============================================================================
> --- trunk/reactos/boot/freeldr/freeldr/fs/fat.c [iso-8859-1] (original)
> +++ trunk/reactos/boot/freeldr/freeldr/fs/fat.c [iso-8859-1] Thu Aug 23 12:02:30 2012
> @@ -1338,8 +1338,7 @@
> //
> // Seek to right position
> //
> - Position.HighPart = SectorNumber >> 23;
> - Position.LowPart = SectorNumber << 9;
> + Position.QuadPart = (ULONGLONG)SectorNumber * 512;
> ret = ArcSeek(Volume->DeviceId, &Position, SeekAbsolute);
> if (ret != ESUCCESS)
> {
>
>
>
Hi,
On 2012-08-26 11:17, jgardou(a)svn.reactos.org wrote:
> Log:
> [OPENGL32_WINETEST]
> - Sync with wine
speaking from previous experience, it'd be very nice if the commit
message would allow finding the correctly matched Wine version for this
easily (i.e. without tedious look-up of what was HEAD on whatever date
the commit was).
Thanks!
Best regards,
Thomas
Hi,
after having finished its 11405th build, the last official RBuild
builder has gone offline, forever.
The Linux CMake builder has now turned as being the official builder.
Thanks RBuild, you served us well :-).
Also, the other RBuild builder, the release builder has also gone
offline forever. Its hardware was not able to properly handle a ReactOS
build, and was hardly upgradable.
Daily release builds should replace it any time soon.
With my best regards,
--
Pierre Schweitzer <pierre(a)reactos.org>
Systems Administrator
ReactOS Foundation
Hi,
On 2012-08-21 15:38, jgardou(a)svn.reactos.org wrote:
> URL:http://svn.reactos.org/svn/reactos?rev=57124&view=rev
> Log:
> [WINED3D]
> - MSVC needs INFINITY and NAN from wine/port.h.
> It can't be included from a header
> Will be sent upstream
can you explain what's wrong with including it from a header?
I was under the impression we had fixed the infinity/nan stuff properly
on Wine's side by adding it all to port.h.
Thanks!
-Thomas
Hmmmmmmm....
I don't think that this is a good idea. We must call DC_vPrepareForBlit
to lock the surfaces, otherwise we run into race conditions.
And we should really also care for the mouse cursor, otherwise we might
make it unhappy.
Anyway, I don't care about this code, since I already rewrote it :D
Anyway, I think it's time to ASSERT device locks.
Am 22.08.2012 18:45, schrieb jgardou(a)svn.reactos.org:
> Author: jgardou
> Date: Wed Aug 22 16:45:49 2012
> New Revision: 57129
>
> URL: http://svn.reactos.org/svn/reactos?rev=57129&view=rev
> Log:
> [WIN32K]
> - Use the right surface for direct DCs in DIB transfer functions
> It could have changed with a display settings change
>
> Modified:
> trunk/reactos/win32ss/gdi/ntgdi/dibobj.c
>
> Modified: trunk/reactos/win32ss/gdi/ntgdi/dibobj.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/dibobj.c…
> ==============================================================================
> --- trunk/reactos/win32ss/gdi/ntgdi/dibobj.c [iso-8859-1] (original)
> +++ trunk/reactos/win32ss/gdi/ntgdi/dibobj.c [iso-8859-1] Wed Aug 22 16:45:49 2012
> @@ -447,8 +447,16 @@
> DC_UnlockDc(pDC);
> goto Exit2;
> }
> -
> - pSurf = pDC->dclevel.pSurface;
> +
> + /*
> + * Select the right surface.
> + * NOTE: we don't call DC_vPrepareDCsForBlit, because we don't
> + * care about mouse, visible region or brushes in this API.
> + */
> + if(pDC->dctype == DCTYPE_DIRECT)
> + pSurf = pDC->ppdev->pSurface;
> + else
> + pSurf = pDC->dclevel.pSurface;
> if (!pSurf)
> {
> DC_UnlockDc(pDC);
> @@ -1113,7 +1121,15 @@
> goto cleanup;
> }
>
> - psurfDst = pdc->dclevel.pSurface;
> + /*
> + * Select the right surface.
> + * NOTE: we don't call DC_vPrepareDCsForBlit, because we don't
> + * care about mouse, visible region or brushes in this API.
> + */
> + if(pdc->dctype == DCTYPE_DIRECT)
> + psurfDst = pdc->ppdev->pSurface;
> + else
> + psurfDst = pdc->dclevel.pSurface;
> if (!psurfDst)
> {
> // CHECKME
>
>
>
For me it looks like _pwctype, __p__pwctype and __pwctype_func also
need to be fixed.
Am 20.08.2012 19:20, schrieb fireball(a)svn.reactos.org:
> Author: fireball
> Date: Mon Aug 20 17:20:48 2012
> New Revision: 57119
>
> URL: http://svn.reactos.org/svn/reactos?rev=57119&view=rev
> Log:
> [CRT]
> - Use wine's wctype table in CRT for iswctype() function. Previous implementation was returning incorrect information for non-Latin characters. Problem found and fixed by Sergey Shamanaev (seven_ro).
> - Move wctype.c from libwine to lib/sdk/crt instead of making yet another copy of it (currently there is one more in tools/unicode). Suggested by Amine Khaldi.
> See issue #5090 for more details.
>
> Added:
> trunk/reactos/lib/sdk/crt/string/wctype.c
> - copied unchanged from r57101, trunk/reactos/lib/3rdparty/libwine/wctype.c
> Removed:
> trunk/reactos/lib/3rdparty/libwine/wctype.c
> Modified:
> trunk/reactos/lib/3rdparty/libwine/CMakeLists.txt
> trunk/reactos/lib/sdk/crt/crt.cmake
> trunk/reactos/lib/sdk/crt/string/ctype.c
>
> [This mail would be too long, it was shortened to contain the URLs only.]
>
> Modified: trunk/reactos/lib/3rdparty/libwine/CMakeLists.txt
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/3rdparty/libwine/CMake…
>
> Removed: trunk/reactos/lib/3rdparty/libwine/wctype.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/3rdparty/libwine/wctyp…
>
> Modified: trunk/reactos/lib/sdk/crt/crt.cmake
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/sdk/crt/crt.cmake?rev=…
>
> Modified: trunk/reactos/lib/sdk/crt/string/ctype.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/sdk/crt/string/ctype.c…
>
>
>