Ros-dev January 2008

ros-dev@reactos.org

18 participants
30 discussions

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"

17 years, 10 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

17 years, 10 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

17 years, 10 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

17 years, 10 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

17 years, 10 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

17 years, 10 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)

17 years, 11 months

Patch for misc cleanups from Wine

by Christoph Brill

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

17 years, 11 months

Update shdocvw from wine

by Christoph Brill

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

17 years, 11 months

Patch for msvcrt20

by Christoph Brill

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

17 years, 11 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev January 2008