Ros-dev

ros-dev@reactos.org

5788 discussions

may it is a problem(about Completion port)

by Yee Jacky

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!

16 years, 8 months

Re: [ros-dev] Hi, does ReactOS support x86 multiprocessor completely for now?

by Aleksey Bragin

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?

16 years, 8 months

Hi, does ReactOS support x86 multiprocessor completely for now?

by Xiaoming Gao

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?

16 years, 8 months

delay loading dlls

by Timo Kreuzer

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"

16 years, 8 months

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

> 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

16 years, 8 months

Re: [ros-dev] Crash caused by Sysinternals FileMon 7.04 found by Christoph

by tamlin＠algonet.se

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

16 years, 8 months

Re: [ros-dev] heap.c

by Aleksey Bragin

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

16 years, 8 months

heap.c

by Oriol

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

16 years, 8 months

Crash caused by Sysinternals FileMon 7.04 found by Christoph

by James Tabor

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

16 years, 8 months

advapi32 crypt update from wine

by Christoph Brill

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)

16 years, 8 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev