- Ros-dev - ReactOS.org

Re: [ros-dev] [ros-diffs] [dchapyshev] 32137: - Add Russian translation - Move application title to resources
by gedmurphy 05 Feb '08

05 Feb '08

dchapyshev(a)svn.reactos.org wrote: > > + LoadString(hInstance, IDS_APPTITLE, szAppName, MAX_STRING); > + > hMainWnd = CreateWindowExW(0, > szMainWndClass, > szAppName, Stick with the current mapping, you've just introduced a potential overflow. Ged.

1 0

Re: [ros-dev] [ros-diffs] [cwittich] 32018: compilerflags can be set for compiler {ALL|CC|CPP} now (ALL is default)
by tamlin＠algonet.se 27 Jan '08

27 Jan '08

Alex wrote: >On 26-Jan-08, at 2:34 PM, Marc Piulachs wrote: > >> Hi, >> >> I'm not very sure about r32018-r32022. >> >> Some compiler warnings are stupid and useless, some others not. > >This one is stupid. Actually, I'd say the stupidity is in using a runtime assert, when a compile-time assert will do the trick (not using CPU at runtime, while enforcing the condition). Unless memory fails me, in C++ you can implement ct_assert(x) like: typedef char[x!=0] foo; as an array of size zero is an error. How does current C compilers react to typedefs of zero-sized arrays? Sure, one can't use it exactly as in C++, but it could still be useful to at least know about this idiom. Problems should be trapped as early as possible. -- Mike

2 1

Re: [ros-dev] [ros-diffs] [cwittich] 32018: compilerflags can be set for compiler {ALL|CC|CPP} now (ALL is default)
by Marc Piulachs 26 Jan '08

26 Jan '08

Hi, I'm not very sure about r32018-r32022. Some compiler warnings are stupid and useless, some others not. I think we should solve the underlying problem when possible. Yes, I know it's easier to say than to do but silent them in an indiscriminate way just because clean builds are cooler is not the solution. Warnings are there for something... Also, we should work to actually remove <compilerflags> and <linkerflags> elements and express that information in a compiler/linker agnostic language now that we want to support at least an additional compiler and linker(MSVC) Regards, /Marc > -----Original Message----- > From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] > On Behalf Of cwittich(a)svn.reactos.org > Sent: Saturday, January 26, 2008 7:28 PM > To: ros-diffs(a)reactos.org > Subject: [ros-diffs] [cwittich] 32018: compilerflags can be set for > compiler {ALL|CC|CPP} now (ALL is default) > > Author: cwittich > Date: Sat Jan 26 21:27:37 2008 > New Revision: 32018 > > URL: http://svn.reactos.org/svn/reactos?rev=32018&view=rev > Log: > compilerflags can be set for compiler {ALL|CC|CPP} now (ALL is default) > > Modified: > trunk/reactos/tools/rbuild/backend/mingw/mingw.cpp > trunk/reactos/tools/rbuild/backend/mingw/modulehandler.cpp > trunk/reactos/tools/rbuild/backend/mingw/modulehandler.h > trunk/reactos/tools/rbuild/compilerflag.cpp > trunk/reactos/tools/rbuild/rbuild.h > > Modified: trunk/reactos/tools/rbuild/backend/mingw/mingw.cpp > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/tools/rbuild/backend/ming > w/mingw.cpp?rev=32018&r1=32017&r2=32018&view=diff > ========================================================================== > ==== > --- trunk/reactos/tools/rbuild/backend/mingw/mingw.cpp (original) > +++ trunk/reactos/tools/rbuild/backend/mingw/mingw.cpp Sat Jan 26 21:27:37 > 2008 > @@ -448,10 +448,13 @@ > > for ( i = 0; i < data.compilerFlags.size(); i++ ) > { > - fprintf ( > - fMakefile, > - " %s", > - data.compilerFlags[i]->flag.c_str() ); > + if ( data.compilerFlags[i]->compiler == CompilerTypeDontCare ) > + { > + fprintf ( > + fMakefile, > + " %s", > + data.compilerFlags[i]->flag.c_str() ); > + } > } > > fprintf ( fMakefile, "\n" ); > > Modified: trunk/reactos/tools/rbuild/backend/mingw/modulehandler.cpp > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/tools/rbuild/backend/ming > w/modulehandler.cpp?rev=32018&r1=32017&r2=32018&view=diff > ========================================================================== > ==== > --- trunk/reactos/tools/rbuild/backend/mingw/modulehandler.cpp (original) > +++ trunk/reactos/tools/rbuild/backend/mingw/modulehandler.cpp Sat Jan 26 > 21:27:37 2008 > @@ -764,15 +764,18 @@ > } > > string > -MingwModuleHandler::GenerateCompilerParametersFromVector ( const > vector<CompilerFlag*>& compilerFlags ) const > +MingwModuleHandler::GenerateCompilerParametersFromVector ( const > vector<CompilerFlag*>& compilerFlags, const CompilerType type ) const > { > string parameters; > for ( size_t i = 0; i < compilerFlags.size (); i++ ) > { > CompilerFlag& compilerFlag = *compilerFlags[i]; > - if ( parameters.length () > 0 ) > - parameters += " "; > - parameters += compilerFlag.flag; > + if ( compilerFlag.compiler == type ) > + { > + if ( parameters.length () > 0 ) > + parameters += " "; > + parameters += compilerFlag.flag; > + } > } > return parameters; > } > @@ -848,7 +851,7 @@ > > if ( generatingCompilerMacro ) > { > - string compilerParameters = > GenerateCompilerParametersFromVector ( data.compilerFlags ); > + string compilerParameters = > GenerateCompilerParametersFromVector ( data.compilerFlags , > CompilerTypeDontCare ); > if ( compilerParameters.size () > 0 ) > { > fprintf ( > @@ -1719,21 +1722,25 @@ > { > const FileLocation& sourceFile = compilationUnit.GetFilename (); > string extension = GetExtension ( sourceFile ); > + string flags = cflagsMacro; > + flags += " "; > if ( extension == ".c" || extension == ".C" ) > { > + flags += GenerateCompilerParametersFromVector ( > module.non_if_data.compilerFlags , CompilerTypeCC ); > GenerateGccCommand ( &sourceFile, > GetCompilationUnitDependencies ( > compilationUnit ) + extraDependencies, > cc, > - cflagsMacro ); > + flags ); > } > else if ( extension == ".cc" || extension == ".CC" || > extension == ".cpp" || extension == ".CPP" || > extension == ".cxx" || extension == ".CXX" ) > { > + flags += GenerateCompilerParametersFromVector ( > module.non_if_data.compilerFlags , CompilerTypeCPP ); > GenerateGccCommand ( &sourceFile, > GetCompilationUnitDependencies ( > compilationUnit ) + extraDependencies, > cppc, > - cflagsMacro ); > + flags ); > } > else if ( extension == ".s" || extension == ".S" ) > { > > Modified: trunk/reactos/tools/rbuild/backend/mingw/modulehandler.h > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/tools/rbuild/backend/ming > w/modulehandler.h?rev=32018&r1=32017&r2=32018&view=diff > ========================================================================== > ==== > --- trunk/reactos/tools/rbuild/backend/mingw/modulehandler.h (original) > +++ trunk/reactos/tools/rbuild/backend/mingw/modulehandler.h Sat Jan 26 > 21:27:37 2008 > @@ -130,7 +130,7 @@ > std::string ConcatenatePaths ( const std::string& path1, > const std::string& path2 ) const; > std::string GenerateGccDefineParameters () const; > - std::string GenerateCompilerParametersFromVector ( const > std::vector<CompilerFlag*>& compilerFlags ) const; > + std::string GenerateCompilerParametersFromVector ( const > std::vector<CompilerFlag*>& compilerFlags, const CompilerType type ) > const; > std::string GenerateLinkerParametersFromVector ( const > std::vector<LinkerFlag*>& linkerFlags ) const; > std::string GenerateImportLibraryDependenciesFromVector ( const > std::vector<Library*>& libraries ); > std::string GenerateLinkerParameters () const; > > Modified: trunk/reactos/tools/rbuild/compilerflag.cpp > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/tools/rbuild/compilerflag > .cpp?rev=32018&r1=32017&r2=32018&view=diff > ========================================================================== > ==== > --- trunk/reactos/tools/rbuild/compilerflag.cpp (original) > +++ trunk/reactos/tools/rbuild/compilerflag.cpp Sat Jan 26 21:27:37 2008 > @@ -55,7 +55,25 @@ > node.location, > "<compilerflag> is empty." ); > } > + > flag = node.value; > + compiler = CompilerTypeDontCare; > + > + const XMLAttribute* att = node.GetAttribute ( "compiler", false ); > + if ( att != NULL) > + { > + if ( att->value == "cpp" ) > + compiler = CompilerTypeCPP; > + else if ( att->value == "cc" ) > + compiler = CompilerTypeCC; > + else > + { > + throw InvalidAttributeValueException ( > + node.location, > + "compiler", > + att->value ); > + } > + } > } > > void > > Modified: trunk/reactos/tools/rbuild/rbuild.h > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/tools/rbuild/rbuild.h?rev > =32018&r1=32017&r2=32018&view=diff > ========================================================================== > ==== > --- trunk/reactos/tools/rbuild/rbuild.h (original) > +++ trunk/reactos/tools/rbuild/rbuild.h Sat Jan 26 21:27:37 2008 > @@ -309,6 +309,13 @@ > HostDefault, > HostTrue, > HostDontCare, > +}; > + > +enum CompilerType > +{ > + CompilerTypeDontCare, > + CompilerTypeCC, > + CompilerTypeCPP, > }; > > class FileLocation > @@ -592,6 +599,7 @@ > const Module* module; > const XMLElement& node; > std::string flag; > + CompilerType compiler; > > CompilerFlag ( const Project& project, > const XMLElement& compilerFlagNode ); >

4 3

Re: [ros-dev] [ros-diffs] [arty] 32007: Fix termination of process under debug.
by Alex Ionescu 26 Jan '08

26 Jan '08

This is incorrect behavior, the terminate should be instant. This will likely cause bugs in the user-mode debugging framework. On 26-Jan-08, at 4:20 AM, arty(a)svn.reactos.org wrote: > Author: arty > Date: Sat Jan 26 12:20:56 2008 > New Revision: 32007 > > URL: http://svn.reactos.org/svn/reactos?rev=32007&view=rev > Log: > Fix termination of process under debug. > > Modified: > trunk/reactos/ntoskrnl/dbgk/dbgkobj.c > > Modified: trunk/reactos/ntoskrnl/dbgk/dbgkobj.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/dbgk/dbgkobj.c?re… > = > = > = > = > = > = > = > = > ====================================================================== > --- trunk/reactos/ntoskrnl/dbgk/dbgkobj.c (original) > +++ trunk/reactos/ntoskrnl/dbgk/dbgkobj.c Sat Jan 26 12:20:56 2008 > @@ -1065,6 +1065,17 @@ > > VOID > NTAPI > +DbgkpDelayedTerminateProcess(PVOID Arg) > +{ > + PWORK_QUEUE_ITEM WorkItem = (PWORK_QUEUE_ITEM)Arg; > + PEPROCESS OwnerProcess = *((PEPROCESS *)&WorkItem[1]); > + ExFreePool(WorkItem); > + /* Terminate the process */ > + PsTerminateProcess(OwnerProcess, STATUS_DEBUGGER_INACTIVE); > +} > + > +VOID > +NTAPI > DbgkpCloseObject(IN PEPROCESS OwnerProcess OPTIONAL, > IN PVOID ObjectBody, > IN ACCESS_MASK GrantedAccess, > @@ -1079,6 +1090,8 @@ > DBGKTRACE(DBGK_OBJECT_DEBUG, "OwnerProcess: %p DebugObject: %p\n", > OwnerProcess, DebugObject); > > + DPRINT("APC DISABLE: %d\n", ((PETHREAD)KeGetCurrentThread())- > >Tcb.CombinedApcDisable); > + > /* If this isn't the last handle, do nothing */ > if (SystemHandleCount > 1) return; > > @@ -1127,8 +1140,16 @@ > /* Check if we terminate on exit */ > if (DebugObject->KillProcessOnExit) > { > - /* Terminate the process */ > - PsTerminateProcess(OwnerProcess, > STATUS_DEBUGGER_INACTIVE); > + PWORK_QUEUE_ITEM WorkItem = > + ExAllocatePool > + (NonPagedPool, > + sizeof(WORK_QUEUE_ITEM) + sizeof(PVOID)); > + ExInitializeWorkItem > + (WorkItem, > + DbgkpDelayedTerminateProcess, > + WorkItem); > + *((PEPROCESS *)&WorkItem[1]) = OwnerProcess; > + ExQueueWorkItem(WorkItem, CriticalWorkQueue); > } > > /* Dereference the debug object */ > > Best regards, Alex Ionescu

1 0

Re: [ros-dev] [ros-diffs] [cwittich] 31978: remove statement with no effect
by Alex Ionescu 25 Jan '08

25 Jan '08

Um, this statement is useful. Try to understand compiler warnings, not just obey them :) On 24-Jan-08, at 3:47 PM, cwittich(a)svn.reactos.org wrote: > Author: cwittich > Date: Thu Jan 24 23:47:56 2008 > New Revision: 31978 > > URL: http://svn.reactos.org/svn/reactos?rev=31978&view=rev > Log: > remove statement with no effect > > Modified: > trunk/reactos/dll/win32/kernel32/mem/local.c > > Modified: trunk/reactos/dll/win32/kernel32/mem/local.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/mem/loc… > = > = > = > = > = > = > = > = > ====================================================================== > --- trunk/reactos/dll/win32/kernel32/mem/local.c (original) > +++ trunk/reactos/dll/win32/kernel32/mem/local.c Thu Jan 24 23:47:56 > 2008 > @@ -254,8 +254,6 @@ > NTAPI > LocalLock(HLOCAL hMem) > { > - /* This is the same as a GlobalLock, assuming these never > change */ > - ASSERT(LMEM_LOCKCOUNT == GMEM_LOCKCOUNT); > return GlobalLock(hMem); > } > > >

2 1

How to get the permission to commit code?
by Xiaoming Gao 20 Jan '08

20 Jan '08

HI guys, Would someone tell me how to get the permission to commit code?

2 2

no need to fix apic ldr configure
by Xiaoming Gao 19 Jan '08

19 Jan '08

> > I think the "fixme" in halx86/mp/apic.c line 583 is no need to fix,i have > > read the linux source code ,which just configure like reactos.So still > > need to fix? > > >

1 0

may it is a problem(about Completion port)
by Yee Jacky 19 Jan '08

19 Jan '08

when we use iocp,first,we should create a port like this --- CreateIoCompletionPort(INVALID_HANDLE_VALUE, NULL, 0, 0);--- But in the implementation of CreateIoCompletionPort,the beginning of the fuction is : if ( ExistingCompletionPort == NULL && FileHandle == INVALID_HANDLE_VALUE ) { SetLastError(ERROR_INVALID_PARAMETER); return FALSE; } so ,all the application running well on MS Windows will not run correct in ReactOS,Because they will always get the ERROR_INVALID_PARAMETER error code when they call CreateIoCompletionPort like --CreateIoCompletionPort(INVALID_HANDLE_VALUE, NULL, 0, 0);-- I think this is a problem,But I'm not sure!

2 2

Re: [ros-dev] Hi, does ReactOS support x86 multiprocessor completely for now?
by Aleksey Bragin 19 Jan '08

19 Jan '08

Hello, it's not really completely supported now. As for the label, it was a typo, and I fixed it in revision 31882. WBR, Aleksey Bragin. On Jan 19, 2008, at 12:48 PM, Xiaoming Gao wrote: > Hello everyone > I'm a new comer,i'm reading the kernel source ,but i found that > "jz NotBusy " in ctxswitch.S (line 351),the NotBusy label is not > defined.I have searched the whole source code,but not found it. So, > would someone tell me some information about this?

2 1

Hi, does ReactOS support x86 multiprocessor completely for now?
by Xiaoming Gao 19 Jan '08

19 Jan '08

Hello everyone I'm a new comer,i'm reading the kernel source ,but i found that "jz NotBusy " in ctxswitch.S (line 351),the NotBusy label is not defined.I have searched the whole source code,but not found it. So, would someone tell me some information about this?

1 0

delay loading dlls
by Timo Kreuzer 17 Jan '08

17 Jan '08

Hi, I have recently played around a little with delay loading stuff. I have written a __delayLoadHelper2 and the neccessary asm stubs to do delay loading of a dll. It works and is implemented as documented on msdn / Under The Hood. The stubs are done by hand, but it shouldn't be too hard to write a tool to autocreate them the same way as dlltool does it. There will be no entry in the pe header, but that is optional anyway. Are there any plans on how to handle that? The best way would probably be, if dlltool could handle that, but ... So I thought about a dlitool.exe that creates the stubs. Any ideas? For the ones interested: I have attached the sources. They allow to delay import StrToIntA from shlwapi.dll Timo #include <windows.h> #include "delayimp.h" inline unsigned IndexFromPImgThunkData(PCImgThunkData pData, PCImgThunkData pBase) { return pData - pBase; } extern const IMAGE_DOS_HEADER _image_base__; inline PVOID PFromRva(RVA rva) { return (PVOID)(((ULONG_PTR)(rva)) + ((ULONG_PTR)&_image_base__)); } /**** load helper ****/ FARPROC WINAPI __delayLoadHelper2(PCImgDelayDescr pidd, PImgThunkData pIATEntry) { DelayLoadInfo dli; int index; PImgThunkData pIAT; PImgThunkData pINT; HMODULE *phMod; FARPROC pProc; pIAT = PFromRva(pidd->rvaIAT); pINT = PFromRva(pidd->rvaINT); phMod = PFromRva(pidd->rvaHmod); index = IndexFromPImgThunkData(pIATEntry, pIAT); dli.cb = sizeof(dli); dli.pidd = pidd; dli.ppfn = (FARPROC*)pIATEntry->u1.Function; dli.szDll = PFromRva(pidd->rvaDLLName); dli.dlp.fImportByName = !(pINT[index].u1.Ordinal & IMAGE_ORDINAL_FLAG); if (dli.dlp.fImportByName) { /* u1.AdressOfData points to a IMAGE_IMPORT_BY_NAME struct */ PIMAGE_IMPORT_BY_NAME piibn = PFromRva((RVA)pINT[index].u1.AddressOfData); dli.dlp.szProcName = (LPCSTR)&piibn->Name; } else { dli.dlp.dwOrdinal = pINT[index].u1.Ordinal & ~IMAGE_ORDINAL_FLAG; } dli.hmodCur = *phMod; dli.pfnCur = (FARPROC)pIAT[index].u1.Function; dli.dwLastError = GetLastError(); pProc = __pfnDliNotifyHook2(dliStartProcessing, &dli); if (pProc) { pIAT[index].u1.Function = (DWORD)pProc; return pProc; } if (dli.hmodCur == NULL) { dli.hmodCur = LoadLibraryA(dli.szDll); if (!dli.hmodCur) { dli.dwLastError = GetLastError(); __pfnDliFailureHook2(dliFailLoadLib, &dli); // if (ret) // { // } // FIXME: raise exception; return NULL; } *phMod = dli.hmodCur; } /* dli.dlp.szProcName might also contain the ordinal */ pProc = GetProcAddress(dli.hmodCur, dli.dlp.szProcName); if (!pProc) { dli.dwLastError = GetLastError(); __pfnDliFailureHook2(dliFailGetProc, &dli); // FIXME: handle return value & raise exception return NULL; } pIAT[index].u1.Function = (DWORD)pProc; return pProc; } /*** The default hooks ***/ FARPROC WINAPI DefaultDliNotifyHook2(unsigned dliNotify, PDelayLoadInfo pdli) { return NULL; } FARPROC WINAPI DefaultDliFailureHook2(unsigned dliNotify, PDelayLoadInfo pdli) { return NULL; } PfnDliHook __pfnDliNotifyHook2 = DefaultDliNotifyHook2; PfnDliHook __pfnDliFailureHook2 = DefaultDliFailureHook2; #ifndef _DELAYIMP_H_ #define _DELAYIMP_H_ typedef void *RVA; typedef IMAGE_THUNK_DATA *PImgThunkData; typedef const IMAGE_THUNK_DATA *PCImgThunkData; enum { dlattrRva }; /* Notification codes */ enum { dliStartProcessing, dliNotePreLoadLibrary, dliNotePreGetProcAddress, dliFailLoadLib, dliFailGetProc, dliNoteEndProcessing, }; typedef struct ImgDelayDescr { DWORD grAttrs; RVA rvaDLLName; RVA rvaHmod; RVA rvaIAT; RVA rvaINT; RVA rvaBoundIAT; RVA rvaUnloadIAT; DWORD dwTimeStamp; } ImgDelayDescr, *PImgDelayDescr; typedef const ImgDelayDescr *PCImgDelayDescr; typedef struct DelayLoadProc { BOOL fImportByName; union { LPCSTR szProcName; DWORD dwOrdinal; }; } DelayLoadProc; typedef struct DelayLoadInfo { DWORD cb; PCImgDelayDescr pidd; FARPROC *ppfn; LPCSTR szDll; DelayLoadProc dlp; HMODULE hmodCur; FARPROC pfnCur; DWORD dwLastError; } DelayLoadInfo, *PDelayLoadInfo; typedef FARPROC (WINAPI *PfnDliHook)(unsigned, PDelayLoadInfo); extern PfnDliHook __pfnDliNotifyHook2; extern PfnDliHook __pfnDliFailureHook2; #endif /* not _DELAYIMP_H_ */ .intel_syntax noprefix .section .text .global __tailMerge__shlwapi __tailMerge__shlwapi: push ecx push edx push eax push offset __DELAY_IMPORT_DESCRIPTOR_SHLWAPI call ___delayLoadHelper2@8 pop edx pop ecx jmp eax # DELAY_IMPORT_DESCRIPTOR .section .text$2 .global __DELAY_IMPORT_DESCRIPTOR_SHLWAPI __DELAY_IMPORT_DESCRIPTOR_SHLWAPI: .long 1 # grAttrs .rva shlwapi_dll_iname # rvaDLLName .rva shlwapi_dll_handle # rvaHmod .rva shlwapi_dll_diat # rvaIAT .rva shlwapi_dll_dint # rvaINT .long 0 # rvaBoundIAT .long 0 # rvaUnloadIAT .long 0 # dwTimeStamp .section .data shlwapi_dll_handle: .long 0 #Stuff for compatibility .section .idata$5 .long 0 shlwapi_dll_diat: .section .idata$4 .long 0 .section .idata$4 shlwapi_dll_dint: .intel_syntax noprefix .section .text .global _StrToIntA@4 _StrToIntA@4: jmp dword ptr [.idata$5] __imp__load_StrToIntA@4: mov eax, offset __imp__StrToIntA@4 jmp __tailMerge__shlwapi # The INT .section .idata$4 .rva .idata$6 # The IAT .section .idata$5 __imp__StrToIntA@4: .long __imp__load_StrToIntA@4 # The name .section .idata$6 .byte 0x00, 0x00 .asciz "StrToIntA" #.section .idata$7 # .rva __DELAY_IMPORT_DESCRIPTOR_SHLWAPI .intel_syntax noprefix # Terminate the INT .section .idata$4 .long 0 # Terminate the IAT .section .idata$5 .long 0 # The dll name .section .idata$7 .global shlwapi_dll_iname shlwapi_dll_iname: .asciz "shlwapi.dll"

1 0

Re: [ros-dev] [ros-diffs] [peterw] 31817: Big polish translation patch by Olaf Siejka (caemyr AT gmail DOT com) See issue #2944 for more details. - Polish translation for 0.3.4 is now complete... almost :) One thing left is kernel32 error codes. As it requires inte
by Marc Piulachs 16 Jan '08

16 Jan '08

> trunk/reactos/dll/win32/kernel32/lang/pl-PL.mc (with props) IMO is not a good idea to use different mc files for every language. MC file format is specially designed to hold all the languages in the same file, also our current WMC implementation does not support splitting translation across multiple mc files. AFAIK Physcious was working on implementing that feature to our WMC but even in that case there is no easy way to support them at rbuild level without introducing a hack, also MS's WMC does not support it so I think we should keep it to the lowest common denominator and avoid future compiler compatibility problems as there isn't any significant advantage on it. /Marc

2 1

Re: [ros-dev] Crash caused by Sysinternals FileMon 7.04 found by Christoph
by tamlin＠algonet.se 15 Jan '08

15 Jan '08

jimtabor wrote: >when WindowObject->Wnd is NULL and WindowObject is not NULL > it crashes in vis.c line 89. [...] >Since this crash is started in GetDCEx with a NULL "Window" >call leaves me with a bad taste. The code was written prior to >having Desktop support, later hax. So having null window >associated with DCE is okay then, not now. > >Any Ideas? Isn't this the case where it in Windows originally got the meaning "use the desktop window", that later became a compatibility hack where "NULL isn't a cool HWND, but due to the many programs using it, we'll automatically give the user the DC for the (currently visible) screen" (or possibly the desktop associated with the thread)? -- Mike

1 0

Re: [ros-dev] heap.c
by Aleksey Bragin 13 Jan '08

13 Jan '08

Hi, please provide a patch in a unified diff format (preferably submit it to www.reactos.org/bugzilla for faster reviewing/commit process). WBR, Aleksey Bragin. On Jan 13, 2008, at 6:11 PM, Oriol wrote: > here's the implementation and some corrections of some unimplemented > functions at lib/rtl/heap.c > > NTSTATUS NTAPI > RtlEnumProcessHeaps(PHEAP_ENUMERATION_ROUTINE HeapEnumerationRoutine, > PVOID lParam) > { > > #if 1 > NTSTATUS Status = STATUS_SUCCESS; > > struct list *ptr=NULL; > RtlEnterHeapLock(&processHeap->critSection); > Status=HeapEnumerationRoutine(processHeap,lParam); > LIST_FOR_EACH( ptr, &processHeap->entry ) > { > if (!NT_SUCCESS(Status)) > break; > Status = HeapEnumerationRoutine(ptr,lParam); > > } > > > RtlLeaveHeapLock(&processHeap->critSection); > > return Status; > #endif > } > > > /* > * @implemented > */ > ULONG NTAPI > RtlGetProcessHeaps(ULONG count, > HANDLE *heaps ) > { > ULONG total = 1; /* main heap */ > struct list *ptr; > ULONG i=0; > RtlEnterHeapLock( &processHeap->critSection ); > LIST_FOR_EACH( ptr, &processHeap->entry ) total++; > //if (total <= count) > { > *(heaps++) = processHeap; > i++; > LIST_FOR_EACH( ptr, &processHeap->entry ) > { > if(i>=count) > { > break; > } > i++; > *(heaps++) = LIST_ENTRY( ptr, HEAP, entry ); > > } > } > RtlLeaveHeapLock( &processHeap->critSection ); > return i; > } > > > /* > * @implemented > */ > BOOLEAN NTAPI > RtlValidateProcessHeaps(VOID) > { > > #if 1 > BOOLEAN Result = TRUE; > HEAP ** pptr; > > > RtlEnterHeapLock( &processHeap->critSection ); > > for (pptr = (HEAP**)&NtCurrentPeb()->ProcessHeaps; *pptr; pptr++) > { > if (!RtlValidateHeap(*pptr, 0, NULL)) > { > Result = FALSE; > break; > } > } > > > RtlLeaveHeapLock( &processHeap->critSection ); > return Result; > #endif > } > > is it correct? > > > > ______________________________________________ > LLama Gratis a cualquier PC del Mundo. > Llamadas a fijos y móviles desde 1 céntimo por minuto. > http://es.voice.yahoo.com > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev

1 0

heap.c
by Oriol 13 Jan '08

13 Jan '08

here's the implementation and some corrections of some unimplemented functions at lib/rtl/heap.c NTSTATUS NTAPI RtlEnumProcessHeaps(PHEAP_ENUMERATION_ROUTINE HeapEnumerationRoutine, PVOID lParam) { #if 1 NTSTATUS Status = STATUS_SUCCESS; struct list *ptr=NULL; RtlEnterHeapLock(&processHeap->critSection); Status=HeapEnumerationRoutine(processHeap,lParam); LIST_FOR_EACH( ptr, &processHeap->entry ) { if (!NT_SUCCESS(Status)) break; Status = HeapEnumerationRoutine(ptr,lParam); } RtlLeaveHeapLock(&processHeap->critSection); return Status; #endif } /* * @implemented */ ULONG NTAPI RtlGetProcessHeaps(ULONG count, HANDLE *heaps ) { ULONG total = 1; /* main heap */ struct list *ptr; ULONG i=0; RtlEnterHeapLock( &processHeap->critSection ); LIST_FOR_EACH( ptr, &processHeap->entry ) total++; //if (total <= count) { *(heaps++) = processHeap; i++; LIST_FOR_EACH( ptr, &processHeap->entry ) { if(i>=count) { break; } i++; *(heaps++) = LIST_ENTRY( ptr, HEAP, entry ); } } RtlLeaveHeapLock( &processHeap->critSection ); return i; } /* * @implemented */ BOOLEAN NTAPI RtlValidateProcessHeaps(VOID) { #if 1 BOOLEAN Result = TRUE; HEAP ** pptr; RtlEnterHeapLock( &processHeap->critSection ); for (pptr = (HEAP**)&NtCurrentPeb()->ProcessHeaps; *pptr; pptr++) { if (!RtlValidateHeap(*pptr, 0, NULL)) { Result = FALSE; break; } } RtlLeaveHeapLock( &processHeap->critSection ); return Result; #endif } is it correct? ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com

1 0

Crash caused by Sysinternals FileMon 7.04 found by Christoph
by James Tabor 12 Jan '08

12 Jan '08

Hi, >From this patch http://svn.reactos.org/svn/reactos?view=rev&revision=30477, I found when WindowObject->Wnd is NULL and WindowObject is not NULL it crashes in vis.c line 89. This patch is okay. My best guess, when Wnd is null that means the window is on the way of removal. Luck of the thread? I can patch and protect the while loops in vis.c but the crash moves to another place based on the same null Wnd problem. Since this crash is started in GetDCEx with a NULL "Window" call leaves me with a bad taste. The code was written prior to having Desktop support, later hax. So having null window associated with DCE is okay then, not now. Any Ideas? Thanks, James

1 0

advapi32 crypt update from wine
by Christoph Brill 08 Jan '08

08 Jan '08

Hi list, attached is a patch to update the crypt-related part of advapi from wine. Hope this patch is useful. It's less intrusive than earlier patches from me. Please use it, Christoph (aka egore on IRC)

3 2

Patch for misc cleanups from Wine
by Christoph Brill 06 Jan '08

06 Jan '08

Hi list, on my way on comparing wine with reactos I found several differences which were cleanups in wine. Attached is a patch to merge over theses changes. Regards, Christoph Brill

2 2

Update shdocvw from wine
by Christoph Brill 06 Jan '08

06 Jan '08

Hi list, I tried to sync shdocvw today. Our version is quite different from what I found in wine. Both seem to have started from a similar point but both got some development done. I'm not sure I'm doing anything correct here, but to outline my changes (and later on the issues): - Import the new "class hierarchie" (ConnectionPointContainer->DocHost->WebBrowser) - stuff like IPersistMemory, IOleCommandTarget, IHlinkFrame, IDispatch, IServiceProvider - URL-History and Navigation (Forward, Backward) Issues: - I commented out regsvr.c because factory.c had similar functions. I'm not sure which one is better, but whichever we choose it should be put in regserv.c and merged back to wine. - DllGetClassObject in shdocvw_main.c commented out in favour of factory.c. Same as above. - I removed "extern const GUID CLSID_InternetShortcut;" from include/psdk/isguids.h. We needed CLSID_InternetShortcut to be static in factory.c. You see: factory.c causes me a major headache. I'll see if I can fix these issues but I really like one with knowledge(!) to look over the patches and at least tell me: Hey, what you are doing is (more or less) right/wrong. Feedback please! Thanks, Christoph Brill

1 0

Patch for msvcrt20
by Christoph Brill 06 Jan '08

06 Jan '08

Hi list, attached is a patch to update msvcrt20 against wine. It changes: - use the .spec file from wine to generate the .def - Add some CDECL's That's it, Christoph Brill

1 0

[PATCH] Sync msiexec againt wine
by Christoph Brill 06 Jan '08

06 Jan '08

Hi list, attached is a patch that updates our msiexec from the wine sources. From what I can tell it has 2 major changes: - option handling is now much more sane (no "if (!xyz)" but "if (xyz)") - addition of argument "/regserver" I also added the icon from wine for msiexec. Not sure if it's ok. Tell me if I should create another (if someone tells me how the icon should look like I would do a better one). Regards, Christoph Brill

1 0

dll/cpl/usrmgr translation status
by Olaf Siejka 05 Jan '08

05 Jan '08

I would like to ask if usrmgr is open for translation. As Eric Kohl left the following message inside en-US.rc: * Attention Translators: * DO NOT TRANSLATE THESE RESOURCES YET! it should be quite evident, its not ready yet. Alas, a russian translation exists, commited by Fireball himself. Regards Olaf Siejka aka Caemyr aka Haos

1 0

bug in vfatfs.sys?
by Oriol 04 Jan '08

04 Jan '08

I get an error while trying to install Firefox 2.0 on a bootcd compilation, finally i found the possibly bug is in vfatfs.sys i modified some lines but is not my code.....it seems to install Firefox. Also, testing firefox i found problems with gdi and also done some modifications, still testing them.. Here is my patch..NO WARRANTY he he..

3 4

Re: [ros-dev] bug in vfatfs.sys?
by Aleksey Bragin 04 Jan '08

04 Jan '08

Basically, Oriol just uncommented your #if0-ed code, and substituted SEH-wrapped pointer operation with a worse "if not null" check. And that's filtering a number of unrelated debug-messages hacks. But, Oriol, you're giving good signs you're improving! :-) The VFAT problem of not clearing the delete pending flag is a good thing (Christoph discovered that, however there are still problems if you clear the flag). With the best regards, Aleksey Bragin. On Jan 4, 2008, at 10:46 AM, James Tabor wrote: > Hi, > I can only write about the gdi code changes. > > 1st dll/win32/gdi32/misc/misc.c looks good! > 2nd the dc.c changes,,, ATM the support code for dirty bit sets is not > inplace, but the patch is good. > > I will apply your patch ASAP for the GDI changes, it does look good. > > Thanks, > James > > On Jan 3, 2008 3:41 PM, Oriol <oripipa(a)yahoo.es> wrote: >> I get an error while trying to install Firefox 2.0 on a bootcd >> compilation, finally i found the possibly bug is in vfatfs.sys i >> modified some lines but is not my code.....it seems to install >> Firefox. >> Also, testing firefox i found problems with gdi and also done some >> modifications, still testing them.. >> Here is my patch..NO WARRANTY he he..

1 0

Re : bug in vfatfs.sys?
by Sylvain Petreolle 04 Jan '08

04 Jan '08

Hi Oriol, now you can send the vfatfs.sys patch ;) Kind regards, Sylvain Petreolle (aka Usurp) Je ne suis pas d'accord avec ce que vous dites, mais je me battrai jusqu'à la mort pour que vous ayez le droit de le dire.I may disagree with what you have to say, but I shall defend, to the death, your right to say it. - VoltaireRun your favorite Windows apps with free ReactOS : http://www.reactos.orgListen to non-DRMised Music: http://www.jamendo.com ----- Message d'origine ---- De : Oriol <oripipa(a)yahoo.es> À : ros-dev(a)reactos.org Envoyé le : Jeudi, 3 Janvier 2008, 22h41mn 57s Objet : [ros-dev] bug in vfatfs.sys? I get an error while trying to install Firefox 2.0 on a bootcd compilation, finally i found the possibly bug is in vfatfs.sys i modified some lines but is not my code.....it seems to install Firefox. Also, testing firefox i found problems with gdi and also done some modifications, still testing them.. Here is my patch..NO WARRANTY he he..

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev