Re: [ros-dev] [ros-diffs] [jgardou] 66334: [NTOSKRNL/MM] - MiIsEntireRangeCommitted: Ensure the PTE we are checking is really faulted in. - Prefer MiPteToPde and MiPdeToPte (which should really be cal
If it takes me 6 months to understand why, then yes.
Hint: you can make this delay shorter.
Also the title is a bit misleading, it's the PDE that is not faulted in
in case we don't terminate the loop iteration early.
Le 19/02/2015 05:46, Alex Ionescu a écrit :
it might fix an assert but the patch is incorrect. will this also take 6
months to revert?
Best regards,
Alex Ionescu
On Tue, Feb 17, 2015 at 6:19 AM, jgar...@svn.reactos.org wrote:
Author: jgardou
Date: Tue Feb 17 14:19:05 2015
New Revision: 66334
URL: http://svn.reactos.org/svn/reactos?rev=66334view=rev
Log:
[NTOSKRNL/MM]
- MiIsEntireRangeCommitted: Ensure the PTE we are checking is really
faulted in.
- Prefer MiPteToPde and MiPdeToPte (which should really be called
MiFirstPteInPde) instead of MiAddressToPte and MiPteToAddress
Fixes weird failed ASSERT in page fault handler when using DPH.
Modified:
trunk/reactos/ntoskrnl/mm/ARM3/virtual.c
Modified: trunk/reactos/ntoskrnl/mm/ARM3/virtual.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/virtual.c?rev=66334r1=66333r2=66334view=diff
==
--- trunk/reactos/ntoskrnl/mm/ARM3/virtual.c[iso-8859-1] (original)
+++ trunk/reactos/ntoskrnl/mm/ARM3/virtual.c[iso-8859-1] Tue Feb 17
14:19:05 2015
@@ -1994,14 +1994,13 @@
if (OnBoundary)
{
/* Is this PDE demand zero? */
-PointerPde = MiAddressToPte(PointerPte);
+PointerPde = MiPteToPde(PointerPte);
if (PointerPde-u.Long != 0)
{
/* It isn't -- is it valid? */
if (PointerPde-u.Hard.Valid == 0)
{
/* Nope, fault it in */
-PointerPte = MiPteToAddress(PointerPde);
MiMakeSystemAddressValid(PointerPte, Process);
}
}
@@ -2009,13 +2008,13 @@
{
/* The PTE was already valid, so move to the next one */
PointerPde++;
-PointerPte = MiPteToAddress(PointerPde);
+PointerPte = MiPdeToPte(PointerPde);
/* Is the entire VAD committed? If not, fail */
if (!Vad-u.VadFlags.MemCommit) return FALSE;
-/* Everything is committed so far past the range, return
true */
-if (PointerPte LastPte) return TRUE;
+/* New loop iteration with our new, on-boundary PTE. */
+continue;
}
}
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 66342: [WIN32SS/NTGDI] - Reject bits data early in SetBitmapBits when it's clear that they can't fit in the destination bitmap. Fixes ugly Office 2007 rulers showin
I don't really see what we could be doing wrong here. We're not
responsible for the data an application passes to us.
If we're not capable of correctly giving back the tuple (width,height,
bpp) which permits to calculate the buffer size, we'd better stop
everything and start thinking about raising goats in Greenland.
Le 18/02/2015 09:40, Timo Kreuzer a écrit :
Is this a bug in Office 2007 or are we doing something wrong here?
Am 17.02.2015 um 21:41 schrieb jgar...@svn.reactos.org:
Author: jgardou
Date: Tue Feb 17 20:41:51 2015
New Revision: 66342
URL: http://svn.reactos.org/svn/reactos?rev=66342view=rev
Log:
[WIN32SS/NTGDI]
- Reject bits data early in SetBitmapBits when it's clear that they
can't fit in the destination bitmap.
Fixes ugly Office 2007 rulers showing garbage.
Modified:
trunk/reactos/win32ss/gdi/ntgdi/bitmaps.c
Modified: trunk/reactos/win32ss/gdi/ntgdi/bitmaps.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/bitmaps.c?rev=66342r1=66341r2=66342view=diff
==
--- trunk/reactos/win32ss/gdi/ntgdi/bitmaps.c[iso-8859-1] (original)
+++ trunk/reactos/win32ss/gdi/ntgdi/bitmaps.c[iso-8859-1] Tue Feb
17 20:41:51 2015
@@ -11,7 +11,8 @@
#define NDEBUG
#include debug.h
-void
+static
+int
NTAPI
UnsafeSetBitmapBits(
PSURFACE psurf,
@@ -32,6 +33,9 @@
lDeltaDst = psurf-SurfObj.lDelta;
lDeltaSrc = WIDTH_BYTES_ALIGN16(nWidth, cBitsPixel);
+if (cjBits (cjBits (lDeltaSrc * nHeight)))
+return 0;
+
while (nHeight--)
{
/* Copy one line */
@@ -40,6 +44,7 @@
pjDst += lDeltaDst;
}
+return 1;
}
HBITMAP
@@ -538,9 +543,8 @@
_SEH2_TRY
{
-ProbeForRead(pUnsafeBits, Bytes, 1);
-UnsafeSetBitmapBits(psurf, Bytes, pUnsafeBits);
-ret = 1;
+ProbeForRead(pUnsafeBits, Bytes, sizeof(WORD));
+ret = UnsafeSetBitmapBits(psurf, Bytes, pUnsafeBits);
}
_SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER)
{
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 66161: [NTDLL] - use the edx register to store the function pointer to the syscall trampoline. This is how google Chrome checks if an exported function is a system
Not really. They still could use the same trampoline mechanism, with a function pointer to some kind of user-mode dispatcher, like we and windows do with the syscall dispatcher. They just understandably don't care enough to do it. Le 04/02/2015 18:36, Hermès BÉLUSCA - MAÏTO a écrit : About the Wine bug report...: ils l'ont dans le XXX ? -Message d'origine- De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Jérôme Gardou Envoyé : mercredi 4 février 2015 18:02 À : ros-dev@reactos.org Objet : Re: [ros-dev] [ros-diffs] [jgardou] 66161: [NTDLL] - use the edx register to store the function pointer to the syscall trampoline. This is how google Chrome checks if an exported function is a system call or not. See https:... Uh, sorry for the horriblly long diff. I guess someone initially committed the file with CRLF file endings :-/ Le 04/02/2015 17:58, jgar...@svn.reactos.org a écrit : Author: jgardou Date: Wed Feb 4 16:58:41 2015 New Revision: 66161 URL: http://svn.reactos.org/svn/reactos?rev=66161view=rev Log: [NTDLL] - use the edx register to store the function pointer to the syscall trampoline. This is how google Chrome checks if an exported function is a system call or not. See https://chromium.googlesource.com/chromium/src.git/+/master/sandbox/wi n/src/service_resolver_32.cc and https://bugs.winehq.org/show_bug.cgi?id=21232 for details Modified: trunk/reactos/include/asm/syscalls.inc Modified: trunk/reactos/include/asm/syscalls.inc URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/asm/syscalls. inc?rev=66161r1=66160r2=66161view=diff == --- trunk/reactos/include/asm/syscalls.inc [iso-8859-1] (original) +++ trunk/reactos/include/asm/syscalls.inc [iso-8859-1] Wed Feb 4 16:58:41 2015 @@ -1,109 +1,109 @@ - -#ifdef _M_IX86 -#define KUSER_SHARED_SYSCALL HEX(7ffe0300) -#define KGDT_R0_CODE 8 -MACRO(STUBCODE_U, Name, SyscallId, ArgCount) -StackBytes = 4 * ArgCount -FPO 0, 0, 0, 0, 0, FRAME_FPO -mov eax, SyscallId -mov ecx, KUSER_SHARED_SYSCALL -call dword ptr [ecx] -ret StackBytes -ENDM -MACRO(STUBCODE_K, Name, SyscallId, ArgCount) -StackBytes = 4 * ArgCount -FPO 0, 0, 0, 0, 0, FRAME_FPO -mov eax, SyscallId -lea edx, [esp + 4] -pushfd -push KGDT_R0_CODE -call _KiSystemService -ret StackBytes -ENDM -#elif defined(_M_AMD64) -MACRO(STUBCODE_U, Name, SyscallId, ArgCount) -.ENDPROLOG -mov eax, SyscallId -mov r10, rcx -syscall -ret -ENDM -MACRO(STUBCODE_K, Name, SyscallId, ArgCount) -.ENDPROLOG -EXTERN NtName:PROC -lea rax, NtName[rip] -mov r10, ArgCount * 8 -jmp KiZwSystemService -ENDM -#elif defined(_M_ARM) -MACRO(STUBCODE_U, Name, SyscallId, ArgCount) -swi #SyscallId -bx lr -ENDM -MACRO(STUBCODE_K, Name, SyscallId, ArgCount) -mov ip, lr -swi #SyscallId -bx ip -ENDM -#elif defined(_M_PPC) -MACRO(STUBCODE_U, Name, SyscallId, ArgCount) -stwu 1,-16(1) -mflr 0 -stw 0,0(1) -li 0, SyscallId -sc -lwz 0,0(1) -mtlr 0 -addi 1,1,16 -blr -ENDM -#define STUBCODE_K STUBCODE_U -#elif defined(_M_MIPS) -MACRO(STUBCODE_U, Name, SyscallId, ArgCount) -li $8, KUSER_SHARED_SYSCALL -lw $8,0($8) -j $8 -nop -ENDM -MACRO(STUBCODE_K, Name, SyscallId, ArgCount) -j KiSystemService -nop -ENDM -#else -#error unsupported architecture -#endif - -#ifdef _M_IX86 -MACRO(MAKE_LABEL, Name, StackBytes) -PUBLIC _Name@StackBytes -_Name@StackBytes: -ENDM -MACRO(START_PROC, Name, StackBytes) -PUBLIC _Name@StackBytes -.PROC _Name@StackBytes -ENDM -#else -MACRO(MAKE_LABEL, Name, StackBytes) -PUBLIC Name -Name: -ENDM -MACRO(START_PROC, Name, StackBytes) -PUBLIC Name -.PROC Name -ENDM -#endif - -MACRO(STUB_U, Name, ArgCount) -MAKE_LABEL ZwName, %ArgCount * 4 -START_PROC NtName, %ArgCount * 4 -STUBCODE_U Name, SyscallId, %ArgCount -.ENDP -SyscallId = SyscallId + 1 -ENDM - -MACRO(STUB_K, Name, ArgCount) -START_PROC ZwName, %ArgCount * 4 -STUBCODE_K Name, SyscallId, %ArgCount -.ENDP -SyscallId = SyscallId + 1 -ENDM + +#ifdef _M_IX86 +#define KUSER_SHARED_SYSCALL HEX(7ffe0300) #define KGDT_R0_CODE 8 +MACRO(STUBCODE_U, Name, SyscallId, ArgCount) +StackBytes = 4 * ArgCount +FPO 0, 0, 0, 0, 0, FRAME_FPO +mov eax, SyscallId +mov edx, KUSER_SHARED_SYSCALL +call dword ptr [edx] +ret StackBytes +ENDM +MACRO(STUBCODE_K, Name, SyscallId, ArgCount) +StackBytes = 4 * ArgCount +FPO 0, 0, 0, 0, 0, FRAME_FPO +mov eax, SyscallId +lea edx, [esp + 4] +pushfd +push KGDT_R0_CODE +call _KiSystemService +ret StackBytes +ENDM +#elif defined(_M_AMD64) +MACRO(STUBCODE_U, Name, SyscallId
Re: [ros-dev] [ros-diffs] [pschweitzer] 65501: [FASTFAT] Set clean shutdown bit on dismount
Hey Pierre!
This flag
+if (DeviceExt-VolumeFcb-Flags VCB_CLEAR_DIRTY)
+{
+/* Set clean shutdown bit */
+Status = GetNextCluster(DeviceExt, 1, eocMark);
+if (NT_SUCCESS(Status))
+{
+eocMark |= DeviceExt-CleanShutBitMask;
+if (NT_SUCCESS(WriteCluster(DeviceExt, 1, eocMark)))
and that one
+DeviceExt-VolumeFcb-Flags = ~VCB_IS_DIRTY;
+}
+}
+
/* Flush volume files */
VfatFlushVolume(DeviceExt, (PVFATFCB)FileObject-FsContext);
don't really seem to match. Or is the former a part of a OR combination
defining the latter ?
Cheers.
Jérôme.
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 64911: [USER32] - Fix LookupIconIdFromDirectoryEx, returning 0 when no matching entry is found. - Fix error handling when opening a cursor file. - Various code beau
Of course. Le 23/10/2014 14:22, Thomas Faber a écrit : On 2014-10-23 11:32, jgar...@svn.reactos.org wrote: -if ( dwFileSize (sizeof(*dir) + sizeof(dir-idEntries[0])*(dir-idCount-1)) ) +if (dwFileSize (sizeof(*dir) + FIELD_OFFSET(CURSORICONFILEDIR, idEntries[dir-idCount]))) Did you mean to remove the sizeof(*dir)? ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [hbelusca] 64747: [NTVDM]: Zero-fill memory with RtlZeroMemory (that exists also in NT mode), and use sizeof(object) instead of sizeof(type_of_object).
RtlZeroMemory(ptr, sizeof(ptr)) is almost always a bug ;-)
Le 16/10/2014 12:19, Hermès BÉLUSCA - MAÏTO a écrit :
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Timo Kreuzer
Envoyé : mercredi 15 octobre 2014 21:11
À : ros-dev@reactos.org
Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 64747: [NTVDM]: Zero-fill
memory with RtlZeroMemory (that exists also in NT mode), and use
sizeof(object) instead of sizeof(type_of_object).
Looks like bugs
Can you develop your point?
Am 15.10.2014 00:46, schrieb hbelu...@svn.reactos.org:
Author: hbelusca
Date: Tue Oct 14 22:46:40 2014
New Revision: 64747
URL: http://svn.reactos.org/svn/reactos?rev=64747view=rev
Log:
[NTVDM]: Zero-fill memory with RtlZeroMemory (that exists also in NT
mode), and use sizeof(object) instead of sizeof(type_of_object).
/* Clear the current directory buffer */
-ZeroMemory(CurrentDirectories, sizeof(CurrentDirectories));
+RtlZeroMemory(CurrentDirectories, sizeof(CurrentDirectories));
@@ -2901,7 +2901,7 @@
WCHAR Buffer[256];
/* Clear the current directory buffer */
-ZeroMemory(CurrentDirectories, sizeof(CurrentDirectories));
+RtlZeroMemory(CurrentDirectories, sizeof(CurrentDirectories));
@@ -1901,7 +1901,7 @@
VOID VgaClearMemory(VOID)
{
-ZeroMemory(VgaMemory, sizeof(VgaMemory));
+RtlZeroMemory(VgaMemory, sizeof(VgaMemory));
}
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 64311: [WIN32K] - Simplify IntRemoveWindowProp - Complain loudly if a NULL list entry sneaks into a window property list. CORE-8562
Uh oh, seems like I screwed up these two.
The spec2def part of this commit should indeed belong to r64312.
Le 26/09/2014 14:43, jgar...@svn.reactos.org a écrit :
Author: jgardou
Date: Fri Sep 26 12:43:12 2014
New Revision: 64311
URL: http://svn.reactos.org/svn/reactos?rev=64311view=rev
Log:
[WIN32K]
- Simplify IntRemoveWindowProp
- Complain loudly if a NULL list entry sneaks into a window property list.
CORE-8562
Modified:
trunk/reactos/tools/spec2def/spec2def.c
trunk/reactos/win32ss/user/ntuser/prop.c
Modified: trunk/reactos/tools/spec2def/spec2def.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/tools/spec2def/spec2def.c?rev=64311r1=64310r2=64311view=diff
==
--- trunk/reactos/tools/spec2def/spec2def.c [iso-8859-1] (original)
+++ trunk/reactos/tools/spec2def/spec2def.c [iso-8859-1] Fri Sep 26
12:43:12 2014
@@ -38,6 +38,7 @@
typedef int (*PFNOUTLINE)(FILE *, EXPORT *);
int gbMSComp = 0;
int gbImportLib = 0;
+int gbTracing = 0;
int giArch = ARCH_X86;
char *pszArchString = i386;
char *pszArchString2;
@@ -52,6 +53,9 @@
FL_STUB = 2,
FL_NONAME = 4,
FL_ORDINAL = 8,
+FL_NORELAY = 16,
+FL_RET64 = 32,
+FL_REGISTER = 64,
};
enum
@@ -161,52 +165,126 @@
OutputHeader_stub(FILE *file)
{
fprintf(file, /* This file is autogenerated, do not edit. */\n\n
-#include stubs.h\n\n);
+#include stubs.h\n);
+
+if (gbTracing)
+{
+fprintf(file, #include wine/debug.h\n);
+fprintf(file, #include inttypes.h\n);
+fprintf(file, WINE_DECLARE_DEBUG_CHANNEL(relay);\n);
+}
+
+fprintf(file, \n);
}
int
OutputLine_stub(FILE *file, EXPORT *pexp)
{
int i;
+int bRelay = 0;
+int bInPrototype;
if (pexp-nCallingConvention != CC_STUB
-(pexp-uFlags FL_STUB) == 0) return 0;
-
-fprintf(file, int );
-if ((giArch == ARCH_X86)
-pexp-nCallingConvention == CC_STDCALL)
-{
-fprintf(file, __stdcall );
-}
-
-/* Check for C++ */
-if (pexp-strName.buf[0] == '?')
-{
-fprintf(file, stub_function%d(, pexp-nNumber);
+(pexp-uFlags FL_STUB) == 0)
+{
+/* Only relay trace stdcall C functions */
+if (!gbTracing || (pexp-nCallingConvention != CC_STDCALL)
+|| (pexp-uFlags FL_NORELAY)
+|| (pexp-strName.buf[0] == '?'))
+{
+return 0;
+}
+bRelay = 1;
+}
+
+/* Declare the real function */
+if (bRelay)
+{
+fprintf(file, extern );
+bInPrototype = 1;
+}
+
+do
+{
+if (pexp-uFlags FL_REGISTER)
+{
+/* FIXME: Not sure this is right */
+fprintf(file, void );
+}
+else if (pexp-uFlags FL_RET64)
+{
+fprintf(file, __int64 );
+}
+else
+{
+fprintf(file, int );
+}
+
+if ((giArch == ARCH_X86)
+pexp-nCallingConvention == CC_STDCALL)
+{
+fprintf(file, __stdcall );
+}
+
+/* Check for C++ */
+if (pexp-strName.buf[0] == '?')
+{
+fprintf(file, stub_function%d(, pexp-nNumber);
+}
+else
+{
+if (!bRelay || bInPrototype)
+fprintf(file, %.*s(, pexp-strName.len, pexp-strName.buf);
+else
+fprintf(file, $relaytrace$%.*s(, pexp-strName.len,
pexp-strName.buf);
+}
+
+for (i = 0; i pexp-nArgCount; i++)
+{
+if (i != 0) fprintf(file, , );
+switch (pexp-anArgs[i])
+{
+case ARG_LONG: fprintf(file, long); break;
+case ARG_PTR: fprintf(file, void*); break;
+case ARG_STR: fprintf(file, char*); break;
+case ARG_WSTR: fprintf(file, wchar_t*); break;
+case ARG_DBL: fprintf(file, double); break;
+case ARG_INT64 : fprintf(file, __int64); break;
+case ARG_INT128 : fprintf(file, __int128); break;
+case ARG_FLOAT: fprintf(file, float); break;
+}
+fprintf(file, a%d, i);
+}
+
+if (bInPrototype)
+{
+fprintf(file, );\n\n);
+}
+} while (bInPrototype--);
+
+if (!bRelay)
+{
+fprintf(file, )\n{\n\tDbgPrint(\WARNING: calling stub %.*s(,
+pexp-strName.len, pexp-strName.buf);
}
else
{
-fprintf(file, %.*s(, pexp-strName.len, pexp-strName.buf);
-}
-
-for (i = 0; i pexp-nArgCount; i++)
-{
-if (i != 0) fprintf(file, , );
-switch (pexp-anArgs[i])
-{
-case ARG_LONG: fprintf(file, long); break;
-case ARG_PTR: fprintf(file, void*); break;
-case ARG_STR: fprintf(file, char*); break;
-case ARG_WSTR:
Re: [ros-dev] [ros-diffs] [jgardou] 64176: [GDI32] - Fix up values got from win32k in GetOutlineTextMetrics and do not fail if the provided buffersize is only sizeof(OUTLINETEXTMETRICW). CORE-8507 #re
Le 17/09/2014 21:32, Timo Kreuzer a écrit :
Am 17.09.2014 11:54, schrieb jgar...@svn.reactos.org:
Author: jgardou
Date: Wed Sep 17 09:54:14 2014
New Revision: 64176
URL: http://svn.reactos.org/svn/reactos?rev=64176view=rev
Log:
[GDI32]
- Fix up values got from win32k in GetOutlineTextMetrics and do not fail if
the provided buffersize is only sizeof(OUTLINETEXTMETRICW).
CORE-8507 #resolve
Modified:
trunk/reactos/win32ss/gdi/gdi32/objects/font.c
Modified: trunk/reactos/win32ss/gdi/gdi32/objects/font.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/gdi32/objects/font.c?rev=64176r1=64175r2=64176view=diff
==
--- trunk/reactos/win32ss/gdi/gdi32/objects/font.c [iso-8859-1] (original)
+++ trunk/reactos/win32ss/gdi/gdi32/objects/font.c [iso-8859-1] Wed Sep 17
09:54:14 2014
@@ -9,8 +9,19 @@
#include precomp.h
+#include math.h
+
#define NDEBUG
#include debug.h
+
+/* Rounds a floating point number to integer. The world-to-viewport
+ * transformation process is done in floating point internally. This function
+ * is then used to round these coordinates to integer values.
+ */
+static __inline INT GDI_ROUND(FLOAT val)
+{
+ return (int)floor(val + 0.5);
+}
roundf() is the appropriate function here. The older MS crt headers
don't have the *round*() functions, but VS 2013 headers seem to have
them (according MSDN).
I propose adding them inside some #ifdef, instead of reimplementing them
in different places.
Hmm, why not, but we don't use msvcr120.dll.
For the other functions: strange coding style. Is this taken from wine?
Yes, I thought I added the copyright notice, obviously forgot to do so.
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [akhaldi] 64151: [XDK][DDK] * Handle the rest of cases about the order of pragma and symbol declaration.
This breaks KDGDB compilation (and most probable KDCOM too if one would want to compile it using GCC) drivers/base/kdgdb/gdb_send.c:77: référence indéfinie vers « __imp__KdDebuggerNotPresent » Le 14/09/2014 17:49, akha...@svn.reactos.org a écrit : Author: akhaldi Date: Sun Sep 14 15:49:35 2014 New Revision: 64151 URL: http://svn.reactos.org/svn/reactos?rev=64151view=rev Log: [XDK][DDK] * Handle the rest of cases about the order of pragma and symbol declaration. Modified: trunk/reactos/include/ddk/ntddk.h trunk/reactos/include/ddk/ntifs.h trunk/reactos/include/ddk/wdm.h trunk/reactos/include/xdk/fsrtlfuncs.h trunk/reactos/include/xdk/haltypes.h trunk/reactos/include/xdk/kdfuncs.h trunk/reactos/include/xdk/ketypes.h trunk/reactos/include/xdk/mmtypes.h trunk/reactos/include/xdk/ntifs.template.h Modified: trunk/reactos/include/ddk/ntddk.h URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/ddk/ntddk.h?rev=64151r1=64150r2=64151view=diff == --- trunk/reactos/include/ddk/ntddk.h [iso-8859-1] (original) +++ trunk/reactos/include/ddk/ntddk.h [iso-8859-1] Sun Sep 14 15:49:35 2014 @@ -1670,8 +1670,8 @@ extern HAL_DISPATCH HalDispatchTable; #define HALDISPATCH (HalDispatchTable) #else +__CREATE_NTOS_DATA_IMPORT_ALIAS(HalDispatchTable) extern PHAL_DISPATCH HalDispatchTable; -__CREATE_NTOS_DATA_IMPORT_ALIAS(HalDispatchTable) #define HALDISPATCH HalDispatchTable #endif Modified: trunk/reactos/include/ddk/ntifs.h URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/ddk/ntifs.h?rev=64151r1=64150r2=64151view=diff == --- trunk/reactos/include/ddk/ntifs.h [iso-8859-1] (original) +++ trunk/reactos/include/ddk/ntifs.h [iso-8859-1] Sun Sep 14 15:49:35 2014 @@ -8396,8 +8396,8 @@ extern const UCHAR * const FsRtlLegalAnsiCharacterArray; #define LEGAL_ANSI_CHARACTER_ARRAY FsRtlLegalAnsiCharacterArray #else +__CREATE_NTOS_DATA_IMPORT_ALIAS(FsRtlLegalAnsiCharacterArray) extern const UCHAR * const *FsRtlLegalAnsiCharacterArray; -__CREATE_NTOS_DATA_IMPORT_ALIAS(FsRtlLegalAnsiCharacterArray) #define LEGAL_ANSI_CHARACTER_ARRAY (*FsRtlLegalAnsiCharacterArray) #endif @@ -10993,8 +10993,8 @@ extern PUSHORT NlsOemLeadByteInfo; #define NLS_OEM_LEAD_BYTE_INFO NlsOemLeadByteInfo #else +__CREATE_NTOS_DATA_IMPORT_ALIAS(NlsOemLeadByteInfo) extern PUSHORT *NlsOemLeadByteInfo; -__CREATE_NTOS_DATA_IMPORT_ALIAS(NlsOemLeadByteInfo) #define NLS_OEM_LEAD_BYTE_INFO (*NlsOemLeadByteInfo) #endif Modified: trunk/reactos/include/ddk/wdm.h URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/ddk/wdm.h?rev=64151r1=64150r2=64151view=diff == --- trunk/reactos/include/ddk/wdm.h [iso-8859-1] (original) +++ trunk/reactos/include/ddk/wdm.h [iso-8859-1] Sun Sep 14 15:49:35 2014 @@ -1661,8 +1661,8 @@ #elif (NTDDI_VERSION = NTDDI_WINXP) extern NTSYSAPI CCHAR KeNumberProcessors; #else +__CREATE_NTOS_DATA_IMPORT_ALIAS(KeNumberProcessors) extern PCCHAR KeNumberProcessors; -__CREATE_NTOS_DATA_IMPORT_ALIAS(KeNumberProcessors) #endif @@ -1815,8 +1815,8 @@ } MM_SYSTEMSIZE; #ifndef _NTSYSTEM_ +__CREATE_NTOS_DATA_IMPORT_ALIAS(Mm64BitPhysicalAddress) extern PBOOLEAN Mm64BitPhysicalAddress; -__CREATE_NTOS_DATA_IMPORT_ALIAS(Mm64BitPhysicalAddress) #endif extern NTKERNELAPI PVOID MmBadPointer; Modified: trunk/reactos/include/xdk/fsrtlfuncs.h URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/xdk/fsrtlfuncs.h?rev=64151r1=64150r2=64151view=diff == --- trunk/reactos/include/xdk/fsrtlfuncs.h [iso-8859-1] (original) +++ trunk/reactos/include/xdk/fsrtlfuncs.h [iso-8859-1] Sun Sep 14 15:49:35 2014 @@ -1584,8 +1584,8 @@ extern const UCHAR * const FsRtlLegalAnsiCharacterArray; #define LEGAL_ANSI_CHARACTER_ARRAY FsRtlLegalAnsiCharacterArray #else +__CREATE_NTOS_DATA_IMPORT_ALIAS(FsRtlLegalAnsiCharacterArray) extern const UCHAR * const *FsRtlLegalAnsiCharacterArray; -__CREATE_NTOS_DATA_IMPORT_ALIAS(FsRtlLegalAnsiCharacterArray) #define LEGAL_ANSI_CHARACTER_ARRAY (*FsRtlLegalAnsiCharacterArray) #endif Modified: trunk/reactos/include/xdk/haltypes.h URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/xdk/haltypes.h?rev=64151r1=64150r2=64151view=diff == --- trunk/reactos/include/xdk/haltypes.h[iso-8859-1] (original) +++ trunk/reactos/include/xdk/haltypes.h[iso-8859-1] Sun Sep 14 15:49:35 2014 @@ -273,8 +273,8 @@ extern HAL_DISPATCH HalDispatchTable; #define HALDISPATCH (HalDispatchTable) #else +__CREATE_NTOS_DATA_IMPORT_ALIAS(HalDispatchTable) extern PHAL_DISPATCH
Re: [ros-dev] [ros-diffs] [jgardou] 64121: [KDGDB] - introduce KDGDB, a KDCOM-like DLL, wrapping the KD protocol and the GDB remote protocol together. It is not fully functional, but for now it permit
Sure, I created https://jira.reactos.org/browse/CORE-8531 I agree it's the way to go, I just still didn't get the reflex to it. Regards Jérôme Le 13/09/2014 17:03, Aleksey Bragin a écrit : I don't remember who was opposing idea of Jira-based changelogs, but IMO it's the way to go. Saves lots of time for the changelog writer, and makes sure no important stuff is missed. Regards, Aleksey On 13.09.2014 3:27, Timo Kreuzer wrote: Oh and btw: I think the targeted way of handling change logs is using jira tasks, therefore it might be worth creating a jira task for it and closing it, once you're done with your work, so that it gets the appropriate consideration in the changelog. I suggest doing that for everything that is worth mentioning in the changelog. Am 12.09.2014 23:28, schrieb Jérôme Gardou: I guess so, I didn't try. But feel free to do! :-p Regards Jérôme Le 12/09/2014 23:25, Aleksey Bragin a écrit : Absolutely great stuff! And does it work in Windows? :-) (not that there is so much demand in that, just for fun) Regards, Aleksey On 12.09.2014 19:35, Pierre Schweitzer wrote: Awesome, indeed! Any info or tuto about how to use it? About how to plug GDB to it? Cheers, On 09/12/2014 12:57 AM, Timo Kreuzer wrote: Awesome stuff! Am 11.09.2014 22:55, schrieb jgar...@svn.reactos.org: Author: jgardou Date: Thu Sep 11 20:55:42 2014 New Revision: 64121 URL: http://svn.reactos.org/svn/reactos?rev=64121view=rev Log: [KDGDB] - introduce KDGDB, a KDCOM-like DLL, wrapping the KD protocol and the GDB remote protocol together. It is not fully functional, but for now it permits source-level debugging in some modules. More will be added as I feel the need and find the time to work a bit more on it. (That is, unless an angel comes and resume the work) To use it, set GDB and _WINKD_ to TRUE in your CMakeCache.txt. Using separate debug symbols is also a good idea. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 64121: [KDGDB] - introduce KDGDB, a KDCOM-like DLL, wrapping the KD protocol and the GDB remote protocol together. It is not fully functional, but for now it permit
Sure, I will write one as soon as it is functional, but to make it short, it is as simple as launching gdb and using target remote your_com_port On ReactOS side, /DEBUGPORT=COMx and you're ready to go. Enjoy Jérôme Le 12/09/2014 17:35, Pierre Schweitzer a écrit : Awesome, indeed! Any info or tuto about how to use it? About how to plug GDB to it? Cheers, On 09/12/2014 12:57 AM, Timo Kreuzer wrote: Awesome stuff! Am 11.09.2014 22:55, schrieb jgar...@svn.reactos.org: Author: jgardou Date: Thu Sep 11 20:55:42 2014 New Revision: 64121 URL: http://svn.reactos.org/svn/reactos?rev=64121view=rev Log: [KDGDB] - introduce KDGDB, a KDCOM-like DLL, wrapping the KD protocol and the GDB remote protocol together. It is not fully functional, but for now it permits source-level debugging in some modules. More will be added as I feel the need and find the time to work a bit more on it. (That is, unless an angel comes and resume the work) To use it, set GDB and _WINKD_ to TRUE in your CMakeCache.txt. Using separate debug symbols is also a good idea. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 64121: [KDGDB] - introduce KDGDB, a KDCOM-like DLL, wrapping the KD protocol and the GDB remote protocol together. It is not fully functional, but for now it permit
I thought about that, but considering the fact that using windbg for a GCC compiled OS or GDB for a MSVC compiled OS makes little sense (although one could use that for mixed kernel+drivers setup), I decided to go the KDCOM way. I am open to good arguments for doing that another way though. Jérôme Le 12/09/2014 18:42, Hermès BÉLUSCA - MAÏTO a écrit : Ah and I forgot : Jérôme, now you can use /DEBUGPORT=foo to load KDfoo.DLL ;) Then your KDfoo.DLL can implement a simple line parser in order to interpret any other hypothetical parameters present in the bootloader command line (some other KDxxx use that, for example KD1394 or KDUSB iirc.). One can imagine something like: /DEBUGPORT=GDB:COM1 to say: “Load KDGDB.DLL and use COM1 for it”. Currently it’s not what you did, maybe it would be great to have that? (and using /DEBUGPORT=COM1 just for loading KDCOM.DLL, the KD layer for WinDbg ?) Hermès. *De :*Ros-dev [mailto:ros-dev-boun...@reactos.org] *De la part de* Jérôme Gardou *Envoyé :* vendredi 12 septembre 2014 18:20 *À :* ros-dev@reactos.org *Objet :* Re: [ros-dev] [ros-diffs] [jgardou] 64121: [KDGDB] - introduce KDGDB, a KDCOM-like DLL, wrapping the KD protocol and the GDB remote protocol together. It is not fully functional, but for now it permits source-level debuggin... Sure, I will write one as soon as it is functional, but to make it short, it is as simple as launching gdb and using target remote your_com_port On ReactOS side, /DEBUGPORT=COMx and you're ready to go. Enjoy Jérôme Le 12/09/2014 17:35, Pierre Schweitzer a écrit : Awesome, indeed! Any info or tuto about how to use it? About how to plug GDB to it? Cheers, On 09/12/2014 12:57 AM, Timo Kreuzer wrote: Awesome stuff! Am 11.09.2014 22:55, schriebjgar...@svn.reactos.org mailto:jgar...@svn.reactos.org: Author: jgardou Date: Thu Sep 11 20:55:42 2014 New Revision: 64121 URL:http://svn.reactos.org/svn/reactos?rev=64121view=rev Log: [KDGDB] - introduce KDGDB, a KDCOM-like DLL, wrapping the KD protocol and the GDB remote protocol together. It is not fully functional, but for now it permits source-level debugging in some modules. More will be added as I feel the need and find the time to work a bit more on it. (That is, unless an angel comes and resume the work) To use it, set GDB and _WINKD_ to TRUE in your CMakeCache.txt. Using separate debug symbols is also a good idea. ___ Ros-dev mailing list Ros-dev@reactos.org mailto:Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org mailto:Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 64121: [KDGDB] - introduce KDGDB, a KDCOM-like DLL, wrapping the KD protocol and the GDB remote protocol together. It is not fully functional, but for now it permit
This will go away eventually. Le 12/09/2014 18:40, Hermès BÉLUSCA - MAÏTO a écrit : And what about this GDB stub there: trunk/reactos/ntoskrnl/kd/wrappers/ ? Do we still need it? Hermès. *De :*Ros-dev [mailto:ros-dev-boun...@reactos.org] *De la part de* Jérôme Gardou *Envoyé :* vendredi 12 septembre 2014 18:20 *À :* ros-dev@reactos.org *Objet :* Re: [ros-dev] [ros-diffs] [jgardou] 64121: [KDGDB] - introduce KDGDB, a KDCOM-like DLL, wrapping the KD protocol and the GDB remote protocol together. It is not fully functional, but for now it permits source-level debuggin... Sure, I will write one as soon as it is functional, but to make it short, it is as simple as launching gdb and using target remote your_com_port On ReactOS side, /DEBUGPORT=COMx and you're ready to go. Enjoy Jérôme Le 12/09/2014 17:35, Pierre Schweitzer a écrit : Awesome, indeed! Any info or tuto about how to use it? About how to plug GDB to it? Cheers, On 09/12/2014 12:57 AM, Timo Kreuzer wrote: Awesome stuff! Am 11.09.2014 22:55, schriebjgar...@svn.reactos.org mailto:jgar...@svn.reactos.org: Author: jgardou Date: Thu Sep 11 20:55:42 2014 New Revision: 64121 URL:http://svn.reactos.org/svn/reactos?rev=64121view=rev Log: [KDGDB] - introduce KDGDB, a KDCOM-like DLL, wrapping the KD protocol and the GDB remote protocol together. It is not fully functional, but for now it permits source-level debugging in some modules. More will be added as I feel the need and find the time to work a bit more on it. (That is, unless an angel comes and resume the work) To use it, set GDB and _WINKD_ to TRUE in your CMakeCache.txt. Using separate debug symbols is also a good idea. ___ Ros-dev mailing list Ros-dev@reactos.org mailto:Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org mailto:Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 64127: [KDGDB] - Add a callback mechanism permitting to simulate KD send - receive loop without having to actually communicate to GDB - Use that to update the p
Yeah you're not the first one to tell me that, and I wasn't really happy
to write it either.
I like your approach. I will try to do as you suggest.
Thanks
Jérôme
Le 12/09/2014 22:53, Timo Kreuzer a écrit :
while(1); is not really a good solution. It should be something that is
visible in GDB.
But I fear that a KeBugCheck() won't work here, since it will rely on a
working KD connection.
Maybe a KD_ASSERT() macro, that calls KdAssert() on failure or
something, resets the GDB connection somehow, issues a debug print and
then halts.
Am 12.09.2014 22:23, schrieb jgar...@svn.reactos.org:
Author: jgardou
Date: Fri Sep 12 20:23:08 2014
New Revision: 64127
URL: http://svn.reactos.org/svn/reactos?rev=64127view=rev
Log:
[KDGDB]
- Add a callback mechanism permitting to simulate KD send - receive loop
without having to actually communicate to GDB
- Use that to update the program counter when cont'ing a breakpoint
Now cont'ing an assertion failure is possible, since we actually get beyond the
int 3 instruction
Modified:
trunk/reactos/drivers/base/kdgdb/gdb_input.c
trunk/reactos/drivers/base/kdgdb/kdgdb.h
trunk/reactos/drivers/base/kdgdb/kdpacket.c
+)
+{
+DBGKD_MANIPULATE_STATE64* State =
(DBGKD_MANIPULATE_STATE64*)MessageHeader-Buffer;
+
+/* We just confirm that all went well */
+if ((PacketType != PACKET_TYPE_KD_STATE_MANIPULATE)
+|| (State-ApiNumber != DbgKdSetContextApi)
+|| (State-ReturnStatus != STATUS_SUCCESS))
+{
+/* Should we bugcheck ? */
+while (1);
+}
+}
+
+static
+KDSTATUS
+SetContext(
+_Out_ DBGKD_MANIPULATE_STATE64* State,
+_Out_ PSTRING MessageData,
+_Out_ PULONG MessageLength,
+_Inout_ PKD_CONTEXT KdContext,
+_In_opt_ KDP_MANIPULATESTATE_HANDLER ManipulateStateHandler
+)
+{
+State-ApiNumber = DbgKdSetContextApi;
+State-Processor = CurrentStateChange.Processor;
+State-ReturnStatus = STATUS_SUCCESS;
+State-ProcessorLevel = CurrentStateChange.ProcessorLevel;
+MessageData-Length = sizeof(CurrentContext);
+
+if (MessageData-MaximumLength sizeof(CurrentContext))
+{
+while (1);
+}
+
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 64121: [KDGDB] - introduce KDGDB, a KDCOM-like DLL, wrapping the KD protocol and the GDB remote protocol together. It is not fully functional, but for now it permit
I guess so, I didn't try. But feel free to do! :-p Regards Jérôme Le 12/09/2014 23:25, Aleksey Bragin a écrit : Absolutely great stuff! And does it work in Windows? :-) (not that there is so much demand in that, just for fun) Regards, Aleksey On 12.09.2014 19:35, Pierre Schweitzer wrote: Awesome, indeed! Any info or tuto about how to use it? About how to plug GDB to it? Cheers, On 09/12/2014 12:57 AM, Timo Kreuzer wrote: Awesome stuff! Am 11.09.2014 22:55, schrieb jgar...@svn.reactos.org: Author: jgardou Date: Thu Sep 11 20:55:42 2014 New Revision: 64121 URL: http://svn.reactos.org/svn/reactos?rev=64121view=rev Log: [KDGDB] - introduce KDGDB, a KDCOM-like DLL, wrapping the KD protocol and the GDB remote protocol together. It is not fully functional, but for now it permits source-level debugging in some modules. More will be added as I feel the need and find the time to work a bit more on it. (That is, unless an angel comes and resume the work) To use it, set GDB and _WINKD_ to TRUE in your CMakeCache.txt. Using separate debug symbols is also a good idea. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [akhaldi] 64094: [CMAKE/CLANG] * Globally link mingwex for C modules. CORE-8516
Hey Amine
Is there any reason to not use our own mingwex build ?
Le 09/09/2014 20:11, akha...@svn.reactos.org a écrit :
Author: akhaldi
Date: Tue Sep 9 18:11:10 2014
New Revision: 64094
URL: http://svn.reactos.org/svn/reactos?rev=64094view=rev
Log:
[CMAKE/CLANG]
* Globally link mingwex for C modules.
CORE-8516
Modified:
trunk/reactos/toolchain-clang.cmake
Modified: trunk/reactos/toolchain-clang.cmake
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/toolchain-clang.cmake?rev=64094r1=64093r2=64094view=diff
==
--- trunk/reactos/toolchain-clang.cmake [iso-8859-1] (original)
+++ trunk/reactos/toolchain-clang.cmake [iso-8859-1] Tue Sep 9 18:11:10 2014
@@ -56,7 +56,7 @@
set(CMAKE_ASM_CREATE_STATIC_LIBRARY ${CMAKE_C_CREATE_STATIC_LIBRARY})
# Don't link with anything by default unless we say so
-set(CMAKE_C_STANDARD_LIBRARIES -lgcc CACHE STRING Standard C Libraries)
+set(CMAKE_C_STANDARD_LIBRARIES -lmingwex -lgcc CACHE STRING Standard C
Libraries)
#MARK_AS_ADVANCED(CLEAR CMAKE_CXX_STANDARD_LIBRARIES)
set(CMAKE_CXX_STANDARD_LIBRARIES -lgcc CACHE STRING Standard C++
Libraries)
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [tfaber] 63928: [FASTFAT] - Properly handle errors in CcInitializeCacheMap, CcCopyRead and CcCopyWrite CORE-8410
Hey Thomas
I think that you want to use _SEH2_YIELD in a few places here, that is,
unless we want to completely ditch pseh2 in favor of pseh3 ;-)
Regards
Jérôme
Le 24/08/2014 05:28, tfa...@svn.reactos.org a écrit :
Author: tfaber
Date: Sun Aug 24 03:28:01 2014
New Revision: 63928
URL: http://svn.reactos.org/svn/reactos?rev=63928view=rev
Log:
[FASTFAT]
- Properly handle errors in CcInitializeCacheMap, CcCopyRead and CcCopyWrite
CORE-8410
Modified:
trunk/reactos/drivers/filesystems/fastfat/CMakeLists.txt
trunk/reactos/drivers/filesystems/fastfat/fcb.c
trunk/reactos/drivers/filesystems/fastfat/fsctl.c
trunk/reactos/drivers/filesystems/fastfat/rw.c
trunk/reactos/drivers/filesystems/fastfat/vfat.h
Modified: trunk/reactos/drivers/filesystems/fastfat/CMakeLists.txt
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfat/CMakeLists.txt?rev=63928r1=63927r2=63928view=diff
==
--- trunk/reactos/drivers/filesystems/fastfat/CMakeLists.txt[iso-8859-1]
(original)
+++ trunk/reactos/drivers/filesystems/fastfat/CMakeLists.txt[iso-8859-1]
Sun Aug 24 03:28:01 2014
@@ -26,6 +26,7 @@
add_library(fastfat SHARED ${SOURCE} vfatfs.rc)
set_module_type(fastfat kernelmodedriver)
+target_link_libraries(fastfat ${PSEH_LIB})
add_importlibs(fastfat ntoskrnl hal)
add_pch(fastfat vfat.h SOURCE)
Modified: trunk/reactos/drivers/filesystems/fastfat/fcb.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfat/fcb.c?rev=63928r1=63927r2=63928view=diff
==
--- trunk/reactos/drivers/filesystems/fastfat/fcb.c [iso-8859-1] (original)
+++ trunk/reactos/drivers/filesystems/fastfat/fcb.c [iso-8859-1] Sun Aug 24
03:28:01 2014
@@ -340,12 +340,14 @@
{
PFILE_OBJECT fileObject;
PVFATCCB newCCB;
+NTSTATUS status;
fileObject = IoCreateStreamFileObject (NULL, vcb-StorageDevice);
newCCB = ExAllocateFromNPagedLookasideList(VfatGlobalData-CcbLookasideList);
if (newCCB == NULL)
{
+ObDereferenceObject(fileObject);
return STATUS_INSUFFICIENT_RESOURCES;
}
RtlZeroMemory(newCCB, sizeof (VFATCCB));
@@ -356,11 +358,24 @@
fcb-FileObject = fileObject;
fcb-RefCount++;
-CcInitializeCacheMap(fileObject,
- (PCC_FILE_SIZES)(fcb-RFCB.AllocationSize),
- TRUE,
- VfatGlobalData-CacheMgrCallbacks,
- fcb);
+_SEH2_TRY
+{
+CcInitializeCacheMap(fileObject,
+ (PCC_FILE_SIZES)(fcb-RFCB.AllocationSize),
+ TRUE,
+ VfatGlobalData-CacheMgrCallbacks,
+ fcb);
+}
+_SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER)
+{
+status = _SEH2_GetExceptionCode();
+fcb-RefCount--;
+fcb-FileObject = NULL;
+ExFreeToNPagedLookasideList(VfatGlobalData-CcbLookasideList, newCCB);
+ObDereferenceObject(fileObject);
+return status;
+}
+_SEH2_END;
fcb-Flags |= FCB_CACHE_INITIALIZED;
return STATUS_SUCCESS;
Modified: trunk/reactos/drivers/filesystems/fastfat/fsctl.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfat/fsctl.c?rev=63928r1=63927r2=63928view=diff
==
--- trunk/reactos/drivers/filesystems/fastfat/fsctl.c [iso-8859-1] (original)
+++ trunk/reactos/drivers/filesystems/fastfat/fsctl.c [iso-8859-1] Sun Aug 24
03:28:01 2014
@@ -550,11 +550,20 @@
Fcb-RFCB.ValidDataLength = Fcb-RFCB.FileSize;
Fcb-RFCB.AllocationSize = Fcb-RFCB.FileSize;
-CcInitializeCacheMap(DeviceExt-FATFileObject,
- (PCC_FILE_SIZES)(Fcb-RFCB.AllocationSize),
- TRUE,
- VfatGlobalData-CacheMgrCallbacks,
- Fcb);
+_SEH2_TRY
+{
+CcInitializeCacheMap(DeviceExt-FATFileObject,
+ (PCC_FILE_SIZES)(Fcb-RFCB.AllocationSize),
+ TRUE,
+ VfatGlobalData-CacheMgrCallbacks,
+ Fcb);
+}
+_SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER)
+{
+Status = _SEH2_GetExceptionCode();
+goto ByeBye;
+}
+_SEH2_END;
DeviceExt-LastAvailableCluster = 2;
ExInitializeResourceLite(DeviceExt-FatResource);
Modified: trunk/reactos/drivers/filesystems/fastfat/rw.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfat/rw.c?rev=63928r1=63927r2=63928view=diff
==
--- trunk/reactos/drivers/filesystems/fastfat/rw.c [iso-8859-1]
Re: [ros-dev] [ros-diffs] [pschweitzer] 62442: [NTOSKRNL] - Implement FsRtlNotifyFilterReportChange - Implement FsRtlNotifyUpdateBuffer - Implement FsRtlCancelNotify - Implement FsRtlNotifyGetLastPart
Awesomeness, in its purest art.
Le 07.03.2014 20:33, pschweit...@svn.reactos.org a écrit :
Author: pschweitzer
Date: Fri Mar 7 19:33:38 2014
New Revision: 62442
URL: http://svn.reactos.org/svn/reactos?rev=62442view=rev
Log:
[NTOSKRNL]
- Implement FsRtlNotifyFilterReportChange
- Implement FsRtlNotifyUpdateBuffer
- Implement FsRtlCancelNotify
- Implement FsRtlNotifyGetLastPartOffset
- Fix implementation of FsRtlNotifyFilterChangeDirectory
This finishes the implementation of file system notifications inside the kernel.
Data are properly returned to the caller on changes.
CORE-2582
Modified:
trunk/reactos/ntoskrnl/fsrtl/notify.c
trunk/reactos/ntoskrnl/include/internal/fsrtl.h
Modified: trunk/reactos/ntoskrnl/fsrtl/notify.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/fsrtl/notify.c?rev=62442r1=62441r2=62442view=diff
==
--- trunk/reactos/ntoskrnl/fsrtl/notify.c [iso-8859-1] (original)
+++ trunk/reactos/ntoskrnl/fsrtl/notify.c [iso-8859-1] Fri Mar 7
19:33:38 2014
@@ -12,6 +12,55 @@
#define NDEBUG
#include debug.h
+/* INLINED FUNCTIONS */
+
+/*
+ * @implemented
+ */
+FORCEINLINE
+VOID
+FsRtlNotifyAcquireFastMutex(IN PREAL_NOTIFY_SYNC RealNotifySync)
+{
+ULONG_PTR CurrentThread = (ULONG_PTR)KeGetCurrentThread();
+
+/* Only acquire fast mutex if it's not already acquired by the current
thread */
+if (RealNotifySync-OwningThread != CurrentThread)
+{
+ExAcquireFastMutexUnsafe((RealNotifySync-FastMutex));
+RealNotifySync-OwningThread = CurrentThread;
+}
+/* Whatever the case, keep trace of the attempt to acquire fast mutex */
+RealNotifySync-OwnerCount++;
+}
+
+/*
+ * @implemented
+ */
+FORCEINLINE
+VOID
+FsRtlNotifyReleaseFastMutex(IN PREAL_NOTIFY_SYNC RealNotifySync)
+{
+RealNotifySync-OwnerCount--;
+/* Release the fast mutex only if no other instance needs it */
+if (!RealNotifySync-OwnerCount)
+{
+ExReleaseFastMutexUnsafe((RealNotifySync-FastMutex));
+RealNotifySync-OwningThread = (ULONG_PTR)0;
+}
+}
+
+#define FsRtlNotifyGetLastPartOffset(FullLen, TargLen, Type, Chr)
\
+for (FullPosition = 0; FullPosition FullLen; ++FullPosition)
\
+if (((Type)NotifyChange-FullDirectoryName-Buffer)[FullPosition] ==
Chr) \
+++FullNumberOfParts;
\
+for (LastPartOffset = 0; LastPartOffset TargLen; ++LastPartOffset) {
\
+if ( ((Type)TargetDirectory.Buffer)[LastPartOffset] == Chr) {
\
+++TargetNumberOfParts;
\
+if (TargetNumberOfParts == FullNumberOfParts)
\
+break;
\
+}
\
+}
+
/* PRIVATE FUNCTIONS
*/
VOID
@@ -22,13 +71,161 @@
FsRtlNotifySetCancelRoutine(IN PIRP Irp,
IN PNOTIFY_CHANGE NotifyChange OPTIONAL);
+/*
+ * @implemented
+ */
VOID
NTAPI
FsRtlCancelNotify(IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp)
{
+PVOID Buffer;
+PIRP NotifyIrp;
+ULONG BufferLength;
+PIO_STACK_LOCATION Stack;
+PNOTIFY_CHANGE NotifyChange;
+PREAL_NOTIFY_SYNC RealNotifySync;
+PSECURITY_SUBJECT_CONTEXT SubjectContext = NULL;
+
+/* Get the NOTIFY_CHANGE struct and reset it */
+NotifyChange = (PNOTIFY_CHANGE)Irp-IoStatus.Information;
+Irp-IoStatus.Information = 0;
+/* Reset the cancel routine */
+IoSetCancelRoutine(Irp, NULL);
+/* And release lock */
IoReleaseCancelSpinLock(Irp-CancelIrql);
-UNIMPLEMENTED;
+/* Get REAL_NOTIFY_SYNC struct */
+RealNotifySync = NotifyChange-NotifySync;
+
+FsRtlNotifyAcquireFastMutex(RealNotifySync);
+
+ _SEH2_TRY
+ {
+ /* Remove the IRP from the notifications list and mark it pending */
+ RemoveEntryList((Irp-Tail.Overlay.ListEntry));
+ IoMarkIrpPending(Irp);
+
+ /* Now, the tricky part - let's find a buffer big enough to hold the
return data */
+ if (NotifyChange-Buffer NotifyChange-AllocatedBuffer == NULL
+ ((Irp-MdlAddress MmGetSystemAddressForMdl(Irp-MdlAddress) ==
NotifyChange-Buffer) ||
+ NotifyChange-Buffer == Irp-AssociatedIrp.SystemBuffer))
+ {
+ /* Assume we didn't find any */
+ Buffer = NULL;
+ BufferLength = 0;
+
+ /* If we don't have IRPs, check if current buffer is big enough */
+ if (IsListEmpty(NotifyChange-NotifyIrps))
+ {
+ if (NotifyChange-BufferLength = NotifyChange-DataLength)
+ {
+
Re: [ros-dev] [ros-diffs] [aandrejevic] 60757: [SOFTX86] Remove softx86, as it is no longer used by anything.
Hello. Just nitpicking a bit: -target_link_libraries(ntvdm softx86 softx87 fast486) +target_link_libraries(ntvdm fast486) add_importlibs(ntvdm msvcrt user32 gdi32 kernel32 ntdll) -add_dependencies(ntvdm softx86 softx87) +add_dependencies(ntvdm fast486) The call to add_dependencies is useless here, as a call to target_link_libraries adds an implicit dependency. Regards Jérôme ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 59174: [WIN32K] - Don't crash if the focus m
It happened if explorer.exe get stopped for whatever reason (taskmgr) and there are no other window opened. Then press ctrl - alt -del = BSOD. To my understanding, this is valid for this variable is NULL, so checking it is necessary. Any comments ? Regards. Jérôme ReactOS Development List ros-dev@reactos.org wrote on mer., juin 5th, 2013, 11:30 : What application failed? Thanks, James ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [pschweitzer] 58960: [RTL] Finally reenable RtlAcquirePrivilege
Hey Pierre! Nice patch series, that takes ReactOS nearer to being secure. A remark though : /* - * enable the SeSystemtimePrivilege privilege + * Call SetLocalTime twice to ensure correct results */ +Ret = SetLocalTime(SetupData-SystemTime) + SetLocalTime(SetupData-SystemTime); This is a bit confusing, and the comment doesn't really help. Why would calling the function twice ansure correct result ? Also, this is likely to be optimized away by the compiler, or at least produce a report in static code analysers. I know this isn't pure chance. Any hint as to why you wrote it like this ? Cheers Jérôme ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [hbelusca] 58824: [KDCOM] - Use the UCHAR type directly instead
Hey Hermès ! + +long atol(const char *str); + Shouldn't this belong to some standard header ? Cheers Jérôme ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 58660: [MESA32] * Disable SSE optimizations, as they only cause mayhem.
It causes some kernel mode exception. The code deliberately throws an SSE exception to see if the OS supports them. The trap handler considers this as a k-mode exception and bug checks. See http://jira.reactos.org/browse/CORE-6776 Timo Kreuzer a écrit : What exactly does it cause? And shouldn't we rather fix that, instead of disabling optimizations? mesa is already slow enough. Am 03.04.2013 14:02, schrieb jgar...@svn.reactos.org: Author: jgardou Date: Wed Apr 3 12:02:58 2013 New Revision: 58660 URL: http://svn.reactos.org/svn/reactos?rev=58660view=rev Log: [MESA32] * Disable SSE optimizations, as they only cause mayhem. Modified: trunk/reactos/dll/opengl/mesa/src/mesa/CMakeLists.txt Modified: trunk/reactos/dll/opengl/mesa/src/mesa/CMakeLists.txt URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/opengl/mesa/src/mesa/CMakeLists.txt?rev=58660r1=58659r2=58660view=diff == --- trunk/reactos/dll/opengl/mesa/src/mesa/CMakeLists.txt [iso-8859-1] (original) +++ trunk/reactos/dll/opengl/mesa/src/mesa/CMakeLists.txt [iso-8859-1] Wed Apr 3 12:02:58 2013 @@ -33,17 +33,18 @@ x86/3dnow_xform3.S x86/3dnow_xform4.S x86/3dnow_normal.S -x86/sse_xform1.S -x86/sse_xform2.S -x86/sse_xform3.S -x86/sse_xform4.S -x86/sse_normal.S +# x86/sse_xform1.S +# x86/sse_xform2.S +# x86/sse_xform3.S +# x86/sse_xform4.S +# x86/sse_normal.S x86/read_rgba_span_x86.S) add_definitions( -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM --DUSE_SSE_ASM) +# -DUSE_SSE_ASM +) endif() list(APPEND SOURCE ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [tkreuzer] 58101: [WIN32K] Revert the revert from r58091 and apply a correct fix (passed parameters to RECTL_vSetRect() in wrong order)
Thank you for looking into this, I am not really available for coding in
reactos at the moment.
Greetings.
Jérôme
tkreu...@svn.reactos.org a écrit :
Author: tkreuzer
Date: Wed Jan 2 14:52:34 2013
New Revision: 58101
URL: http://svn.reactos.org/svn/reactos?rev=58101view=rev
Log:
[WIN32K]
Revert the revert from r58091 and apply a correct fix (passed parameters to
RECTL_vSetRect() in wrong order)
Modified:
trunk/reactos/win32ss/gdi/ntgdi/dib.h
trunk/reactos/win32ss/gdi/ntgdi/dibobj.c
trunk/reactos/win32ss/user/ntuser/clipboard.c
trunk/reactos/win32ss/user/ntuser/misc/file.c
Modified: trunk/reactos/win32ss/gdi/ntgdi/dib.h
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/dib.h?rev=58101r1=58100r2=58101view=diff
==
--- trunk/reactos/win32ss/gdi/ntgdi/dib.h [iso-8859-1] (original)
+++ trunk/reactos/win32ss/gdi/ntgdi/dib.h [iso-8859-1] Wed Jan 2 14:52:34 2013
@@ -7,8 +7,11 @@
INT APIENTRY DIB_GetDIBImageBytes (INT width, INT height, INT depth);
HPALETTE FASTCALL DIB_MapPaletteColors(PPALETTE ppal, CONST BITMAPINFO*
lpbmi);
HPALETTE FASTCALL BuildDIBPalette (CONST BITMAPINFO *bmi);
+
+/* Those functions permit to tranparently work with a BITMAPCOREINFO structure
*/
BITMAPINFO* FASTCALL DIB_ConvertBitmapInfo(CONST BITMAPINFO* bmi, DWORD
Usage);
-VOID FASTCALL DIB_FreeConvertedBitmapInfo(BITMAPINFO* converted, BITMAPINFO*
orig);
+/* Pass Usage = -1 if you don't want to convert the BITMAPINFO back to
BITMAPCOREINFO */
+VOID FASTCALL DIB_FreeConvertedBitmapInfo(BITMAPINFO* converted, BITMAPINFO*
orig, DWORD Usage);
INT
APIENTRY
Modified: trunk/reactos/win32ss/gdi/ntgdi/dibobj.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/dibobj.c?rev=58101r1=58100r2=58101view=diff
==
--- trunk/reactos/win32ss/gdi/ntgdi/dibobj.c [iso-8859-1] (original)
+++ trunk/reactos/win32ss/gdi/ntgdi/dibobj.c [iso-8859-1] Wed Jan 2 14:52:34
2013
@@ -584,7 +584,6 @@
DWORD compr, size ;
USHORT i;
int bitmap_type;
-RGBTRIPLE* rgbTriples;
RGBQUAD* rgbQuads;
VOID* colorPtr;
@@ -594,7 +593,6 @@
return 0;
colorPtr = (LPBYTE)Info + Info-bmiHeader.biSize;
-rgbTriples = colorPtr;
rgbQuads = colorPtr;
bitmap_type = DIB_GetBitmapInfo(Info-bmiHeader,
@@ -643,15 +641,6 @@
switch(bpp)
{
case 0: /* Only info */
-if(pbmci)
-{
-pbmci-bmciHeader.bcWidth = (WORD)psurf-SurfObj.sizlBitmap.cx;
-pbmci-bmciHeader.bcHeight = (WORD)((psurf-SurfObj.fjBitmap
BMF_TOPDOWN) ?
- -psurf-SurfObj.sizlBitmap.cy :
- psurf-SurfObj.sizlBitmap.cy);
-pbmci-bmciHeader.bcPlanes = 1;
-pbmci-bmciHeader.bcBitCount =
BitsPerFormat(psurf-SurfObj.iBitmapFormat);
-}
Info-bmiHeader.biWidth = psurf-SurfObj.sizlBitmap.cx;
Info-bmiHeader.biHeight = (psurf-SurfObj.fjBitmap BMF_TOPDOWN) ?
-psurf-SurfObj.sizlBitmap.cy :
@@ -702,16 +691,6 @@
if(Usage == DIB_RGB_COLORS)
{
ULONG colors = min(psurf-ppal-NumColors, 256);
-
-if(pbmci)
-{
-for(i = 0; i colors; i++)
-{
-rgbTriples[i].rgbtRed =
psurf-ppal-IndexedColors[i].peRed;
-rgbTriples[i].rgbtGreen =
psurf-ppal-IndexedColors[i].peGreen;
-rgbTriples[i].rgbtBlue =
psurf-ppal-IndexedColors[i].peBlue;
-}
-}
if(colors != 256) Info-bmiHeader.biClrUsed = colors;
for(i = 0; i colors; i++)
{
@@ -724,10 +703,7 @@
else
{
for(i = 0; i 256; i++)
-{
-if(pbmci) ((WORD*)rgbTriples)[i] = i;
((WORD*)rgbQuads)[i] = i;
-}
}
}
else
@@ -736,7 +712,6 @@
{
for(i = 0; i 256; i++)
{
-if(pbmci) ((WORD*)rgbTriples)[i] = i;
((WORD*)rgbQuads)[i] = i;
}
}
@@ -753,13 +728,6 @@
}
for (i = 0; i pDcPal-NumColors; i++)
{
-if (pbmci)
-{
-rgbTriples[i].rgbtRed =
pDcPal-IndexedColors[i].peRed;
-rgbTriples[i].rgbtGreen =
pDcPal-IndexedColors[i].peGreen;
-rgbTriples[i].rgbtBlue =
pDcPal-IndexedColors[i].peBlue;
-}
-
rgbQuads[i].rgbRed = pDcPal-IndexedColors[i].peRed;
Re: [ros-dev] [ros-diffs] [hbelusca] 58016: [MSVCRT] Export __crtLCMapStringW and correct __crtLCMapStringA: their prototypes are : int CDECL __crtLCMapStringW(LCID lcid, DWORD mapflags, const wchar_t
For input strings. I think that's not relevant to us anyway, as wine uses this for relay tracing, that we don't use nor have any implementation of. Jérôme. Hermès BÉLUSCA - MAÏTO a écrit : So why do 'str' and 'wstr' exist ? Hermès. -Message d'origine- De : ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] De la part de Jérôme Gardou Envoyé : vendredi 28 décembre 2012 00:17 À : ros-dev@reactos.org Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 58016: [MSVCRT] Export __crtLCMapStringW and correct __crtLCMapStringA: their prototypes are : int CDECL __crtLCMapStringW(LCID lcid, DWORD mapflags, const wchar_t *src, int srclen, wcha... I think that in the spec files semantics, destination strings are just buffers and should be considered as pointers. hbelu...@svn.reactos.org a écrit : Author: hbelusca Date: Wed Dec 26 19:26:08 2012 New Revision: 58016 URL: http://svn.reactos.org/svn/reactos?rev=58016view=rev Log: [MSVCRT] Export __crtLCMapStringW and correct __crtLCMapStringA: their prototypes are : int CDECL __crtLCMapStringW(LCID lcid, DWORD mapflags, const wchar_t *src, int srclen, wchar_t *dst, int dstlen, unsigned int codepage, int xflag) and int CDECL __crtLCMapStringA(LCID lcid, DWORD mapflags, const char* src, int srclen, char* dst, int dstlen, unsigned int codepage, int xflag) Needed by SVN. Modified: trunk/reactos/dll/win32/msvcrt/msvcrt.spec Modified: trunk/reactos/dll/win32/msvcrt/msvcrt.spec URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msvcrt/msvc rt.spec?rev=58016r1=58015r2=58016view=diff == --- trunk/reactos/dll/win32/msvcrt/msvcrt.spec [iso-8859-1] (original) +++ trunk/reactos/dll/win32/msvcrt/msvcrt.spec [iso-8859-1] Wed Dec 26 +++ 19:26:08 2012 @@ -143,8 +143,8 @@ @ cdecl __crtCompareStringW(long long wstr long wstr long) kernel32.CompareStringW @ cdecl __crtGetLocaleInfoW(long long ptr long) kernel32.GetLocaleInfoW @ cdecl __crtGetStringTypeW(long long wstr long ptr) -@ cdecl __crtLCMapStringA(long long str long ptr long long long) -# stub __crtLCMapStringW +@ cdecl __crtLCMapStringA(long long str long str long long long) @ +cdecl __crtLCMapStringW(long long wstr long wstr long long long) @ cdecl __daylight() __p__daylight @ cdecl __dllonexit(ptr ptr ptr) @ cdecl __doserrno() ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [hbelusca] 58016: [MSVCRT] Export __crtLCMapStringW and correct __crtLCMapStringA: their prototypes are : int CDECL __crtLCMapStringW(LCID lcid, DWORD mapflags, const wchar_t
I think that in the spec files semantics, destination strings are just buffers and should be considered as pointers. hbelu...@svn.reactos.org a écrit : Author: hbelusca Date: Wed Dec 26 19:26:08 2012 New Revision: 58016 URL: http://svn.reactos.org/svn/reactos?rev=58016view=rev Log: [MSVCRT] Export __crtLCMapStringW and correct __crtLCMapStringA: their prototypes are : int CDECL __crtLCMapStringW(LCID lcid, DWORD mapflags, const wchar_t *src, int srclen, wchar_t *dst, int dstlen, unsigned int codepage, int xflag) and int CDECL __crtLCMapStringA(LCID lcid, DWORD mapflags, const char* src, int srclen, char* dst, int dstlen, unsigned int codepage, int xflag) Needed by SVN. Modified: trunk/reactos/dll/win32/msvcrt/msvcrt.spec Modified: trunk/reactos/dll/win32/msvcrt/msvcrt.spec URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msvcrt/msvcrt.spec?rev=58016r1=58015r2=58016view=diff == --- trunk/reactos/dll/win32/msvcrt/msvcrt.spec [iso-8859-1] (original) +++ trunk/reactos/dll/win32/msvcrt/msvcrt.spec [iso-8859-1] Wed Dec 26 19:26:08 2012 @@ -143,8 +143,8 @@ @ cdecl __crtCompareStringW(long long wstr long wstr long) kernel32.CompareStringW @ cdecl __crtGetLocaleInfoW(long long ptr long) kernel32.GetLocaleInfoW @ cdecl __crtGetStringTypeW(long long wstr long ptr) -@ cdecl __crtLCMapStringA(long long str long ptr long long long) -# stub __crtLCMapStringW +@ cdecl __crtLCMapStringA(long long str long str long long long) +@ cdecl __crtLCMapStringW(long long wstr long wstr long long long) @ cdecl __daylight() __p__daylight @ cdecl __dllonexit(ptr ptr ptr) @ cdecl __doserrno() ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 57909: [INCLUDE/CRT] - _CRT_NON_CONFORMING_SWPRINTFS is not relevant for us.
Windows XP and windows 2k3 msvcrt.dll don't export _swprintf, making any test compiled with this define unusable on them and using swprintf unusable on this platforms. Also, from a pure testing point of view, we'd better test functions that we should export ;-) Le Fri, 14 Dec 2012 21:33:47 +0100, Timo Kreuzer timo.kreu...@web.de a écrit : The reason for this define is to allow swprintf etc., wich is then an alias for _swprintf, which we do implement. I don't see why this should be disabled. Am 13.12.2012 20:21, schrieb jgar...@svn.reactos.org: Author: jgardou Date: Thu Dec 13 19:21:30 2012 New Revision: 57909 URL: http://svn.reactos.org/svn/reactos?rev=57909view=rev Log: [INCLUDE/CRT] - _CRT_NON_CONFORMING_SWPRINTFS is not relevant for us. Modified: trunk/reactos/include/crt/stdio.h trunk/reactos/include/crt/wchar.h Modified: trunk/reactos/include/crt/stdio.h URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/crt/stdio.h?rev=57909r1=57908r2=57909view=diff == --- trunk/reactos/include/crt/stdio.h [iso-8859-1] (original) +++ trunk/reactos/include/crt/stdio.h [iso-8859-1] Thu Dec 13 19:21:30 2012 @@ -322,12 +322,14 @@ #include vadefs.h #endif +#if 0 //this is for MSVCRT80 and higher, which we don't use nor implement #ifdef _CRT_NON_CONFORMING_SWPRINTFS #ifndef __cplusplus #define swprintf _swprintf #define vswprintf _vswprintf #define _swprintf_l __swprintf_l #define _vswprintf_l __vswprintf_l +#endif #endif #endif Modified: trunk/reactos/include/crt/wchar.h URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/crt/wchar.h?rev=57909r1=57908r2=57909view=diff == --- trunk/reactos/include/crt/wchar.h [iso-8859-1] (original) +++ trunk/reactos/include/crt/wchar.h [iso-8859-1] Thu Dec 13 19:21:30 2012 @@ -561,12 +561,14 @@ _CRTIMP int __cdecl __swprintf_l(wchar_t *_Dest,const wchar_t *_Format,_locale_t _Plocinfo,...); _CRTIMP int __cdecl __vswprintf_l(wchar_t *_Dest,const wchar_t *_Format,_locale_t _Plocinfo,va_list _Args); +#if 0 //this is for MSVCRT80 and higher, which we don't use nor implement #ifdef _CRT_NON_CONFORMING_SWPRINTFS #ifndef __cplusplus #define swprintf _swprintf #define vswprintf _vswprintf #define _swprintf_l __swprintf_l #define _vswprintf_l __vswprintf_l +#endif #endif #endif ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [tfaber] 57485: [SHELL32] - Fix what might finally be the last missing this- instances left over from the C++ conversion (used a regex this time)
Isn't there somewhere some compiler warning for such ambiguation?
Le Fri, 05 Oct 2012 10:41:47 +0200,
Thomas Faber thfa...@gmx.de a écrit :
Yeah, that would certainly be a more sensible convention.
I wasn't planning on refactoring all of shell32 any time soon
though. :|
We accept patches™ ;)
On 2012-10-05 10:30, Timo Kreuzer wrote:
Shouldn't member variables rather be prefixed with m_?
Am 05.10.2012 01:46, schrieb tfa...@svn.reactos.org:
Author: tfaber
Date: Thu Oct 4 23:46:59 2012
New Revision: 57485
URL: http://svn.reactos.org/svn/reactos?rev=57485view=rev
Log:
[SHELL32]
- Fix what might finally be the last missing this- instances
left over from the C++ conversion (used a regex this time)
Modified:
trunk/reactos/dll/win32/shell32/folders/cpanel.cpp
trunk/reactos/dll/win32/shell32/folders/mycomp.cpp
trunk/reactos/dll/win32/shell32/shlview.cpp
Modified: trunk/reactos/dll/win32/shell32/folders/cpanel.cpp
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/shell32/folders/cpanel.cpp?rev=57485r1=57484r2=57485view=diff
==
--- trunk/reactos/dll/win32/shell32/folders/cpanel.cpp
[iso-8859-1] (original) +++
trunk/reactos/dll/win32/shell32/folders/cpanel.cpp [iso-8859-1]
Thu Oct 4 23:46:59 2012 @@ -540,7 +540,7 @@ // pObj =
(IContextMenu *)this; this-apidl = apidl;
-cidl = cidl;
+this-cidl = cidl;
pObj-AddRef();
hr = S_OK;
} else if (IsEqualIID(riid, IID_IDataObject) (cidl =
1)) {
Modified: trunk/reactos/dll/win32/shell32/folders/mycomp.cpp
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/shell32/folders/mycomp.cpp?rev=57485r1=57484r2=57485view=diff
==
--- trunk/reactos/dll/win32/shell32/folders/mycomp.cpp
[iso-8859-1] (original) +++
trunk/reactos/dll/win32/shell32/folders/mycomp.cpp [iso-8859-1]
Thu Oct 4 23:46:59 2012 @@ -728,7 +728,7 @@ wcscpy(sName, lpName);
SHFree(sName);
-sName = sName;
+this-sName = sName;
TRACE(result %s\n, debugstr_w(sName));
return S_OK;
}
Modified: trunk/reactos/dll/win32/shell32/shlview.cpp
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/shell32/shlview.cpp?rev=57485r1=57484r2=57485view=diff
==
--- trunk/reactos/dll/win32/shell32/shlview.cpp [iso-8859-1]
(original) +++ trunk/reactos/dll/win32/shell32/shlview.cpp
[iso-8859-1] Thu Oct 4 23:46:59 2012 @@ -2828,7 +2828,7 @@
FIXME(partial stub: %p %08x %08x %p\n, this, aspects, advf,
pAdvSink); /* FIXME: we set the AdviseSink, but never use it to
send any advice */
-pAdvSink = pAdvSink;
+this-pAdvSink = pAdvSink;
dwAspects = aspects;
dwAdvf = advf;
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 57171: [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
Hi.
Please see the inlined answers.
Timo Kreuzer a écrit :
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.
There is DllEntryPoint in the code base, but no DllMain. Is it what you
are talking about?
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.
You have a point. If nothing is given, then the programmer could assume
that nothing happens.
Regarding CRT thread initialization: DisableThreadLibraryCalls means
that the DLLs ahs nothing to initialize on thread creation, and that the
loader can gain some performance in skipping this DLL. We have some Dlls
that call it, and if this is a problem with our CRT, then this is bad.
Quoting MSDN:
Do not call this function from a DLL that is linked to the static C
run-time library (CRT). The static CRT requires DLL_THREAD_ATTACH and
DLL_THREAD_DETATCH notifications to function properly
Reading between the lines, that means that every CRT thread
initialization is done in msvcrt.dll, and nowhere else. What we link
statically to our DLLs shouldn't have anything to do on thread
initializations.
There is also no need for weak symbols, we can simply call the stub
DllMain, since it doesn't (shouldn't) do anything.
As said in the comment, link.exe choses symbols defined in the object
files it is given, and then in the libraries. So adding a stubbed
version of dllmain in our library is harmless (unless someone puts his
DllMain in a static library and links to that library.) I don't really
know about ld behaviour regarding this case, and the
--allow-multiple-definition option of ld (see
http://sourceware.org/binutils/docs-2.22/ld/Options.html#Options )
scares me.
Regards,
Timo
Regards.
Jérôme
Am 27.08.2012 01:31, schrieb jgar...@svn.reactos.org:
Author: jgardou
Date: Sun Aug 26 23:31:49 2012
New Revision: 57171
URL: http://svn.reactos.org/svn/reactos?rev=57171view=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?rev=57171r1=57170r2=57171view=diff
==
--- 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.c?rev=57171r1=57170r2=57171view=diff
==
--- 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
Re: [ros-dev] [ros-diffs] [jgardou] 57129: [WIN32K] - Use the right surface for direct DCs in DIB transfer functions It could have changed with a display settings change
Oh, right, I forgot about the lock...
Commit your rewrite :-)
Timo Kreuzer a écrit :
Hmmm
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 jgar...@svn.reactos.org:
Author: jgardou
Date: Wed Aug 22 16:45:49 2012
New Revision: 57129
URL: http://svn.reactos.org/svn/reactos?rev=57129view=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?rev=57129r1=57128r2=57129view=diff
==
--- 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
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 56947: [WIN32SS/GDI]
OOPS.. Sorry. Changelog should have been: [WIN32SS/NTGDI] - Associate NULL surface for newly created memory DCs. jgar...@svn.reactos.org a écrit : Author: jgardou Date: Mon Jul 23 10:12:53 2012 New Revision: 56947 URL: http://svn.reactos.org/svn/reactos?rev=56947view=rev Log: [WIN32SS/GDI] Modified: trunk/reactos/win32ss/gdi/eng/engbrush.c trunk/reactos/win32ss/gdi/ntgdi/bitblt.c trunk/reactos/win32ss/gdi/ntgdi/bitmaps.c trunk/reactos/win32ss/gdi/ntgdi/dclife.c trunk/reactos/win32ss/gdi/ntgdi/dcobjs.c Modified: trunk/reactos/win32ss/gdi/eng/engbrush.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/eng/engbrush.c?rev=56947r1=56946r2=56947view=diff == --- trunk/reactos/win32ss/gdi/eng/engbrush.c [iso-8859-1] (original) +++ trunk/reactos/win32ss/gdi/eng/engbrush.c [iso-8859-1] Mon Jul 23 10:12:53 2012 @@ -67,6 +67,9 @@ pebo-crCurrentText = pdc-pdcattr-crForegroundClr; pebo-psurfTrg = pdc-dclevel.pSurface; +/* We are initializing for a new memory DC */ +if(!pebo-psurfTrg) +pebo-psurfTrg = psurfDefaultBitmap; ASSERT(pebo-psurfTrg); ASSERT(pebo-psurfTrg-ppal); Modified: trunk/reactos/win32ss/gdi/ntgdi/bitblt.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/bitblt.c?rev=56947r1=56946r2=56947view=diff == --- trunk/reactos/win32ss/gdi/ntgdi/bitblt.c [iso-8859-1] (original) +++ trunk/reactos/win32ss/gdi/ntgdi/bitblt.c [iso-8859-1] Mon Jul 23 10:12:53 2012 @@ -807,9 +807,11 @@ SURFACE *psurf; POINTL BrushOrigin; BOOL ret; -PBRUSH pbrush = pebo-pbrush; +PBRUSH pbrush; ASSERT(pebo); +pbrush = pebo-pbrush; +ASSERT(pbrush); FIXUP_ROP(dwRop); Modified: trunk/reactos/win32ss/gdi/ntgdi/bitmaps.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/bitmaps.c?rev=56947r1=56946r2=56947view=diff == --- trunk/reactos/win32ss/gdi/ntgdi/bitmaps.c [iso-8859-1] (original) +++ trunk/reactos/win32ss/gdi/ntgdi/bitmaps.c [iso-8859-1] Mon Jul 23 10:12:53 2012 @@ -259,6 +259,7 @@ DIBSECTION dibs; INT Count; PSURFACE psurf = Dc-dclevel.pSurface; +if(!psurf) psurf = psurfDefaultBitmap; Count = BITMAP_GetObject(psurf, sizeof(dibs), dibs); if (Count == sizeof(BITMAP)) Modified: trunk/reactos/win32ss/gdi/ntgdi/dclife.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/dclife.c?rev=56947r1=56946r2=56947view=diff == --- trunk/reactos/win32ss/gdi/ntgdi/dclife.c [iso-8859-1] (original) +++ trunk/reactos/win32ss/gdi/ntgdi/dclife.c [iso-8859-1] Mon Jul 23 10:12:53 2012 @@ -180,7 +180,7 @@ pdc-dclevel.pSurface = NULL; // FIXME: HACK, because our code expects a surface -pdc-dclevel.pSurface = SURFACE_ShareLockSurface(StockObjects[DEFAULT_BITMAP]); +// pdc-dclevel.pSurface = SURFACE_ShareLockSurface(StockObjects[DEFAULT_BITMAP]); pdc-erclBounds.left = 0; pdc-erclBounds.top = 0; @@ -271,12 +271,9 @@ pdc-dclevel.ptlBrushOrigin.x = 0; pdc-dclevel.ptlBrushOrigin.y = 0; pdc-dcattr.ptlBrushOrigin = pdc-dclevel.ptlBrushOrigin; - -/* Initialize EBRUSHOBJs */ -EBRUSHOBJ_vInit(pdc-eboFill, pdc-dclevel.pbrFill, pdc); -EBRUSHOBJ_vInit(pdc-eboLine, pdc-dclevel.pbrLine, pdc); + +/* Init text brush */ EBRUSHOBJ_vInit(pdc-eboText, pbrDefaultBrush, pdc); -EBRUSHOBJ_vInit(pdc-eboBackground, pbrDefaultBrush, pdc); /* Setup fill data */ pdc-dcattr.jROP2 = R2_COPYPEN; @@ -424,9 +421,8 @@ pdc-dclevel.pbrFill = BRUSH_ShareLockBrush(pdc-pdcattr-hbrush); pdc-dclevel.pbrLine = PEN_ShareLockPen(pdc-pdcattr-hpen); -/* Update the EBRUSHOBJs */ -EBRUSHOBJ_vUpdate(pdc-eboFill, pdc-dclevel.pbrFill, pdc); -EBRUSHOBJ_vUpdate(pdc-eboLine, pdc-dclevel.pbrLine, pdc); +/* Mark them as dirty */ +pdc-pdcattr-ulDirty_ |= DIRTY_FILL|DIRTY_LINE; /* Allocate or free DC attribute */ if (ulOwner == GDI_OBJ_HMGR_PUBLIC || ulOwner == GDI_OBJ_HMGR_NONE) @@ -796,7 +792,7 @@ DC_bAllocDcAttr(pdcNew); // HACK! -DC_vSelectSurface(pdcNew, psurfDefaultBitmap); +//DC_vSelectSurface(pdcNew, psurfDefaultBitmap); DC_UnlockDc(pdcNew); Modified: trunk/reactos/win32ss/gdi/ntgdi/dcobjs.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/dcobjs.c?rev=56947r1=56946r2=56947view=diff == --- trunk/reactos/win32ss/gdi/ntgdi/dcobjs.c [iso-8859-1] (original) +++ trunk/reactos/win32ss/gdi/ntgdi/dcobjs.c [iso-8859-1] Mon Jul 23 10:12:53 2012 @@ -230,9 +230,10
Re: [ros-dev] [ros-diffs] [akhaldi] 56104: [CMAKE] * Fix a typo.
Le 10/03/2012 19:02, akha...@svn.reactos.org a écrit :
Author: akhaldi
Date: Sat Mar 10 18:02:40 2012
New Revision: 56104
URL: http://svn.reactos.org/svn/reactos?rev=56104view=rev
Log:
[CMAKE]
* Fix a typo.
Modified:
trunk/reactos/cmake/msvc.cmake
Modified: trunk/reactos/cmake/msvc.cmake
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/cmake/msvc.cmake?rev=56104r1=56103r2=56104view=diff
==
--- trunk/reactos/cmake/msvc.cmake [iso-8859-1] (original)
+++ trunk/reactos/cmake/msvc.cmake [iso-8859-1] Sat Mar 10 18:02:40 2012
@@ -178,7 +178,7 @@
# add our library
# NOTE: as stub file and def file are generated in one pass,
depending on one is like depending on the other
-_add_library(lib${_file} STATIC EXCLUDE_FROM_ALL
+add_library(lib${_file} STATIC EXCLUDE_FROM_ALL
${CMAKE_CURRENT_BINARY_DIR}/lib${_file}_stubs.asm)
# set correct link rule
it wasn't a typo :-)
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 56082: [DAMN_IT] - addendum to r56081
Le 07/03/2012 22:50, Jérôme Gardou a écrit : Hey! Can't we add tests to the regular tree, and disable them with a onig flag or something. This is getting retarded, and we must be the only project separating tests and runtime in their tree. Every tester should just build them (not speaking about developers...), and we include them in nightly builds. For me this separation is just pointless... regards. Jérôme In onig flag, you should read config flag... ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 55770: [NTOSKRNL/MM] - finally, release user shared data at process address space cleanup. - release PDE pages that might not be freed at process end. - Let the cal
Le 21/02/2012 01:32, jgar...@svn.reactos.org a écrit : Author: jgardou Date: Tue Feb 21 00:32:24 2012 New Revision: 55770 URL: http://svn.reactos.org/svn/reactos?rev=55770view=rev Log: [NTOSKRNL/MM] - finally, release user shared data at process address space cleanup. - release PDE pages that might not be freed at process end. - Let the caller handle PDE release when deleting a PTE - restore Richard's ASSERT : All user PDE pages are now freed! Addendum to log : When a page maps a Prototype PTE, we can't know if it must be deleted before dropping shared reference. Modify ASSERT accordingly. Restore the ASSERTion that only page fault should provocate the creation of the PDE and modify PDE refcounting in pageout code accordingly. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [janderwald] 55447: [DISK_NEW] - Fix compilation of new disk driver - Patch by Alex Ionescu
Le 06/02/2012 07:50, janderw...@svn.reactos.org a écrit : +if(ARCH MATCHES i386) +add_target_compile_flags(disk -mrtd -fno-builtin -Wno-unused-variable -Wno-pointer-sign) +endif() + Hey! Those look very GCC centric. The corresponding flag for MSVC to -mrtd would be /Gz. As for other flags, I'm unsure of what -fno-builtin would correspond to, and others are only for warnings. Cheers. Jérôme. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [janderwald] 55447: [DISK_NEW] - Fix compilation of new disk driver - Patch by Alex Ionescu
Le 06/02/2012 19:58, Alex Ionescu a écrit : All of these are only for GCC because MSVC already compiles this correctly. On 2012-02-06, at 10:07 AM, Jérôme Gardou wrote: Le 06/02/2012 07:50, janderw...@svn.reactos.org a écrit : +if(ARCH MATCHES i386) +add_target_compile_flags(disk -mrtd -fno-builtin -Wno-unused-variable -Wno-pointer-sign) +endif() + Hey! Those look very GCC centric. The corresponding flag for MSVC to -mrtd would be /Gz. As for other flags, I'm unsure of what -fno-builtin would correspond to, and others are only for warnings. Cheers. Jérôme. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev Are you sure that /Gz is default with cl.exe ? Anyway, those flags should be wrapped with if (NOT MSVC) condition. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [project-tools] Revision 1363: [ROSBE-UNIX] Implement support for pre-build post-build hook scripts in RosBE-Unix.
Le 28/01/2012 23:30, Colin Finck a écrit : pschweit...@svn.reactos.org wrote: touch boot/bootdata/packages/reactos.dff.in We can't put this one-liner into the CMakeLists.txt file? execute_process should do the job if there is no touch command in CMake itself. Your change makes RosBE depend on a very specific file in a very specific path of the source tree (= tree change only possible with an updated RosBE). In addition, these hooks separate the build logic between CMake and RosBE and pave the way for even more source tree dependent changes in RosBE. I like to avoid this. - Colin ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev I don't know why this is needed at all, but in cmake files you can use cmake -E touch for portability (windows have no default touch afaik) ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
[ros-dev] December 2011 meeting minutes
Hello everybody. You will find attached to this e-mail the minutes for the meeting of 2011. A topic as also been opened on the ReactOS forum :http://reactos.org/forum/viewtopic.php?f=2t=10352 http://reactos.org/forum/viewtopic.php?f=2t=10352 I'm deeply sorry for the delay. Regards. Jérôme 2011-12.meeting_minutes.rtf Description: MS-Word document ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
[ros-dev] November meeting minutes are there.
You will find them on the forum : http://reactos.org/forum/viewtopic.php?f=2t=9918 Best regards. Jérôme ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 54462: [RTL] - explicitly truncate some values, so it doesn't count as an error for compiler/MSVC runtime checker
Here the variable is an ULONGLONG and we pass it to a macro that casts
it to a DWORD, and that's what it should do. Although casting and
truncating is the same from a normal compiler point of view, a run
time checker would raise a warning if you cast a value superior to
0x to a DWORD. Truncating it explicitly tells it yes, I
truncate this value, not for avoiding compiler warning, but because
that's what I want. See r54460 to see which kind of bugs such checkers
could help to fix.
See also http://msdn.microsoft.com/en-us/magazine/cc301374.aspx for some
in depth details, and, of course, cl documentation.
Also, gcc has this kind of functionalities, it's called GNAT.
Mit freundlichen Grüssen. :-)
Jérôme
Le 24/11/2011 00:03, Timo Kreuzer a écrit :
That doesn't make much sense.
Whats the point of the LOWORD() macro, if not truncating it ?
Fix the macro if its broken.
Am 20.11.2011 20:45, schrieb jgar...@svn.reactos.org:
Author: jgardou
Date: Sun Nov 20 19:45:06 2011
New Revision: 54462
URL: http://svn.reactos.org/svn/reactos?rev=54462view=rev
Log:
[RTL]
- explicitly truncate some values, so it doesn't count as an error
for compiler/MSVC runtime checker
Modified:
trunk/reactos/lib/rtl/image.c
Modified: trunk/reactos/lib/rtl/image.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/lib/rtl/image.c?rev=54462r1=54461r2=54462view=diff
==
--- trunk/reactos/lib/rtl/image.c [iso-8859-1] (original)
+++ trunk/reactos/lib/rtl/image.c [iso-8859-1] Sun Nov 20 19:45:06 2011
@@ -369,7 +369,7 @@
{
SHORT Offset;
USHORT Type;
-USHORT i;
+ULONG i;
PUSHORT ShortPtr;
PULONG LongPtr;
PULONGLONG LongLongPtr;
@@ -379,7 +379,6 @@
Offset = SWAPW(*TypeOffset) 0xFFF;
Type = SWAPW(*TypeOffset) 12;
ShortPtr = (PUSHORT)(RVA(Address, Offset));
-
/*
* Don't relocate within the relocation section itself.
* GCC/LD generates sometimes relocation records for the
relocation section.
@@ -398,16 +397,16 @@
break;
case IMAGE_REL_BASED_HIGH:
-*ShortPtr = HIWORD(MAKELONG(0, *ShortPtr) + (LONG)Delta);
+*ShortPtr = HIWORD(MAKELONG(0, *ShortPtr) + (Delta
0x));
break;
case IMAGE_REL_BASED_LOW:
-*ShortPtr = SWAPW(*ShortPtr) + LOWORD(Delta);
+*ShortPtr = SWAPW(*ShortPtr) + LOWORD(Delta 0x);
break;
case IMAGE_REL_BASED_HIGHLOW:
LongPtr = (PULONG)RVA(Address, Offset);
-*LongPtr = SWAPD(*LongPtr) + (ULONG)Delta;
+*LongPtr = SWAPD(*LongPtr) + (Delta 0x);
break;
case IMAGE_REL_BASED_DIR64:
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Qemu Recoverable Assertion when Loading Gecko
Le 18/11/2011 01:07, James Tabor a écrit : Head up on this one. It's recoverable by just typing cont and it goes on. (dll/ntdll/ldr/ldrutils.c:1177) Overlapping DLL: C:\ReactOS\system32\oleaut32.dll WARNING: MmFlushVirtualMemory at ntoskrnl/mm/ARM3/virtual.c:1044 is UNIMPLEMENTED! fixme:(dll/win32/wintrust/register.c:1161) stub (dll/ntdll/ldr/ldrutils.c:1138) LDR: LdrpMapDll Relocating Image Name C:\ReactOS\system32\mshtml.dll (7665 - 014C) (dll/ntdll/ldr/ldrutils.c:1177) Overlapping DLL: C:\ReactOS\System32\setupapi.dll (ntoskrnl/se/semgr.c:299) SidInToken Calls: 4 Assertion 'RtlCheckBit(MiUserPfnBitMap, (ULONG)Page)' failed at ntoskrnl/mm/freelist.c line 127 Entered debugger on embedded INT3 at 0x0008:0x80904efe. kdb: bt Eip: NTOSKRNL.EXE:104eff (lib/rtl/i386/debug_asm.S:35 (_DbgBreakPoint@0)) Frames: NTOSKRNL.EXE:c283d (ntoskrnl/mm/freelist.c:127 (MmRemoveLRUUserPage@4)) NTOSKRNL.EXE:c18de (ntoskrnl/mm/balance.c:134 (MmReleasePageMemoryConsumer@8)) NTOSKRNL.EXE:cbf6a (ntoskrnl/mm/section.c:2365 (MmPageOutSectionView@16)) NTOSKRNL.EXE:c822c (ntoskrnl/mm/rmap.c:143 (MmPageOutPhysicalAddress@4)) NTOSKRNL.EXE:c17a9 (ntoskrnl/mm/balance.c:177 (MmTrimUserMemory)) NTOSKRNL.EXE:c141c (ntoskrnl/mm/balance.c:366 (MiBalancerThread@4)) NTOSKRNL.EXE:f2972 (ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8)) NTOSKRNL.EXE:5a6a (ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0)) NTOSKRNL.EXE:f290e (ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28)) fcdebd80 NTOSKRNL.EXE:152e5 (ntoskrnl/ke/wait.c:527 (KeWaitForSingleObject@20)) NTOSKRNL.EXE:c524e (ntoskrnl/mm/mminit.c:292 (MmMpwThreadMain@4)) NTOSKRNL.EXE:f2972 (ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8)) NTOSKRNL.EXE:5a6a (ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0)) NTOSKRNL.EXE:f290e (ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28)) fce4fab0 0001 kdb: cont Assertion 'RtlCheckBit(MiUserPfnBitMap, (ULONG)Page)' failed at ntoskrnl/mm/freelist.c line 127 Entered debugger on embedded INT3 at 0x0008:0x80904efe. kdb: cont (subsystems/win32/win32k/ntuser/keyboard.c:1066) err: No Window for Translate. (dll/ntdll/ldr/ldrutils.c:1138) LDR: LdrpMapDll Relocating Image Name xul.dll (1000 - 01DB) (dll/ntdll/ldr/ldrutils.c:1177) Overlapping DLL: C:\ReactOS\system32\ \1.0.0\wine_gecko\xpcom.dll ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev Hi James! I put this ASSERT here to check, as Cameron just pointed, that we don't remove a PFN entry from user bitmap when it already has or never was in it. I hoped someone would trigger it. I think you deserve a thank you :-) So let's just fix this one, it can't do any harm. Btw, do you mean by loading gecko, the very instant when mshtml.dll gets registered in 3rd stage? Isn't it startling how it coincides with bug 5857 ? Best regards. Jérôme ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Qemu Recoverable Assertion when Loading Gecko
Le 18/11/2011 21:08, James Tabor a écrit : Hi! 2011/11/18 Jérôme Gardoujerome.gar...@laposte.net: Hi James! I put this ASSERT here to check, as Cameron just pointed, that we don't remove a PFN entry from user bitmap when it already has or never was in it. I hoped someone would trigger it. I think you deserve a thank you :-) So let's just fix this one, it can't do any harm. Btw, do you mean by loading gecko, the very instant when mshtml.dll gets registered in 3rd stage? Isn't it startling how it coincides with bug 5857 ? Best regards. Jérôme Something the installer was doing I guess, in most cases more than 10 hits at this point. Running DOSEmu hits it every time to the point of having to kill Qemu. The fix for me last night was commenting the assert out. To continue my testing. Hoping I'm not the only one but if I am, QEMU emulator version 0.13.0 (qemu-kvm-0.13.0) Fedroa 12/13/14. Haven't tested Slackware 13.x and hardware yet. Thanks, James ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev Out of curiosity, how much RAm did you allocate for your VM ? ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [tkreuzer] 53399: [VMWINST] Fix amd64 build [NTDLL] add missing amd64 specific exports [MSVCRT*] Fix mangled c++ exports for amd64 [OLEAUT32] Add amd64 adm stub for call_meth
Le 23/08/2011 10:58, tkreu...@svn.reactos.org a écrit : Author: tkreuzer Date: Tue Aug 23 08:58:15 2011 New Revision: 53399 URL: http://svn.reactos.org/svn/reactos?rev=53399view=rev Log: [VMWINST] Fix amd64 build What about : [VMWINST] Get rid of this useless relic. I mean it's something we have to maintain, it was written for antediluvian vmware versions, and I see no reason to have such a thing. I may as well write an application to install specific ATI card drivers, or intel chipset drivers... ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [tkreuzer] 53399: [VMWINST] Fix amd64 build
Le 04/09/2011 17:29, Bernd Blaauw a écrit : Op 4-9-2011 17:10, Jérôme Gardou schreef: Le 23/08/2011 10:58, tkreu...@svn.reactos.org a écrit : What about : [VMWINST] Get rid of this useless relic. I mean it's something we have to maintain, it was written for antediluvian vmware versions, and I see no reason to have such a thing. I may as well write an application to install specific ATI card drivers, or intel chipset drivers... Well you got multiple options: * ensure the VMware installer (MSI) can run properly so people can install their drivers. Makes VMWINST obsolete. * ensure ReactOS can deal with a directory containing the bare VMware drivers (requiring 7zip to extract them from VMware 7 ISO). * convert the Linux opensource VMware drivers into NT ones * update this relic tool to finally (also) work with modern VMware ISO contents structure. Nice and all that people can show off Quake2, Furmark etc in VirtualBox..now prove the same for other virtualisation products and real hardware graphics cards (Nvidia and AMD/ATI for starters, Intel graphics if you aim at business desktops). Demonstrate equal progress in all used/supported platforms. Show VMWINST is an obsolete relic by proving VMware drivers can install on trunk ReactOS, including the added 3D support (OpenGL only I guess, but good enough for now). ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev Please, stop asking us to port opensource linux drivers into NT ones. And also don't answer to this sentence and try to explain us why it would be so good for this project. There's no offence meant, it's just that we don't have interest into it, and we lack manpower anyway. Also, Aleksey noted that he still had use of this, I won't touch it. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [cmihail] 53543: [shell32.dll] - Fix bug related to correct error code returning in delete_files. The value of 1026 was revealed to be returned by windows 2003 server. Score
Hello Claudiu! I notice some weird tab/spaces modifications here. Regards. Jérôme. Le 03/09/2011 16:20, cmih...@svn.reactos.org a écrit : Author: cmihail Date: Sat Sep 3 14:20:03 2011 New Revision: 53543 URL: http://svn.reactos.org/svn/reactos?rev=53543view=rev Log: [shell32.dll] - Fix bug related to correct error code returning in delete_files. The value of 1026 was revealed to be returned by windows 2003 server. Score several passed winetests. - Fix a bug in ShellLink::SetShowCmd and score one more passed winetest Modified: branches/shell32_new-bringup/dll/win32/shell32/shelllink.cpp branches/shell32_new-bringup/dll/win32/shell32/shlfileop.cpp ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 53547: [VGA_NEW] - fix some warnings
Yuou're right... It was a bad mistake in my local copy which caused the warnings to appear. Thanks for pointing this out. BTW, I took a look at it, and our headers have the NTAPI calling convention, whereas WDK ones haven't. Le 03/09/2011 18:21, Alex Ionescu a écrit : These changes are wrong :( Please use the correct compiler flag instead (-mrtd) Best regards, Alex Ionescu ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 53547: [VGA_NEW] - fix some warnings
May I ask what the change is? Le 03/09/2011 22:53, Dmitry Gorbachev a écrit : BTW, -mrtd has recently (in April) changed its behavior in GCC trunk. If reactos needs this flag, then maybe somebody should ask the author of that change (Kai) to provide another flag (say, -mold-rtd) instead of it. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 53481: [WIDL] - reenable -Oif flag, it's too good to be disabled With this commit, advapi32:service winetest suffers only 2 failures.
Feel free to disable it again if probems occur.
Probable bugs are hard to test alone, so I'm waiting for test bot to
confirm this fixes things without breaking others.
Regards.
Jérôme.
Le 28/08/2011 17:37, jgar...@svn.reactos.org a écrit :
Author: jgardou
Date: Sun Aug 28 15:37:01 2011
New Revision: 53481
URL: http://svn.reactos.org/svn/reactos?rev=53481view=rev
Log:
[WIDL]
- reenable -Oif flag, it's too good to be disabled
With this commit, advapi32:service winetest suffers only 2 failures.
Modified:
trunk/reactos/cmake/idl-support.cmake
trunk/reactos/tools/rbuild/backend/mingw/rules.mak
Modified: trunk/reactos/cmake/idl-support.cmake
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/cmake/idl-support.cmake?rev=53481r1=53480r2=53481view=diff
==
--- trunk/reactos/cmake/idl-support.cmake [iso-8859-1] (original)
+++ trunk/reactos/cmake/idl-support.cmake [iso-8859-1] Sun Aug 28 15:37:01 2011
@@ -22,8 +22,8 @@
set(IDL_HEADER_ARG -h -o) #.h
set(IDL_HEADER_ARG2 -h -H) #.h
set(IDL_TYPELIB_ARG -t -o) #.tlb
-set(IDL_SERVER_ARG -s -o) #.c for server library
-set(IDL_CLIENT_ARG -c -o) #.c for stub client library
+set(IDL_SERVER_ARG -Oif -s -o) #.c for server library
+set(IDL_CLIENT_ARG -Oif -c -o) #.c for stub client library
set(IDL_PROXY_ARG -p -o)
set(IDL_INTERFACE_ARG -u -o)
if(ARCH MATCHES i386)
@@ -169,6 +169,6 @@
list(APPEND IID_SOURCES ${NAME}_i.c)
endforeach()
add_library(${TARGET} ${IID_SOURCES})
-add_dependencies(${TARGET} psdk)
+ add_dependencies(${TARGET} psdk)
set_target_properties(${TARGET} PROPERTIES EXCLUDE_FROM_ALL TRUE)
endfunction()
Modified: trunk/reactos/tools/rbuild/backend/mingw/rules.mak
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/tools/rbuild/backend/mingw/rules.mak?rev=53481r1=53480r2=53481view=diff
==
--- trunk/reactos/tools/rbuild/backend/mingw/rules.mak [iso-8859-1] (original)
+++ trunk/reactos/tools/rbuild/backend/mingw/rules.mak [iso-8859-1] Sun Aug 28
15:37:01 2011
@@ -264,7 +264,7 @@
${call RBUILD_intermediate_path_noext,$(2)}_c: $(2) $(3) $$(widl_TARGET) |
${call RBUILD_intermediate_dir,$(2)}
$$(ECHO_WIDL)
- $$(Q)$$(widl_TARGET) ${call RBUILD_midlflags,$(1),$(4),-I${call
RBUILD_dir,$(2)}} -h -H ${call RBUILD_intermediate_path_noext,$(2)}_c.h -c -C
${call RBUILD_intermediate_path_noext,$(2)}_c.c $(2)
+ $$(Q)$$(widl_TARGET) ${call RBUILD_midlflags,$(1),$(4),-I${call
RBUILD_dir,$(2)}} -Oif -h -H ${call RBUILD_intermediate_path_noext,$(2)}_c.h -c
-C ${call RBUILD_intermediate_path_noext,$(2)}_c.c $(2)
$${checkpoint} $$@$(NUL)
${call RBUILD_CC,$(1),${call
RBUILD_intermediate_path_noext,$(2)}_c.c,,,${call
RBUILD_intermediate_path_noext,$(2)}_c.o}
@@ -280,7 +280,7 @@
${call RBUILD_intermediate_path_noext,$(2)}_s: $(2) $(3) $$(widl_TARGET) |
${call RBUILD_intermediate_dir,$(2)}
$$(ECHO_WIDL)
- $$(Q)$$(widl_TARGET) ${call RBUILD_midlflags,$(1),$(4),-I${call
RBUILD_dir,$(2)}} -h -H ${call RBUILD_intermediate_path_noext,$(2)}_s.h -s -S
${call RBUILD_intermediate_path_noext,$(2)}_s.c $(2)
+ $$(Q)$$(widl_TARGET) ${call RBUILD_midlflags,$(1),$(4),-I${call
RBUILD_dir,$(2)}} -Oif -h -H ${call RBUILD_intermediate_path_noext,$(2)}_s.h -s
-S ${call RBUILD_intermediate_path_noext,$(2)}_s.c $(2)
$${checkpoint} $$@$(NUL)
${call RBUILD_CC,$(1),${call
RBUILD_intermediate_path_noext,$(2)}_s.c,,,${call
RBUILD_intermediate_path_noext,$(2)}_s.o}
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [ekohl] 53469: [WIDL] Revert parts of r53171: Remove the -Oif flag for WIDL because the NT4 stub code generated by the current WIDL is heavily broken with respect to the rang
Please see inlined answers. Le 28/08/2011 00:29, Eric Kohl a écrit : Hello Jérôme! I'm not sure about what you mean for range attribute, but I notice that typedef [context_handle] PVOID my_handle; makes widl thinks that any value of the my_handle type is passed by pointer, whereas midl considers it is passed by value. Did you try to find the bug in WIDL? In fact, it was our bug, fixed in r53477. Could you be more precise about range attributes and others? please. I should better have written range attributes and probably others! The range attribute is used in the svcctl.idl file and enables range checks in rpcrt4.dll. This is a nice feature, but WIDL is messing up the ranges if a range attribute is used with function parameters. For example: DWORD Test( [in] SC_RPC_HANDLE hSCManager, [in, range(0, 1024)] DWORD dwParam1, [in, range(0, 255)] DWORD dwParam2); WIDL will emit the same range type (range 0-255) for both parameters because the range attribute is assigned to the DWORD type and it is overwritten whenever a new range attribute is used with the DWORD type. In the end all DWORD type parameters that have a range attribute will use the range that is used by the last DWORD type with a range attribute (dwParam2 in this case) in the idl file. This will cause some 'funny' effects if dwParam1 is greater than 255. :-/ OK, I guess we'd have to open a bug on wine side, I'm not comfortable enough with WIDL code to fix it myself. BTW, I think it is more important to have a working RPC system in ReactOS than a windows-compatible one. The compatibility issues can be fixed later, but if you break RPC today by fixing compatibility issues you will render ReactOS unusable. So please be very careful when you make changes to rpcrt4 or WIDL. I fully agree with that, but just try to reenable -Oif, and look at advapi32:service winetest results. You'd be surprised : no skipped tests, and some others are actually fixed! (while others are broken, most probably because of this range thing) So it's more than a nice feature. You can already see it fixes one eventlog test by looking at the link Olaf provided (look for eventlog.c:206). Regards, Eric ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev Regards. Jérôme. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] August meeting
Hi. I won't be able to attend the meeting tonight. As for the votings, Amine knows my feelings about the two issues concerned, so I give him my vote, if such a thing is doable. Regards. Jérôme. Le 25/08/2011 18:14, Pierre Schweitzer a écrit : Hi, I've just sent the emails containing the credentials to all the users. As a public reminder, the meeting will take place on the IRC server fezile.reactos.org port 6667, no SSL) on channel #meeting. Please don't forget to log in with the given nickname and then provide the password you received. The meeting will be open for reading to everyone. The IRC server will be open a short time before meeting starts (at 19UTC, so in a bit less than 3 hours). Regards, Pierre. ReactOS Development Listros-dev@reactos.org wrote on Wed, August 24th, 2011, 11:30 AM: Hi, this is a reminder about the Status meeting, which is to happen tomorrow, 25th of August at 19:00 UTC. Please don't miss it. Proposed agenda for the meeting: 1. Arwinss adoption voting. 2. CMake adoption voting. 3. Release preparation status report, deciding on the next release date. 4. Driver signing. Discussing possible threats and deciding on an official position wrt driver signing in future. 4. Party related to GSoC results. I propose to move individual devs status reports to ros-dev mailing list, because there is no reason to just sit in the irc channel and listen to them for hours. List of participants: - Giannis Adamopoulos (smiley1_) - Johannes Anderwald (janderwald) - Javier Agustìn Fernàndez Arroyo (elhoir) - Maciej Bialas (niski) - Jan Blomqvist-Kinander (JaixBly) - Aleksey Bragin (abragin) - Thomas Faber (ThFabba) - Colin Finck (Colin_Finck) - Jérôme Gardou (zefklop) - Danny Götte (dangerground) - Cameron Gutman (aicom) - Ziliang Guo (ZWabbit) - Rafal Harabien (rafalh) - Andrew Hill (ash77) - Kamil Hornicek (Pigglesworth) - Gabriel Ilardi (gabriel_it) - Alex Ionescu (Alex_Ionescu) - Amine Khaldi (AmineKhaldi) - Igor Koshpaev (tower) - Timo Kreuzer (tkreuzer) - Matthias Kupfer (Collibri) - Michael Martin (mjmartin) - Victor Martinez (vicmarcal) - Roel Messiant (Mephisto) - Claudiu Mihail (KlausM) - Andrew Munger (WaxDragon) - Ged Murphy (GedMurphy) - Igor Paliychuk (igorko) - Sylvain Petreolle (Usurp) - Hervé Poussineau (hpoussin) - Daniel Reimer (dreimer) - Pierre Schweitzer (HeisSpiter) - Samuel Serapion (encoded) - Olaf Siejka (Caemyr) - James Tabor (jimtabor) - Christoph von Wittich (Christoph_vW) - Art Yerkes (arty) WBR, Aleksey Bragin. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [ekohl] 53201: [ADVAPI32] Fix EnumServicesStatusEx[A/W]: - If lpServices is NULL or cbBufSize is less than sizeof(ENUM_SERVICE_STATUS_PROCESS) pass a pointer to an internal s
Passing [in] and [unique] to RQueryServiceonfigW is not a solution
either. It was a quick and dirty hack to get things working.
I'm working on a proper solution right now, unless you already have
something in your hat :-)
Le 13/08/2011 12:53, ek...@svn.reactos.org a écrit :
Author: ekohl
Date: Sat Aug 13 10:53:15 2011
New Revision: 53201
URL: http://svn.reactos.org/svn/reactos?rev=53201view=rev
Log:
[ADVAPI32]
Fix EnumServicesStatusEx[A/W]:
- If lpServices is NULL or cbBufSize is less than
sizeof(ENUM_SERVICE_STATUS_PROCESS) pass a pointer to an internal status buffer
to REnumServicesStatusExA/W. Adding 'in' and 'unique' attributes in the idl
file is NOT an option because this is not compatible with Windows.
- Check the InfoLevel.
Modified:
trunk/reactos/dll/win32/advapi32/service/scm.c
Modified: trunk/reactos/dll/win32/advapi32/service/scm.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/advapi32/service/scm.c?rev=53201r1=53200r2=53201view=diff
==
--- trunk/reactos/dll/win32/advapi32/service/scm.c [iso-8859-1] (original)
+++ trunk/reactos/dll/win32/advapi32/service/scm.c [iso-8859-1] Sat Aug 13
10:53:15 2011
@@ -1150,7 +1150,9 @@
LPDWORD lpResumeHandle,
LPCSTR pszGroupName)
{
+ENUM_SERVICE_STATUS_PROCESSA ServiceStatus;
LPENUM_SERVICE_STATUS_PROCESSA lpStatusPtr;
+DWORD dwBufferSize;
DWORD dwError;
DWORD dwCount;
@@ -1166,6 +1168,18 @@
{
SetLastError(ERROR_INVALID_HANDLE);
return FALSE;
+}
+
+if (lpServices == NULL ||
+cbBufSize sizeof(ENUM_SERVICE_STATUS_PROCESSA))
+{
+lpStatusPtr =ServiceStatus;
+dwBufferSize = sizeof(ENUM_SERVICE_STATUS_PROCESSA);
+}
+else
+{
+lpStatusPtr = (LPENUM_SERVICE_STATUS_PROCESSA)lpServices;
+dwBufferSize = cbBufSize;
}
RpcTryExcept
@@ -1174,8 +1188,8 @@
InfoLevel,
dwServiceType,
dwServiceState,
- (LPBYTE)lpServices,
- cbBufSize,
+ (LPBYTE)lpStatusPtr,
+ dwBufferSize,
pcbBytesNeeded,
lpServicesReturned,
lpResumeHandle,
@@ -1189,18 +1203,20 @@
if (dwError == ERROR_SUCCESS || dwError == ERROR_MORE_DATA)
{
-lpStatusPtr = (LPENUM_SERVICE_STATUS_PROCESSA)lpServices;
-for (dwCount = 0; dwCount *lpServicesReturned; dwCount++)
+if (InfoLevel == SC_ENUM_PROCESS_INFO)
{
-if (lpStatusPtr-lpServiceName)
-lpStatusPtr-lpServiceName =
-(LPSTR)((ULONG_PTR)lpServices +
(ULONG_PTR)lpStatusPtr-lpServiceName);
-
-if (lpStatusPtr-lpDisplayName)
-lpStatusPtr-lpDisplayName =
-(LPSTR)((ULONG_PTR)lpServices +
(ULONG_PTR)lpStatusPtr-lpDisplayName);
-
-lpStatusPtr++;
+for (dwCount = 0; dwCount *lpServicesReturned; dwCount++)
+{
+if (lpStatusPtr-lpServiceName)
+lpStatusPtr-lpServiceName =
+(LPSTR)((ULONG_PTR)lpServices +
(ULONG_PTR)lpStatusPtr-lpServiceName);
+
+if (lpStatusPtr-lpDisplayName)
+lpStatusPtr-lpDisplayName =
+(LPSTR)((ULONG_PTR)lpServices +
(ULONG_PTR)lpStatusPtr-lpDisplayName);
+
+lpStatusPtr++;
+}
}
}
@@ -1234,11 +1250,31 @@
LPDWORD lpResumeHandle,
LPCWSTR pszGroupName)
{
+ENUM_SERVICE_STATUS_PROCESSW ServiceStatus;
LPENUM_SERVICE_STATUS_PROCESSW lpStatusPtr;
+DWORD dwBufferSize;
DWORD dwError;
DWORD dwCount;
TRACE(EnumServicesStatusExW() called\n);
+
+if (InfoLevel != SC_ENUM_PROCESS_INFO)
+{
+SetLastError(ERROR_INVALID_LEVEL);
+return FALSE;
+}
+
+if (lpServices == NULL ||
+cbBufSize sizeof(ENUM_SERVICE_STATUS_PROCESSW))
+{
+lpStatusPtr =ServiceStatus;
+dwBufferSize = sizeof(ENUM_SERVICE_STATUS_PROCESSW);
+}
+else
+{
+lpStatusPtr = (LPENUM_SERVICE_STATUS_PROCESSW)lpServices;
+dwBufferSize = cbBufSize;
+}
RpcTryExcept
{
@@ -1246,8 +1282,8 @@
InfoLevel,
dwServiceType,
dwServiceState,
- (LPBYTE)lpServices,
- cbBufSize,
+
Re: [ros-dev] [ros-diffs] [jgardou] 53152: [RPCRT4] - restore lost ros specific change. Thanks Vic.
Don't worry, it's part of the plan!
Le 09/08/2011 23:29, Ged Murphy a écrit :
Call me nuts, but why don't you add a ros_diff patch so it doesn't get
lost again???
From: jgar...@svn.reactos.org
Sent: 09 August 2011 18:43
To: ros-di...@reactos.org
Subject: [ros-diffs] [jgardou] 53152: [RPCRT4] - restore lost ros
specific change. Thanks Vic.
Author: jgardou
Date: Tue Aug 9 17:43:37 2011
New Revision: 53152
URL: http://svn.reactos.org/svn/reactos?rev=53152view=rev
Log:
[RPCRT4]
- restore lost ros specific change.
Thanks Vic.
Modified:
trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c
Modified: trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c?rev=53152r1=53151r2=53152view=diff
==
--- trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c [iso-8859-1] (original)
+++ trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c [iso-8859-1] Tue Aug
9 17:43:37 2011
@@ -6159,6 +6159,7 @@
case RPC_FC_WCHAR:
case RPC_FC_SHORT:
case RPC_FC_USHORT:
+case RPC_FC_ENUM16:
{
USHORT d;
align_pointer(pStubMsg-Buffer, sizeof(USHORT));
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 53158: [TOOLS] - sync wpp, widl and wrc with wine 1.3.26
CMake users : please don't forget to rebuild your host tools :-) Non cmake user : don't worry, this user unfriendly-ness is being worked on. Le 10/08/2011 00:51, jgar...@svn.reactos.org a écrit : Author: jgardou Date: Tue Aug 9 22:51:55 2011 New Revision: 53158 URL: http://svn.reactos.org/svn/reactos?rev=53158view=rev Log: [TOOLS] - sync wpp, widl and wrc with wine 1.3.26 Added: trunk/reactos/tools/wrc/po.c (with props) Modified: trunk/reactos/include/host/nls.h trunk/reactos/include/host/wine/wpp.h trunk/reactos/tools/widl/client.c trunk/reactos/tools/widl/expr.c trunk/reactos/tools/widl/hash.c trunk/reactos/tools/widl/header.c trunk/reactos/tools/widl/header.h trunk/reactos/tools/widl/parser.l trunk/reactos/tools/widl/parser.tab.c trunk/reactos/tools/widl/parser.tab.h trunk/reactos/tools/widl/parser.y trunk/reactos/tools/widl/parser.yy.c trunk/reactos/tools/widl/proxy.c trunk/reactos/tools/widl/register.c trunk/reactos/tools/widl/server.c trunk/reactos/tools/widl/typegen.c trunk/reactos/tools/widl/typegen.h trunk/reactos/tools/widl/typelib.c trunk/reactos/tools/widl/typelib_struct.h trunk/reactos/tools/widl/utils.c trunk/reactos/tools/widl/utils.h trunk/reactos/tools/widl/widl.c trunk/reactos/tools/widl/widl.h trunk/reactos/tools/widl/widl.rbuild trunk/reactos/tools/widl/widltypes.h trunk/reactos/tools/widl/write_msft.c trunk/reactos/tools/wpp/lex.yy.c trunk/reactos/tools/wpp/ppl.l trunk/reactos/tools/wpp/ppy.tab.c trunk/reactos/tools/wpp/ppy.tab.h trunk/reactos/tools/wpp/ppy.y trunk/reactos/tools/wpp/preproc.c trunk/reactos/tools/wpp/wpp.c trunk/reactos/tools/wpp/wpp_private.h trunk/reactos/tools/wrc/CMakeLists.txt trunk/reactos/tools/wrc/dumpres.c trunk/reactos/tools/wrc/genres.c trunk/reactos/tools/wrc/lex.yy.c trunk/reactos/tools/wrc/newstruc.c trunk/reactos/tools/wrc/newstruc.h trunk/reactos/tools/wrc/parser.h trunk/reactos/tools/wrc/parser.l trunk/reactos/tools/wrc/parser.tab.c trunk/reactos/tools/wrc/parser.tab.h trunk/reactos/tools/wrc/parser.y trunk/reactos/tools/wrc/translation.c trunk/reactos/tools/wrc/utils.c trunk/reactos/tools/wrc/utils.h trunk/reactos/tools/wrc/wrc.c trunk/reactos/tools/wrc/wrc.h trunk/reactos/tools/wrc/wrc.rbuild trunk/reactos/tools/wrc/wrcrostypes.h trunk/reactos/tools/wrc/wrctypes.h [This mail would be too long, it was shortened to contain the URLs only.] Modified: trunk/reactos/include/host/nls.h URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/host/nls.h?rev=53158r1=53157r2=53158view=diff Modified: trunk/reactos/include/host/wine/wpp.h URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/host/wine/wpp.h?rev=53158r1=53157r2=53158view=diff Modified: trunk/reactos/tools/widl/client.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/client.c?rev=53158r1=53157r2=53158view=diff Modified: trunk/reactos/tools/widl/expr.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/expr.c?rev=53158r1=53157r2=53158view=diff Modified: trunk/reactos/tools/widl/hash.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/hash.c?rev=53158r1=53157r2=53158view=diff Modified: trunk/reactos/tools/widl/header.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/header.c?rev=53158r1=53157r2=53158view=diff Modified: trunk/reactos/tools/widl/header.h URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/header.h?rev=53158r1=53157r2=53158view=diff Modified: trunk/reactos/tools/widl/parser.l URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/parser.l?rev=53158r1=53157r2=53158view=diff Modified: trunk/reactos/tools/widl/parser.tab.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/parser.tab.c?rev=53158r1=53157r2=53158view=diff Modified: trunk/reactos/tools/widl/parser.tab.h URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/parser.tab.h?rev=53158r1=53157r2=53158view=diff Modified: trunk/reactos/tools/widl/parser.y URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/parser.y?rev=53158r1=53157r2=53158view=diff Modified: trunk/reactos/tools/widl/parser.yy.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/parser.yy.c?rev=53158r1=53157r2=53158view=diff Modified: trunk/reactos/tools/widl/proxy.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/proxy.c?rev=53158r1=53157r2=53158view=diff Modified: trunk/reactos/tools/widl/register.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/register.c?rev=53158r1=53157r2=53158view=diff Modified: trunk/reactos/tools/widl/server.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/server.c?rev=53158r1=53157r2=53158view=diff Modified:
Re: [ros-dev] [ros-diffs] [jgardou] 53085: [FREELDR] - Add back apparently lost line of r52098. Patch by Alex Ionescu, tested by Igor Paliychuk. See issue #6292 for more details.
Credits go to Cameron Gutman for the idea.
Le 05/08/2011 19:54, jgar...@svn.reactos.org a écrit :
Author: jgardou
Date: Fri Aug 5 17:54:06 2011
New Revision: 53085
URL: http://svn.reactos.org/svn/reactos?rev=53085view=rev
Log:
[FREELDR]
- Add back apparently lost line of r52098.
Patch by Alex Ionescu, tested by Igor Paliychuk.
See issue #6292 for more details.
Modified:
trunk/reactos/boot/freeldr/freeldr/arcemul/mm.c
Modified: trunk/reactos/boot/freeldr/freeldr/arcemul/mm.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arcemul/mm.c?rev=53085r1=53084r2=53085view=diff
==
--- trunk/reactos/boot/freeldr/freeldr/arcemul/mm.c [iso-8859-1] (original)
+++ trunk/reactos/boot/freeldr/freeldr/arcemul/mm.c [iso-8859-1] Fri Aug 5
17:54:06 2011
@@ -30,6 +30,7 @@
{ { MemoryFirmwareTemporary, 0x80, 0x10 }, 4, }, // File system read
buffer. FILESYSBUFFER
{ { MemoryFirmwareTemporary, 0x90, 0x10 }, 5, }, // Disk read buffer for
int 13h. DISKREADBUFFER
{ { MemoryFirmwarePermanent, 0xA0, 0x60 }, 6, }, // ROM / Video
+ { { MemorySpecialMemory, 0xFFF, 1 }, 7, }, // unusable memory
#elif __arm__ // This needs to be done per-platform specific way
#endif
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Broken Windows_AMD64_1 VBox-Test
Hi! Author: osiejka Date: Tue Aug 2 22:54:30 2011 New Revision: 53038 URL:http://svn.reactos.org/svn/reactos?rev=53038view=rev Log: [CSRSRV] - don't hack the dll entry point name. Patch by Thomas Faber I think this fixed it, no? Le 03/08/2011 09:06, James Tabor a écrit : Hi! I think this broke it [ros-diffs] [jgardou] 53025: [CMAKE/GCC] - fix entry point for native dlls Thanks, James ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 52840: [CRT] - get back atexit handling as it was before. (reverts 52838, 52829, 52828) Thanks to Kai and Timo for the explanation
Reverts 52836, 52829 and 52828, sorry. Le 24/07/2011 18:45, jgar...@svn.reactos.org a écrit : Author: jgardou Date: Sun Jul 24 16:45:41 2011 New Revision: 52840 URL: http://svn.reactos.org/svn/reactos?rev=52840view=rev Log: [CRT] - get back atexit handling as it was before. (reverts 52838, 52829, 52828) Thanks to Kai and Timo for the explanation Modified: trunk/reactos/dll/win32/msvcrt/msvcrt.spec trunk/reactos/dll/win32/msvcrt20/msvcrt20.spec trunk/reactos/dll/win32/msvcrt40/msvcrt40.spec trunk/reactos/lib/3rdparty/mingw/crtexe.c trunk/reactos/lib/3rdparty/mingw/mingw.rbuild trunk/reactos/lib/sdk/crt/msvcrtex.cmake trunk/reactos/lib/sdk/crt/startup/crtdll.c trunk/reactos/lib/sdk/crt/startup/crtexe.c Modified: trunk/reactos/dll/win32/msvcrt/msvcrt.spec URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msvcrt/msvcrt.spec?rev=52840r1=52839r2=52840view=diff == --- trunk/reactos/dll/win32/msvcrt/msvcrt.spec [iso-8859-1] (original) +++ trunk/reactos/dll/win32/msvcrt/msvcrt.spec [iso-8859-1] Sun Jul 24 16:45:41 2011 @@ -1156,7 +1156,7 @@ @ cdecl asin(double) @ cdecl atan(double) @ cdecl atan2(double double) -@ cdecl atexit(ptr) +@ extern atexit #-- keep this as an extern, thank you @ cdecl atof(str) @ cdecl atoi(str) @ cdecl atol(str) Modified: trunk/reactos/dll/win32/msvcrt20/msvcrt20.spec URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msvcrt20/msvcrt20.spec?rev=52840r1=52839r2=52840view=diff == --- trunk/reactos/dll/win32/msvcrt20/msvcrt20.spec [iso-8859-1] (original) +++ trunk/reactos/dll/win32/msvcrt20/msvcrt20.spec [iso-8859-1] Sun Jul 24 16:45:41 2011 @@ -937,7 +937,7 @@ @ cdecl asin(double) @ cdecl atan(double) @ cdecl atan2(double double) -@ cdecl atexit(ptr) +@ extern atexit #-- do not touch this! @ cdecl atof(str) @ cdecl atoi(str) @ cdecl atol(str) Modified: trunk/reactos/dll/win32/msvcrt40/msvcrt40.spec URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msvcrt40/msvcrt40.spec?rev=52840r1=52839r2=52840view=diff == --- trunk/reactos/dll/win32/msvcrt40/msvcrt40.spec [iso-8859-1] (original) +++ trunk/reactos/dll/win32/msvcrt40/msvcrt40.spec [iso-8859-1] Sun Jul 24 16:45:41 2011 @@ -975,7 +975,7 @@ @ cdecl asin(double) @ cdecl atan(double) @ cdecl atan2(double double) -@ cdecl atexit(ptr) +@ extern atexit #-- changing this will kill your cat, understand? @ cdecl atof(str) @ cdecl atoi(str) @ cdecl atol(str) Modified: trunk/reactos/lib/3rdparty/mingw/crtexe.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/3rdparty/mingw/crtexe.c?rev=52840r1=52839r2=52840view=diff == --- trunk/reactos/lib/3rdparty/mingw/crtexe.c [iso-8859-1] (original) +++ trunk/reactos/lib/3rdparty/mingw/crtexe.c [iso-8859-1] Sun Jul 24 16:45:41 2011 @@ -71,8 +71,8 @@ /* TLS initialization hook. */ extern const PIMAGE_TLS_CALLBACK __dyn_tls_init_callback; -//extern _PVFV *__onexitbegin; -//extern _PVFV *__onexitend; +extern _PVFV *__onexitbegin; +extern _PVFV *__onexitend; extern int mingw_app_type; @@ -119,7 +119,7 @@ __set_app_type(_GUI_APP); else __set_app_type (_CONSOLE_APP); -// __onexitbegin = __onexitend = (_PVFV *) _encode_pointer ((_PVFV *)(-1)); + __onexitbegin = __onexitend = (_PVFV *) _encode_pointer ((_PVFV *)(-1)); * __MINGW_IMP_SYMBOL(_fmode) = _fmode; * __MINGW_IMP_SYMBOL(_commode) = _commode; Modified: trunk/reactos/lib/3rdparty/mingw/mingw.rbuild URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/3rdparty/mingw/mingw.rbuild?rev=52840r1=52839r2=52840view=diff == --- trunk/reactos/lib/3rdparty/mingw/mingw.rbuild [iso-8859-1] (original) +++ trunk/reactos/lib/3rdparty/mingw/mingw.rbuild [iso-8859-1] Sun Jul 24 16:45:41 2011 @@ -12,7 +12,7 @@ include base=ReactOSinclude/reactos/mingw-w64/include librarykernel32/library file_newmode.c/file - !--fileatonexit.c/file-- + fileatonexit.c/file filebinmode.c/file filecharmax.c/file filecinitexe.c/file Modified: trunk/reactos/lib/sdk/crt/msvcrtex.cmake URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/sdk/crt/msvcrtex.cmake?rev=52840r1=52839r2=52840view=diff == --- trunk/reactos/lib/sdk/crt/msvcrtex.cmake [iso-8859-1] (original) +++ trunk/reactos/lib/sdk/crt/msvcrtex.cmake [iso-8859-1] Sun Jul 24 16:45:41 2011 @@ -17,7 +17,7 @@ startup/natstart.c startup/charmax.c startup/merr.c -#startup/atonexit.c +startup/atonexit.c startup/txtmode.c
Re: [ros-dev] cmake rant
+1 for Ged. Le 21/07/2011 18:51, Ged Murphy a écrit : I'm all for deleting rbuild now and dealing with the consequences. That would be better than the current situation, which seems rather ridiculous at the moment. Right now if you change something, you have to : - edit the cmakefiles.txt file - edit the rbuild file - possibly edit a pspec and spec file - build with rbuild to check for breakages - build with cmake to check for breakages Only then can you commit your changes. It's not ideal for the people working on this stuff regularly. Ged. -Original Message- From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On Behalf Of Timo Kreuzer Sent: 21 July 2011 17:39 To: ReactOS Development List Subject: [ros-dev] cmake rant Hi, Several times now cmake build has been broken. Time for some action! Last meeting I asked everyone to test/use cmake. It was also mentioned that if questions arise, we (Amine and me) would be happy to help out. I can't remember anyone has asked how it works, so I assume noone had any problems. There's also a pretty good wiki entry describing the whole procedure for n00bs. Now people tell me it's complicated, people are complaining that its ridiculous to have 2 build systems, etc. And probably noone has ever tried it. We really need to move on. I don't like having 2 build systems as well. Current blocker is the debugging which has some issues, Arty is working on that. Another problem is a boot problem on real hardware, but no I don't know on which configuration it doesn't work, so we need more people testing it on their real hardware setup and report any issues. Here's a list with current issues: http://www.reactos.org/wiki/CMake_Todo So please: If you are missing something, let us know. If you like to make it better, make suggestions. But stop ignoring cmake! If noone cares and everyone just thinks he can give a s^Z damn until we officially switch, then we can as well delete all cmake stuff and keep rbuild. It has a lot of awesome advantages, like you only have to type one command to build everything and you don't need to install cmake and you can export whatever you want from kernel32 even if the functions don't exist. Also you can enjoy the rbuild-loop again and again. Or we can do it the hard way and delete rbuild, so people are forced to use cmake. I'm sure this approach would be *really* appreaciated. Thanks, Timo ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Monthly meeting reminder
Hi! I'll gladly participate this time. By the way, can I be added to te list? Regards. Jérôme. Le 26/06/2011 19:56, Aleksey Bragin a écrit : Colin, thanks for providing all required information and setting up the irc server. Just a small correction - the list of allowed participants now includes Alex Ionescu. Yes, I beg my pardon about the time, the meeting is going to take place at 19:00 UTC. Don't forget to update your calendars! Updated agenda: 1. Cmake switching 2. New release of ReactOS 3. Website work status 4. GSoC status 5. Developers status. I don't think we should add more topics, otherwise meeting will take too much time. (e.g. DLL wine sync questions could be solved during new release discussion). WBR, Aleksey. On Jun 26, 2011, at 5:23 PM, Colin Finck wrote: Aleksey Bragin alek...@reactos.org wrote: Last thursday of this month is quite close, 30th of June, 20:00 UTC We have voted to begin all further meetings at 19:00 UTC in the last meeting. Colin said that our private irc server is going to be ready by that date, so if that's still true, Colin - could you please provide details for those who don't remember where to connect? Yes, the crash we experienced in March has been fixed, so we can use our own server with one-time passwords, logging, voting capabilities and without the possibility of netsplits again. The meeting will be at irc://fezile.reactos.org (Port 6667, no SSL) in the channel #meeting. Note that the IRC service will only be started shortly before the meeting. Please take a look at the list of participants below and reply instantly if your name is missing. The list really matters this time as it is maintained in the IRC server and you won't get a one-time password if you're not on the list. Observers can always join without being on the list, but not participate in the discussions and votings then. I will wait for additional names till Wednesday before sending out the passwords. Aleksey, please also address the recent inquiries about additional points on the meeting agenda and publish an updated agenda. - Colin List of participants = - Giannis Adamopoulos (smiley1_) - Johannes Anderwald (janderwald) - Javier Agustìn Fernàndez Arroyo (elhoir) - Maciej Bialas (niski) - Jan Blomqvist-Kinander (JaixBly) - Aleksey Bragin (abragin) - Thomas Faber (ThFabba) - Colin Finck (Colin_Finck) - Danny Götte (dangerground) - Andrew Green (greeniekin) - Cameron Gutman (aicom) - Ziliang Guo (ZWabbit) - Rafal Harabien (rafalh) - Andrew Hill (ash77) - Kamil Hornicek (Pigglesworth) - Gabriel Ilardi (gabriel_it) - Amine Khaldi (AmineKhaldi) - Timo Kreuzer (tkreuzer) - Matthias Kupfer (Collibri) - Michael Martin (mjmartin) - Victor Martinez (vicmarcal) - Roel Messiant (Mephisto) - Claudiu Mihail (KlausM) - Andrew Munger (WaxDragon) - Ged Murphy (GedMurphy) - Sylvain Petreolle (Usurp) - Hervé Poussineau (hpoussin) - Daniel Reimer (dreimer) - Pierre Schweitzer (HeisSpiter) - Samuel Serapion (encoded) - Olaf Siejka (Caemyr) - James Tabor (jimtabor) - Christoph von Wittich (Christoph_vW) - Neeraj Yadav (neeraj_rct) - Art Yerkes (arty) ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 52339: [NTOSKRNL] - don't rely on a boolean being 1 or 0, it's a bad idea (tm)
Well, just try this snippet of code in VS 2010, and tell me what you see
as result :-)
BOOLEAN is what it is : a typedef to BYTE.
PS : no fancy optimization option or whatever
// test_boolean.cpp : définit le point d'entrée pour l'application console.
//
#include iostream
#include Windows.h
#include tchar.h
using namespace std;
BOOLEAN test0x10(int i)
{
return i 0x10;
}
int _tmain(int argc, _TCHAR* argv[])
{
if(test0x10(0x10) == 1)
cout Alex Ionescu is right endl;
else if(test0x10(0x10))
cout Sometimes Alex Ionescu is wrong endl;
else
cout Unexpected behaviour!!! endl;
return 0;
}
Le 18/06/2011 17:22, Alex Ionescu a écrit :
Or rather
1 ? 1 : 0
(just as retarded).
Of course a BOOLEAN is 0 or 1!!!
Best regards,
Alex Ionescu
On Sat, Jun 18, 2011 at 4:22 PM, Alex Ionescuion...@videotron.ca wrote:
???
This is retarded.
You're doing
0 ? 0 : 1
Best regards,
Alex Ionescu
On Sat, Jun 18, 2011 at 3:45 PM,jgar...@svn.reactos.org wrote:
Author: jgardou
Date: Sat Jun 18 14:45:08 2011
New Revision: 52339
URL: http://svn.reactos.org/svn/reactos?rev=52339view=rev
Log:
[NTOSKRNL]
- don't rely on a boolean being 1 or 0, it's a bad idea (tm)
Modified:
trunk/reactos/ntoskrnl/ke/i386/traphdlr.c
Modified: trunk/reactos/ntoskrnl/ke/i386/traphdlr.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/traphdlr.c?rev=52339r1=52338r2=52339view=diff
==
--- trunk/reactos/ntoskrnl/ke/i386/traphdlr.c [iso-8859-1] (original)
+++ trunk/reactos/ntoskrnl/ke/i386/traphdlr.c [iso-8859-1] Sat Jun 18 14:45:08
2011
@@ -1510,7 +1510,7 @@
/* Set thread fields */
Thread-TrapFrame = TrapFrame;
-Thread-PreviousMode = KiUserTrap(TrapFrame);
+Thread-PreviousMode = KiUserTrap(TrapFrame) ? UserMode : KernelMode;
/* Enable interrupts */
_enable();
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 52339: [NTOSKRNL] - don't rely on a boolean being 1 or 0, it's a bad idea (tm)
I'm not confonding anything, I just consider that calling a function
which returns a BOOLEAN expecting it will return 0 or 1 is a bad idea,
because someone might have written the exact same function I've shown
you as an example.
As a general rule, consider something true when it's not false :-).
Le 19/06/2011 15:29, Alex Ionescu a écrit :
This is a completely different issue. You're confusing bitmask math
with BOOLEAN.
Best regards,
Alex Ionescu
2011/6/19 Jérôme Gardoujerome.gar...@laposte.net:
Well, just try this snippet of code in VS 2010, and tell me what you see as
result :-)
BOOLEAN is what it is : a typedef to BYTE.
PS : no fancy optimization option or whatever
// test_boolean.cpp : définit le point d'entrée pour l'application console.
//
#includeiostream
#includeWindows.h
#includetchar.h
using namespace std;
BOOLEAN test0x10(int i)
{
return i 0x10;
}
int _tmain(int argc, _TCHAR* argv[])
{
if(test0x10(0x10) == 1)
cout Alex Ionescu is right endl;
else if(test0x10(0x10))
cout Sometimes Alex Ionescu is wrong endl;
else
cout Unexpected behaviour!!! endl;
return 0;
}
Le 18/06/2011 17:22, Alex Ionescu a écrit :
Or rather
1 ? 1 : 0
(just as retarded).
Of course a BOOLEAN is 0 or 1!!!
Best regards,
Alex Ionescu
On Sat, Jun 18, 2011 at 4:22 PM, Alex Ionescuion...@videotron.cawrote:
???
This is retarded.
You're doing
0 ? 0 : 1
Best regards,
Alex Ionescu
On Sat, Jun 18, 2011 at 3:45 PM,jgar...@svn.reactos.orgwrote:
Author: jgardou
Date: Sat Jun 18 14:45:08 2011
New Revision: 52339
URL: http://svn.reactos.org/svn/reactos?rev=52339view=rev
Log:
[NTOSKRNL]
- don't rely on a boolean being 1 or 0, it's a bad idea (tm)
Modified:
trunk/reactos/ntoskrnl/ke/i386/traphdlr.c
Modified: trunk/reactos/ntoskrnl/ke/i386/traphdlr.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/traphdlr.c?rev=52339r1=52338r2=52339view=diff
==
--- trunk/reactos/ntoskrnl/ke/i386/traphdlr.c [iso-8859-1] (original)
+++ trunk/reactos/ntoskrnl/ke/i386/traphdlr.c [iso-8859-1] Sat Jun 18
14:45:08 2011
@@ -1510,7 +1510,7 @@
/* Set thread fields */
Thread-TrapFrame = TrapFrame;
-Thread-PreviousMode = KiUserTrap(TrapFrame);
+Thread-PreviousMode = KiUserTrap(TrapFrame) ? UserMode :
KernelMode;
/* Enable interrupts */
_enable();
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] 1296 [dreimer] Get the cmake path from a system variable called _ROSBE_CMAKEPATH. Hard coding is eeevul!
Guess what... Cmake provides such a GUI Le 03/06/2011 12:26, victor martinez a écrit : I am agree with Colin. The idea of having a Build Environment is not just to make the life easier to our devs, but also to have ISOs which we can compare. If the Environment doesnt bundle *ALL* the tools, then we can have devs/testers with different Tools combinations...it can lead to break walls with our head. Also we should try to do the compilation as easier as possible, why not creating RosBE 2.0 with GUI frontend? :3 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] 1296 [dreimer] Get the cmake path from a system variable called _ROSBE_CMAKEPATH. Hard coding is eeevul!
Fact is that we currently use the bleeding edge fersion of cmake, and we may be ahead of it. And it's not that big actually. Le 03/06/2011 00:01, Zachary Gorden a écrit : I object highly to the idea of bundling cmake with the BE. Most platforms already have binaries built of cmake, either by the distro or for Windows, the people who make cmake provide an installer. We provide the compilers and linkers and we provided rbuild because it was our own thing, but cmake is not and has its own environment. On Thu, Jun 2, 2011 at 4:53 PM, Colin Finck co...@reactos.org mailto:co...@reactos.org wrote: drei...@svn.reactos.org mailto:drei...@svn.reactos.org wrote: Get the cmake path from a system variable called _ROSBE_CMAKEPATH. I hope we're not thinking about requiring the user to install RosBE and CMake separately. This would pretty much kill the point of RosBE if people are forced to get random versions of their build tools from multiple sources again.. - Colin ___ Ros-dev mailing list Ros-dev@reactos.org mailto:Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
[ros-dev] Fwd: [NOTEPAD] Patch by Edijs Kolesnikovics: Write default font, weight and point...
SaveDword(hKey, _T(iPointSize), Globals.lfFont.lfHeight); shouldn't it be SaveDword(hKey, _T(iPointSize), PointSizeFromHeight(Globals.lfFont.lfHeight)); Also, this would permit to simplify code a bit :-) http://cia.vc/stats/project/ReactOS/.message/3522f92 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Meeting on Thursday
Unfortunately, I won't be able to make it either. By the way, even if my late activity is hindered by life schedule being quite erratic, could I request the honor of being considered as a ReactOS team member. I'm looking forward the results of this meeting. Best regards. Jérôme. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 50991: [NTOSKRNL] - Print supported CPU features. - Simplify detection of non working but claimed SYSENTER support for intel processors - Workaround a virtualbox f
Official intel documentation :
http://www.intel.com/Assets/PDF/appnote/241618.pdf, page 30.
As to know how it's made on windows, well, I hope they follow intel docs ;-)
Le 07/03/2011 21:49, Aleksey Bragin a écrit :
On Mar 7, 2011, at 4:33 PM, jgar...@svn.reactos.org wrote:
Author: jgardou
/* Check if the CPU is too old to support SYSENTER */
-if ((Prcb-CpuType 6) ||
-((Prcb-CpuType == 6) (Prcb-CpuStep 0x0303)))
+if ((Reg[0] 0x0FFF3FFF) 0x0633)
{
It was intentionally done over CpuType and CpuStep. Now you criptified
it back to a raw Reg[0] value and weird hardcoded constant. Could you
please 1) elaborate this change and 2) if you still think it's
correct, and if you still tihnk(!) Windows does it same way, then
rework it to use Prcb-Cpu* instead of these magic values?
Not to say adding a hack for VirtualBox is far from being a beautiful,
and would need to be *at least* marked so that it's not forgotten.
Thanks,
Aleksey Bragin.
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [tkreuzer] 50942: [WIN32K] Do raster operation on 4 bytes instead of only 3. Fixes ... maybe noone has noticed yet ; -)
Colin Finck a écrit : tkreu...@svn.reactos.org wrote: Do raster operation on 4 bytes instead of only 3. Quoting jgardou's commit before: - When applying raster operation, do so only on 24 bits, we don't support alpha channel in win32k I have no idea about DIB code, but just from the commit message I presume that this change to 24 bits has happened deliberately. - Colin ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev You broke VLC icons in 32bpp ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Getting a Windows Server 2003 license for the project?
I for one, only have a winXP pro license on which I do my tests. Le 14/01/2011 16:46, Colin Finck a écrit : Hi everybody, I've been thinking about getting a license of an English Windows Server 2003 Standard 32-Bit for the project. It could be installed on one of our servers and be made available over RDP. This would enable project members to do development and testing work on our actual target platform. Considering that some developers even use a non-Windows platform for development work, it might simplify their work as well. We may as well use the license for other purposes (Buildslave, Testslave, whatever), but at least native building could be done by any Windows version. And in this case, I might be able to donate an XP Pro license myself (German though). As I don't know about the needs of the other members, I'd like to hear your opinion about my idea. It would also be nice to hear if anybody knows a cheap (but legal!) way to get such a license or can even donate one (e.g. unused OEM license shipped with a server, unused license after getting Server 2008, etc.) English Windows licenses are rare/expensive on German eBay, so this would only be a last resort :-) Cheers, Colin P.S.: If you have the opposite problem and actually need a Linux VM available over SSH/RDP (e.g. for testing build system changes), just let me know and I could set it up. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] ReactOS official compatibility target and the new build system
Then let's have a kernelbase.dll, as win7 does. Le 13/11/2010 12:16, Timo Kreuzer a écrit : I have thought about the multiple Windows version thing some time ago and had some ideas. One idea is to Reorganize the functionality, similar to the way it's done in Windows 7. some of the win32 dlls would become wrapper dlls and forwarding to the actual implementations. These wrapper dlls would be tiny and we could have different sets of wrapper dlls for different windows versions. They might also forward to different implementations of the same api on different versions if required. This could be done on runtime, with something similar to sxs, only user configurable rather than manifest based. So instead of importing the vista function RegDeleteTree from kernel32.dll a wine dll would import it from something like API-ROS-Core-Registry.dll This way we could as well cleanup our dependency tree and layout stuff more window 7 alike ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] ReactOS official compatibility target and the new build system
So, for kernel we keep our own importibs, adding exports one after the other while we implement them, and for user mode dlls we keep win7 compatible ones? We need an official stance on this matter. Le 13/11/2010 03:10, Ged Murphy a écrit : The target is only win2k3 in the kernel. Everything else is open to discussion (in fact, IMO even the kernel compatibility is open to discussion) You should, and must, provide as much functionality as possible with the latest versions of Windows. You can still provide many of the capabilities of Windows 7 using only an NT5.2 kernel. It's only the internal architecture which limits this, and in terms of many win7 capabilities, this kernel isn't a limiting factor. 2010/11/13 Jérôme Gardou jerome.gar...@laposte.net mailto:jerome.gar...@laposte.net As our target is win2k3 sp1 compatibility, ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] ReactOS official compatibility target and the new build system
Imagine an even worse written application : fptr = GetProcAdress(hDll, SomeVistaExport); if(fptr) Vista = TRUE; I know at least one application that does it, and this is... wine tests! Le 13/11/2010 19:41, Colin Finck a écrit : Ged Murphy gedmur...@gmail.com wrote: Usermode should and does report as NT5.2. It actually doesn't have a choice as the APIs which you use in usermode to discover the version (GetVersionEx, VerifyVersionInfo) actually query hardcoded values stored in the kernel. Sure, but you don't consider the example I've given (VMware Tools Installer). We were already reporting ReactOS as NT 5.2 at that time, but obviously the installer just queried the msvcrt.dll version to determine its features. And when finding out that it's 42.4.0.0, it consequently expected Vista features we were missing. What I want to say is that we cannot just report ReactOS as NT 5.2 through the common version functions, but also need to ensure that the DLLs have the same versions as their NT 5.2 counterparts. And when this has been changed, adding APIs of newer Windows versions (like wcsncpy_s) would hardly make any sense if we don't need them to please some Wine-synced DLLs using newer APIs. Colin ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 49396: [CMAKE] - put ntdll.def in source files
This should work now. Thanks for reporting.
Ged Murphy wrote:
I've just tried to build the cmake branch for the first time and hit the
following error :
-- xmllite has no base address
-- win32csr has no base address
-- Configuring done
CMake Error in dll/ntdll/CMakeLists.txt:
Cannot find source file ntdll.def. Tried extensions .c .C .c++ .cc .cpp
.cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx
Reverting the changes in this revision fixed it.
I know nothing about cmake, but this change appears to have broken the build?
Ged.
-Original Message-
From: ros-diffs-boun...@reactos.org [mailto:ros-diffs-boun...@reactos.org] On
Behalf Of jgar...@svn.reactos.org
Sent: 01 November 2010 09:32
To: ros-di...@reactos.org
Subject: [ros-diffs] [jgardou] 49396: [CMAKE] - put ntdll.def in source files
Author: jgardou
Date: Mon Nov 1 09:32:04 2010
New Revision: 49396
URL: http://svn.reactos.org/svn/reactos?rev=49396view=rev
Log:
[CMAKE]
- put ntdll.def in source files
Modified:
branches/cmake-bringup/dll/ntdll/CMakeLists.txt
Modified: branches/cmake-bringup/dll/ntdll/CMakeLists.txt
URL:
http://svn.reactos.org/svn/reactos/branches/cmake-bringup/dll/ntdll/CMakeLists.txt?rev=49396r1=49395r2=49396view=diff
==
--- branches/cmake-bringup/dll/ntdll/CMakeLists.txt [iso-8859-1] (original)
+++ branches/cmake-bringup/dll/ntdll/CMakeLists.txt [iso-8859-1] Mon Nov 1
09:32:04 2010
@@ -21,10 +21,8 @@
rtl/libsupp.c
rtl/version.c
def/ntdll.rc
-def/ntdll.def)
+${CMAKE_CURRENT_BINARY_DIR}/def/ntdll.def)
-set_source_files_properties(def/ntdll.def PROPERTIES EXTERNAL_OBJECT TRUE)
-
if(ARCH MATCHES i386)
list(APPEND SOURCE dispatch/i386/dispatch.S)
elseif(ARCH MATCHES amd64)
@@ -48,7 +46,6 @@
endif()
target_link_libraries(ntdll
-${CMAKE_CURRENT_BINARY_DIR}/def/ntdll.def
ntdllsys
libcntpr
pseh)
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
[ros-dev] Static - dynamic generation of reactos.dff
Hi reactos developers. As many of you know, the cmake branch development is going along and is the occasion of many innovations in the way reactos is built. One of this way is the reactos.dff file. Currently, it is a static file, meaning that each time you want to add a module to reactos, you have to edit this file. What I propose is to create this file dynamically, when parsing the build system file. Adding a reactos module twould then be as simple as (!) creating a new build file for this module. For those who are concerned about slipstreaming or optional files like wallpapers or whatever hacking they do with the current reactos.dff, it will be as easy as before. There will be a file to edit, which will be the static part of it. Whatever you'll write in this file will be written back to reactos.dff, so there is no need to worry about that. What do you think? Regards. Jérôme. PS : The patch is there. It waits for your approval :-) ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 48359: [WIN32K] - Rewrite NtGdiGetDIBitsInternal, with WINE as a reference. - Get back DIB Section creation to classic BITMAPINFO. This si the beginnig of the end f
Timo Kreuzer wrote: Jérôme Gardou schrieb: That's why I began to revert all of this stuff, which is horrible :-) While I completely agree on removing BITMAPCOREHEADER support, I don't really like other parts. - Probing the BITMAPINFO and then passing the usermode buffer to the internal and unprotected function is not enough. The buffer must be copied. OK, it's safer this way. - The BITMAPV5HEADER is only ~120 bytes and only used once per function call, so putting the safe buffer on the stack is appropriate. The buffer needs be large enough for V5 anyway, so why not fixup some values and make it a full V5 header? No, all values added by V4/V5 headers are for ICM. If there is only a BITMAPINFOHEADER there, then we don't have to care about ICM. If we convert it to a V5 header, all values will be 0, that's not worth the effort. - The ProbeAndConvert function was added to simplify the code and move all code that handles the small differences into one central place instead of having a bunch of if (size bla) checks in multiple places just to check whether I can or can not access some member of the BITMAPINFO or where to get the color masks from. With the conversion all of the internal code can work the same simple way assuming a full BITMAPV5INFO is available. The only effort to make here is to take care of where the color buffer is : bmi + bmi-bmiHeader.biSize and not bmi-bmiColors. Then check in some functions if we have a V4/V5 header to take care of the features they have. If we're good enough, we'll just need to call DIB_CreateDIBSection, and work with this bitmap created here. That's what I did in NtGdiStretchBitmapInternal, NtGdiGetDIBits and IntGdiSetDIBits. The major problem is to get the palette created properly. - When support for BITMAPCOREHEADER gets removed the code become much less horrible Agree. Timo Jérôme. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 48359: [WIN32K] - Rewrite NtGdiGetDIBitsInternal, with WINE as a reference. - Get back DIB Section creation to classic BITMAPINFO. This si the beginnig of the end f
That's why I began to revert all of this stuff, which is horrible :-) Regards. Jérôme. James Tabor wrote: Hi! BitmapCoreInfo !Should Be! handled in Gdi32 and converted there! The latest BitmapInfo must be handled in win32k. So not get it confused. James ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [akhaldi] 48236: Create a branch forcmake bringup.
Having a proper build system and a good tree structure is a mandatory step to work efficiently. As long as we have neither of them, it is a priority. That's just my opinion, though... Gabriel ilardi wrote: I think that the tree reshuffle should be done separately from the cmake branch. I also agree with Ged that it isn't very logical, so from this point of view I support the tree restructure. On the other hand ReactOS is in a really bad shape form a user point of view and all the resources should focus on fix the most important bugs and regressions listed in http://www.reactos.org/wiki/Buglist. The rest of the things is of a minor importance to me. We can't do everything at the same time, we should focus and things of major importance at the moment. Just my 2 cents. Gabriel. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Tree restructure
I’d much prefer to go to the audio directory to work on everything from portcls.sys up to mmsys.cpl. Things could be committed together instead of separately forcing 2 separate builds on buildbot Yes, but imagine someone who's going to work on Control Panel Applets, e.g. a UI person (if we had one), who would need to work with all CPLs in the system. He would need to find them throughout whole tree, ask in ros-dev ML if he missed any and abandon his idea soon after starting. Isn't it possible to do hard links with svn, git or whatever? So as in your example, mmsys.cpl would be located in the audio sub tree, and hardlinked to the UI/cpl directory. All modern filesystems support hard links, that wouldn't suprise me if modern version control systems would do the same. What do you think? ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Tree restructure
And here is what I said. http://svnbook.red-bean.com/en/1.0/ch07s03.html Jérôme Gardou wrote: I’d much prefer to go to the audio directory to work on everything from portcls.sys up to mmsys.cpl. Things could be committed together instead of separately forcing 2 separate builds on buildbot Yes, but imagine someone who's going to work on Control Panel Applets, e.g. a UI person (if we had one), who would need to work with all CPLs in the system. He would need to find them throughout whole tree, ask in ros-dev ML if he missed any and abandon his idea soon after starting. Isn't it possible to do hard links with svn, git or whatever? So as in your example, mmsys.cpl would be located in the audio sub tree, and hardlinked to the UI/cpl directory. All modern filesystems support hard links, that wouldn't suprise me if modern version control systems would do the same. What do you think? ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [akhaldi] 48236: Create a branch for cmake bringup.
wasn't there already a branch for that task? Zachary Gorden wrote: I also support a reshuffling of the directories, but not in the cmake branch. Let that be used JUST for getting cmake up and running and if/once that is merged into trunk, then we look into changing the structure. Best not to complicate one task by adding more to it. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [dreimer] 48036: Bug 5501: [PATCH] Adding Wing32support by Carlo Bramini
Alphabetical reordering ? Aleksey Bragin wrote: What's that massive reactos.dff change introduced with this rev? -- From: drei...@svn.reactos.org Sent: Wednesday, July 14, 2010 2:59 PM To: ros-di...@reactos.org Subject: [ros-diffs] [dreimer] 48036: Bug 5501: [PATCH] Adding Wing32support by Carlo Bramini Author: dreimer Date: Wed Jul 14 10:59:32 2010 New Revision: 48036 URL: http://svn.reactos.org/svn/reactos?rev=48036view=rev Log: Bug 5501: [PATCH] Adding Wing32 support by Carlo Bramini Added: trunk/reactos/dll/win32/wing32/ trunk/reactos/dll/win32/wing32/wing32.c (with props) trunk/reactos/dll/win32/wing32/wing32.rbuild (with props) trunk/reactos/dll/win32/wing32/wing32.spec (with props) Modified: trunk/reactos/boot/bootdata/packages/reactos.dff trunk/reactos/dll/win32/win32.rbuild ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Build process changes...
I already have ported an autotools project to cmake, so I might help there. The big plus of cmake is that it is documented(tm) and that we don't have to care of its maintenance. Also, with good macros, adding a dll to the build might be as simple as REACTOS_ADD_DLL(gdi32) into a txt file. Le mercredi 16 juin 2010 17:53:13, Timo Kreuzer a écrit : Timo Kreuzer schrieb: Make a little now. Uhm.. ? No I dea what I wanted to say. Just ignore this sentence ;-) ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] RosBE 1.5 Release Candidates
Here is what I get when typing 'make kernel32' : [LD] output-i386/dll/win32/kernel32/kernel32.dll /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.3/libgcc.a(_enable_execute_stack.o): In function `_enable_execute_stack': /home/jeje/Downloads/RosBE-Unix-1.5-RC2/sources/gcc- build/mingw32/libgcc/../../../gcc/libgcc/../gcc/libgcc2.c:2038: undefined reference to `abort' make: *** [output-i386/dll/win32/kernel32/kernel32.dll] Error 1 This is on fedora 12 64 bits. Regards Jérôme. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss presentation
Because there still exists some features of D3D that OpenGL has not or that some manufacturers implement in their D3D drivers but not in their opengl ICD. The funny side of it is that I use wineD3D on my laptop, because intel drivers suck! Jérôme. Kamil Horníček a écrit : What would be the advantage of such an approach? We now use only Wine DX libs anyway and wined3d seems to do its job just fine. This would go directly against the whole arwinss idea = use tested and known to work code from Wine and only spend valuable dev time on parts that are reactos specific. Kamil ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Wanting to work on ddraw.
Hi everybody. I just wanted to tell you that even if I was silent for quite some time now, I'm still working on this, even more now than RL has calmed down. I have begun working on the user side of ddraw. Currently, I implemented IDirectDraw:CreatePalette (needs testing!) and almost all ddraw-refcount winetests pass when using it on winXP. Patch is on bugzilla : http://www.reactos.org/bugzilla/show_bug.cgi?id=4909 Regards Jérôme ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
[ros-dev] Wanting to work on ddraw.
Hi everybody. It's been a long time that I follow this project, even if I was pretty quiet, and I think it is now time to make my own contribution. Some of you might remind some attempts to work on kernel32 winetests., and it turned out that I needed something more motivational. I found that reactX is an abandoned field, and so I think that it would be a real challenge to get things working. I have already some patches, which get the ddraw initialization a bit further that where it manages to go in trunk. Regards Jérôme (aka zefklop) PS: I'd like to talk with you about that on IRC, but unfortunately I am behind proxy which refuses it ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Let's push winetests farther!
I do get this error too, but that does not stop me from doing some tests. What I did was to recompile kernel32 as kernel32_test and link the winetest to it instead of kernel32, and launch it in winXP. This sounds really dirty as it is, but gave me good result. The fixed tests on reactos side was a mistake. Timo Kreuzer wrote: Hi, Some dlls cannot be properly tested on Window. These are: ntdll: it uses direct systemcalls and the system call numbers would need to match the windows system you test it on. If you are very lucky you could find one version of win2k3 that matches our syscalls, but I wouldn't bet on that. kernel32: it's communication with csrss is not Windows compatible. We would have to fix (rewrite) our csrss, something that would requite lots of work. And noone loves csrss. (We accept patches. ;-)) gdi32: It loads and partly works on Windows XP, as the handle manager win32k syscall numbers are now mostly XP compatible. I'm not sure whether this is still true, as there were some changes recently and I don't know on what Windows version those were based. But the winetest results are a desaster, it even fails CreateDC. user32: Doesn't work, for a lot of reasons. user32 is a major user of kernel-usermode shared data. Our data structures are not anywhere like Windows ones and probably will never be 100%. Same for the handle manager. Also incompatible is communication with csrss again and several syscalls that are incompatible to Windows. And finally we don't (didn't?) properly initialize the kernel callbacks, making it crash on systemcalls.That may actually be fixed by Jim's recent commits. Btw: what are the results you sent? kernel32 on windows XP? I wonder how you managed to get any console output as that wouldn't work with our kernel32 on Windows. For me it doesn't load, even with your patch. WinDbg shows the following debug message: output-i386\modules\rostests\winetests\kernel32\kernel32.dll (dll\win32\kernel32\misc\dllmain.c:203) CSR Failed to give us a console So I guess you made a mistake ;-) Regards, Timo Jérôme Gardou wrote: As you all know, reactos is tested against the wine test suite. While this is a great tool, I think this is not enough to be sure that ReactOS is fully tested. I've been trying to fix some kernel32 tests. As you all know, in ReactOS it is written on top of ntdll. So I wanted to fix some tests, and then a question arose : is it that kernel32 calls ntdll the wrong way, or is it that ntdll does the wrong job? The only way to verify this would be to test kernel32.dll out of reactOS, meaning replacing the windows one with the reactos one, and run the test. To be brief : I think that a weekly reactos dlls against windows test would be very helpful to be sure that things are done the right way! I began with the kernel32:file winetest. I managed to not make it crash when used on winXP, the resulting patch is there : http://www.reactos.org/bugzilla/show_bug.cgi?id=4728 and the result of this test is attached there. As miracles happen, it also fixes some tests on ReactOS. Seems like this is a good approach. Jérôme Gardou (aka zefklop on IRC and forums) ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
