Ros-dev

ros-dev@reactos.org

5790 discussions

Re: [ros-dev] [ros-diffs] [tkreuzer] 39558: Implement hpp - the header preprocessor It can parse headers and create new headers from them based on a simple prepreprocessing language that's compatible with the C preprocessor, so the source file stays a valid header. It works, but doesn't yet support different folders.

by Aleksey Bragin

Please add a standard header, with license information. On Feb 11, 2009, at 11:37 PM, tkreuzer(a)svn.reactos.org wrote: > Author: tkreuzer > Date: Wed Feb 11 14:37:25 2009 > New Revision: 39558 > > URL: http://svn.reactos.org/svn/reactos?rev=39558&view=rev > Log: > Implement hpp - the header preprocessor > It can parse headers and create new headers from them based on a > simple prepreprocessing language that's compatible with the C > preprocessor, so the source file stays a valid header. It works, > but doesn't yet support different folders. > > Added: > trunk/reactos/tools/hpp/ (with props) > trunk/reactos/tools/hpp/hpp.c (with props) > trunk/reactos/tools/hpp/hpp.rbuild (with props) > > Propchange: trunk/reactos/tools/hpp/ > ---------------------------------------------------------------------- > -------- > svn:mergeinfo = > > Added: trunk/reactos/tools/hpp/hpp.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/hpp/ > hpp.c?rev=39558&view=auto > ====================================================================== > ======== > --- trunk/reactos/tools/hpp/hpp.c (added) > +++ trunk/reactos/tools/hpp/hpp.c [iso-8859-1] Wed Feb 11 14:37:25 > 2009 > @@ -1,0 +1,509 @@ > +#include <stdio.h>

16 years, 6 months

Re: [ros-dev] [ros-diffs] [fireball] 39578: Igor Koshpaev <tower@reactos.org> - Include missing modules into bootcd

by Timo Kreuzer

fireball(a)svn.reactos.org wrote: > Author: fireball > Date: Fri Feb 13 05:20:59 2009 > New Revision: 39578 > > URL: http://svn.reactos.org/svn/reactos?rev=39578&view=rev > Log: > Igor Koshpaev <tower(a)reactos.org> > - Include missing modules into bootcd > ... > +modules\rostests\apitests\w32kdll\w32kdll_2k3sp2\w32kdll_2k3sp2.dll 1 optional > +modules\rostests\apitests\w32kdll\w32kdll_2ksp4\w32kdll_2ksp4.dll 1 optional > ... > +modules\rostests\apitests\w32kdll\w32kdll_xpsp2\w32kdll_xpsp2.dll 1 optional > These make no sense on reactos. They only work on the respective OS.

16 years, 6 months

Re: [ros-dev] [ros-diffs] [tkreuzer] 39533: x64 version of ntoskrnl doesn't export ExInterlockedAddLargeStatistic

by Steven Edwards

Does the pspec here use Winebuild? Sorry I can't check at the moment. If it does, the current winebuild allows you to specify exports for a given arch by passing -arch=cpu in the spec file. On Tue, Feb 10, 2009 at 10:15 AM, <tkreuzer(a)svn.reactos.org> wrote: > Author: tkreuzer > Date: Tue Feb 10 09:15:07 2009 > New Revision: 39533 > > URL: http://svn.reactos.org/svn/reactos?rev=39533&view=rev > Log: > x64 version of ntoskrnl doesn't export ExInterlockedAddLargeStatistic > > Modified: > branches/ros-amd64-bringup/reactos/ntoskrnl/ntoskrnl.pspec > > Modified: branches/ros-amd64-bringup/reactos/ntoskrnl/ntoskrnl.pspec > URL: http://svn.reactos.org/svn/reactos/branches/ros-amd64-bringup/reactos/ntosk… > ============================================================================== > --- branches/ros-amd64-bringup/reactos/ntoskrnl/ntoskrnl.pspec [iso-8859-1] (original) > +++ branches/ros-amd64-bringup/reactos/ntoskrnl/ntoskrnl.pspec [iso-8859-1] Tue Feb 10 09:15:07 2009 > @@ -104,7 +104,9 @@ > @ stdcall ExInitializeRundownProtectionCacheAware(ptr long) > @ stdcall ExInitializeZone(ptr long ptr long) > @ stdcall ExInterlockedAddLargeInteger(ptr long long ptr) > +#ifndef __x86_64__ > @ fastcall ExInterlockedAddLargeStatistic(ptr long) > +#endif > @ stdcall ExInterlockedAddUlong(ptr long ptr) > #ifndef __x86_64__ > @ fastcall ExInterlockedCompareExchange64(ptr ptr ptr ptr) > > -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

16 years, 7 months

Development Tools for ReactOS

by Deepak Gupta

Folks, I don't know where to ask this question, So decided to ask it on Dev mailing list. I am new to ReactOS and installed it on VMWare workstation and really loved it. It's behavior look and feel is like Windows and I really appreciate it (although there is long way to for it) Few of my questions are below:-- 1) Is there any development kit for developing applications for ReactOS? 2) If not, Will Applications developed using Windows SDK (not .net framework and all, just plain SDK) will work on ReactOS? 3) If Apps developed on Windows works on ReactOS, Are libraries developed for Windows (which just depend on kernel32, user32 and other system dlls) will work on ReactOS? I am planning to use ReactOS for one of my custom device (using x86 based processor) and want to develop some applications on top of it. Regards Deepak

16 years, 7 months

Public ddk headers vs ntoskrnl

by Timo Kreuzer

Hi, I am currently having a small problem on the x64 branch, maybe someone can help me. In wdm.h there's the following declarations: #if defined (_WIN64) #if defined(_NTDRIVER_) || defined(_NTDDK) || defined(_NTIFS_) || \ defined(_NTHAL_) || defined(_NTOSP_) NTKRNLAPI USHORT ExQueryDepthSList(IN PSLIST_HEADER Listhead); #else FORCEINLINE USHORT ExQueryDepthSList(IN PSLIST_HEADER Listhead) { return (USHORT)(ListHead->Alignment & 0xffff); } #endif #else #define ExQueryDepthSList(listhead) (listhead)->Depth #endif So when compiling ntoskrnl, ExQueryDepthSList is not inlined. Later in wdm.h (currently in our winddk.h, but to be moved to wdm.h) ExQueryDepthSList is used in ExFreeToNPagedLookasideList inline function. But I want ExQueryDepthSList to be inlined from within ntoskrnl. The question is how can I achieve this? If I #define it to be inline in ntoskrnl's private headers, it will not affect ExFreeToNPagedLookasideList. When I declare it as an inline function after the header is included, I get a warning that it was declared inline after being used and that a static declaration follows a non-static. (Does anyone know hoe to disable these stupid warnings?) Declaring it inline before including wdm.h doesn't work, as the needed declaration for SLIST_HEADER is missing. Anyone got any other idea? I'd like to avoid hacking our public headers, to keep them as compatible to ms headers as possible. Regards, Timo

16 years, 7 months

Re: [ros-dev] [ros-diffs] [dgorbachev] 39422: Fix bug #4129 in CmpGetNameControlBlock().

by Alex Ionescu

By reformatting my code and breaking ReactOS 1) Coding Style and 2) Commit Rules? On 5-Feb-09, at 4:30 PM, dgorbachev(a)svn.reactos.org wrote: > Author: dgorbachev > Date: Thu Feb 5 15:30:21 2009 > New Revision: 39422 > > URL: http://svn.reactos.org/svn/reactos?rev=39422&view=rev > Log: > Fix bug #4129 in CmpGetNameControlBlock(). > > Modified: > trunk/reactos/ntoskrnl/config/cmkcbncb.c > > Modified: trunk/reactos/ntoskrnl/config/cmkcbncb.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/config/cmkcbncb.c… > = > = > = > = > = > = > = > = > ====================================================================== > --- trunk/reactos/ntoskrnl/config/cmkcbncb.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/config/cmkcbncb.c [iso-8859-1] Thu Feb 5 > 15:30:21 2009 > @@ -175,15 +175,16 @@ > Length = NodeName->Length / sizeof(WCHAR); > for (i = 0; i < (NodeName->Length / sizeof(WCHAR)); i++) > { > - /* Check if this is a valid character */ > - if (*NodeName->Buffer > (UCHAR)-1) > + /* Check if this is a 16-bit character */ > + if (NodeName->Buffer[i] > (UCHAR)-1) > { > /* This is the actual size, and we know we're not > compressed */ > Length = NodeName->Length; > IsCompressed = FALSE; > - } > - } > - > + break; > + } > + } > + > /* Lock the NCB entry */ > CmpAcquireNcbLockExclusiveByKey(ConvKey); > > @@ -195,7 +196,7 @@ > Ncb = CONTAINING_RECORD(HashEntry, CM_NAME_CONTROL_BLOCK, > NameHash); > > /* Check if the hash matches */ > - if ((ConvKey = HashEntry->ConvKey) && (Length = Ncb- > >NameLength)) > + if (ConvKey == HashEntry->ConvKey && Length == Ncb- > >NameLength) > { > /* Assume success */ > Found = TRUE; > @@ -242,7 +243,7 @@ > /* Go to the next hash */ > HashEntry = HashEntry->NextHash; > } > - > + > /* Check if we didn't find it */ > if (!Found) > { > @@ -255,16 +256,15 @@ > CmpReleaseNcbLockByKey(ConvKey); > return NULL; > } > - > + > /* Clear it out */ > RtlZeroMemory(Ncb, NcbSize); > - > + > /* Check if the name was compressed */ > if (IsCompressed) > { > /* Copy the compressed name */ > - Ncb->Compressed = TRUE; > - for (i = 0; i < Length; i++) > + for (i = 0; i < NodeName->Length / sizeof(WCHAR); i++) > { > /* Copy Unicode to ANSI */ > ((PCHAR)Ncb->Name)[i] = > (CHAR)RtlUpcaseUnicodeChar(NodeName->Buffer[i]); > @@ -273,25 +273,25 @@ > else > { > /* Copy the name directly */ > - Ncb->Compressed = FALSE; > - for (i = 0; i < Length; i++) > + for (i = 0; i < NodeName->Length / sizeof(WCHAR); i++) > { > /* Copy each unicode character */ > Ncb->Name[i] = RtlUpcaseUnicodeChar(NodeName- > >Buffer[i]); > } > } > - > + > /* Setup the rest of the NCB */ > + Ncb->Compressed = IsCompressed; > Ncb->ConvKey = ConvKey; > Ncb->RefCount++; > Ncb->NameLength = Length; > - > + > /* Insert the name in the hash table */ > HashEntry = &Ncb->NameHash; > HashEntry->NextHash = GET_HASH_ENTRY(CmpNameCacheTable, > ConvKey).Entry; > GET_HASH_ENTRY(CmpNameCacheTable, ConvKey).Entry = HashEntry; > } > - > + > /* Release NCB lock */ > CmpReleaseNcbLockByKey(ConvKey); > > @@ -537,18 +537,18 @@ > } > > /* Check if there's no linked cell */ > - if (Kcb->KeyCell == HCELL_NIL) > + if (Kcb->KeyCell == HCELL_NIL) > { > /* Make sure it's a delete */ > - ASSERT(Kcb->Delete); > - KeyNode = NULL; > - } > + ASSERT(Kcb->Delete); > + KeyNode = NULL; > + } > else > { > /* Get the key node */ > - KeyNode = (PCM_KEY_NODE)HvGetCell(Kcb->KeyHive, Kcb->KeyCell); > - } > - > + KeyNode = (PCM_KEY_NODE)HvGetCell(Kcb->KeyHive, Kcb- > >KeyCell); > + } > + > /* Check if we got the node */ > if (!KeyNode) > { > @@ -561,7 +561,7 @@ > Kcb->ExtFlags &= ~CM_KCB_INVALID_CACHED_INFO; > Kcb->SubKeyCount = KeyNode->SubKeyCounts[Stable] + > KeyNode->SubKeyCounts[Volatile]; > - > + > /* Release the cell */ > HvReleaseCell(Kcb->KeyHive, Kcb->KeyCell); > } > @@ -865,12 +865,12 @@ > } > > /* Check if this is a KCB inside a frozen hive */ > - if ((Kcb) && (((PCMHIVE)Hive)->Frozen) && (!(Kcb->Flags & > KEY_SYM_LINK))) > + if ((Kcb) && (((PCMHIVE)Hive)->Frozen) && (!(Kcb->Flags & > KEY_SYM_LINK))) > { > /* Don't add these to the delay close */ > - Kcb->ExtFlags |= CM_KCB_NO_DELAY_CLOSE; > - } > - > + Kcb->ExtFlags |= CM_KCB_NO_DELAY_CLOSE; > + } > + > /* Sanity check */ > ASSERT((!Kcb) || (Kcb->Delete == FALSE)); > > Best regards, Alex Ionescu

16 years, 7 months

Re: [ros-dev] [ros-diffs] [janderwald] 39459: - Add a hack

by Timo Kreuzer

Very descriptive commit message ;-) janderwald(a)svn.reactos.org schrieb: > Author: janderwald > Date: Sat Feb 7 09:43:14 2009 > New Revision: 39459 > > URL: http://svn.reactos.org/svn/reactos?rev=39459&view=rev > Log: > - Add a hack > > Modified: > trunk/reactos/base/system/services/config.c > trunk/reactos/base/system/services/rpcserver.c > > Modified: trunk/reactos/base/system/services/config.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/system/services/confi… > ============================================================================== > --- trunk/reactos/base/system/services/config.c [iso-8859-1] (original) > +++ trunk/reactos/base/system/services/config.c [iso-8859-1] Sat Feb 7 09:43:14 2009 > @@ -289,7 +289,7 @@ > *lpValue = ptr; > } > > -done:; > +done: > if (dwError != ERROR_SUCCESS) > { > HeapFree(GetProcessHeap(), 0, ptr); > > Modified: trunk/reactos/base/system/services/rpcserver.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/system/services/rpcse… > ============================================================================== > --- trunk/reactos/base/system/services/rpcserver.c [iso-8859-1] (original) > +++ trunk/reactos/base/system/services/rpcserver.c [iso-8859-1] Sat Feb 7 09:43:14 2009 > @@ -4012,33 +4012,36 @@ > > if (InfoW.dwInfoLevel == SERVICE_CONFIG_DESCRIPTION) > { > - LPSERVICE_DESCRIPTIONW lpServiceDesriptonW; > - LPSERVICE_DESCRIPTIONA lpServiceDesriptonA; > - > - lpServiceDesriptonA = Info.psd; > - > - if (lpServiceDesriptonA && > - lpServiceDesriptonA->lpDescription) > - { > - dwLength = (strlen(lpServiceDesriptonA->lpDescription) + 1) * sizeof(WCHAR); > - > - lpServiceDesriptonW = HeapAlloc(GetProcessHeap(), > + LPSERVICE_DESCRIPTIONW lpServiceDescriptonW; > + LPSERVICE_DESCRIPTIONA lpServiceDescriptonA; > + > + lpServiceDescriptonA = Info.psd; > + > + ///if (lpServiceDescriptonA && > + ///lpServiceDescriptonA->lpDescription) > + ///{ > + dwLength = (strlen(Info.lpDescription) + 1) * sizeof(WCHAR); > + > + lpServiceDescriptonW = HeapAlloc(GetProcessHeap(), > 0, > dwLength + sizeof(SERVICE_DESCRIPTIONW)); > - if (!lpServiceDesriptonW) > + if (!lpServiceDescriptonW) > { > return ERROR_NOT_ENOUGH_MEMORY; > } > > + lpServiceDescriptonW->lpDescription = (LPWSTR)(lpServiceDescriptonW + 1); > + > MultiByteToWideChar(CP_ACP, > 0, > - lpServiceDesriptonA->lpDescription, > + Info.lpDescription, > -1, > - lpServiceDesriptonW->lpDescription, > + lpServiceDescriptonW->lpDescription, > dwLength); > > - ptr = lpServiceDesriptonW; > - } > + ptr = lpServiceDescriptonW; > + InfoW.psd = lpServiceDescriptonW; > + ///} > } > else if (Info.dwInfoLevel == SERVICE_CONFIG_FAILURE_ACTIONS) > { > @@ -4162,12 +4165,13 @@ > { > LPSERVICE_DESCRIPTIONW lpServiceDescription; > > - lpServiceDescription = (LPSERVICE_DESCRIPTIONW)&Info; > - lpServiceDescription->lpDescription = (LPWSTR)(&Info + sizeof(LPSERVICE_DESCRIPTIONW)); > + lpServiceDescription = (LPSERVICE_DESCRIPTIONW)Info.psd; > + lpServiceDescription->lpDescription = (LPWSTR)((ULONG_PTR)lpServiceDescription + sizeof(LPSERVICE_DESCRIPTIONW)); > > if (lpServiceDescription != NULL && > lpServiceDescription->lpDescription != NULL) > { > + DPRINT1("Setting value %S\n", lpServiceDescription->lpDescription); > RegSetValueExW(hServiceKey, > L"Description", > 0, > @@ -4212,7 +4216,7 @@ > LPWSTR lpDescriptionW = NULL; > LPSTR lpDescription = NULL; > > - DPRINT("RQueryServiceConfig2W() called\n"); > + DPRINT1("RQueryServiceConfig2A() called hService %p dwInfoLevel %u, lpBuffer %p cbBufSize %u pcbBytesNeeded %p\n",hService, dwInfoLevel, lpBuffer, cbBufSize, pcbBytesNeeded); > > if (!lpBuffer) > return ERROR_INVALID_ADDRESS; > @@ -4261,7 +4265,7 @@ > &lpDescriptionW); > if (dwError == ERROR_SUCCESS) > { > - *pcbBytesNeeded += ((wcslen(lpDescriptionW) + 1)); > + *pcbBytesNeeded += ((wcslen(lpDescriptionW) + 1) * sizeof(WCHAR)); > } > > if (cbBufSize >= *pcbBytesNeeded) > > >

16 years, 7 months

Re: [ros-dev] [ros-diffs] [cfinck] 39353: Gabriel Ilardi (gabrielilardi@hotmail.it) - Allow only one instance of Task-Manager to be run at the same time See issue #3976 for more details.

by Alex Ionescu

This won't be compatible with Windows applications. On 3-Feb-09, at 5:25 PM, cfinck(a)svn.reactos.org wrote: > Author: cfinck > Date: Tue Feb 3 16:25:39 2009 > New Revision: 39353 > > URL: http://svn.reactos.org/svn/reactos?rev=39353&view=rev > Log: > Gabriel Ilardi (gabrielilardi(a)hotmail.it) > - Allow only one instance of Task-Manager to be run at the same time > > See issue #3976 for more details. > > Modified: > trunk/reactos/base/applications/taskmgr/taskmgr.c > > Modified: trunk/reactos/base/applications/taskmgr/taskmgr.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/taskmgr/… > = > = > = > = > = > = > = > = > ====================================================================== > --- trunk/reactos/base/applications/taskmgr/taskmgr.c [iso-8859-1] > (original) > +++ trunk/reactos/base/applications/taskmgr/taskmgr.c [iso-8859-1] > Tue Feb 3 16:25:39 2009 > @@ -51,6 +51,12 @@ > HANDLE hProcess; > HANDLE hToken; > TOKEN_PRIVILEGES tkp; > + HANDLE hMutex; > + > + /* check wether we're already running or not */ > + hMutex = CreateMutexW(NULL, TRUE, L"taskmgrros"); > + if ((!hMutex) || (GetLastError() == ERROR_ALREADY_EXISTS)) > + return 1; > > /* Initialize global variables */ > hInst = hInstance; > Best regards, Alex Ionescu

16 years, 7 months

Re : [Qemu-devel] Virtio ballon device always loaded ?

by Sylvain Petreolle

Forwarded to ReactOS mailing list. (using correct address this time :) ----- Message d'origine ---- > De : Anthony Liguori <anthony(a)codemonkey.ws> > À : qemu-devel(a)nongnu.org > Envoyé le : Jeudi, 29 Janvier 2009, 22h55mn 12s > Objet : Re: [Qemu-devel] Virtio ballon device always loaded ? > > Sylvain Petreolle wrote: > > Testing ReactOS in qemu made it always asking drivers for a RAM Controller. > > > > Looking at "info pci" output and hw/pc.c, I see that the Virtio balloon device > is always loaded in an x86/64 target. > > Is that a wanted feature ? > > > > Sure, as I see no harm in not enabling it by default. ReactOS doesn't > just ignore unknown PCI devices? That's strange because Windows seems to. > > Regards, > > Anthony Liguori > > > I also notice that hw/virtio-balloon.c header refers to the Virtio Block > Device. > > > > Kind regards, > > Sylvain Petreolle > > > > > > > >

16 years, 7 months

[ros-diffs] [gschneider] 39217: Unify identical StretchBlt implementations in preparation of partial ROP suppport.

by James Tabor

Hi! Don't forget the Bug report number this is related to... Bolt aka BSTSoft is working hard on fixing this. Thanks, James Ref: http://www.reactos.org/bugzilla/show_bug.cgi?id=4075

16 years, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev