- Ros-dev - ReactOS.org

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

Re: [ros-dev] [ros-diffs] [mpiulachs] 31563: - Show localized error messages
by Ged Murphy 02 Jan '08

02 Jan '08

Can you fill the headers out correctly please? See any other the other reactos sources as to how this is done. There's also a wiki page detailing this. Thanks, Ged. +/* + * ReactOS kernel + * Copyright (C) 2003 ReactOS Team + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ +/* $Id: registry.h 21704 2006-04-22 13:55:01Z tretiakov $ + * COPYRIGHT: See COPYING in the top level directory + * PROJECT: ReactOS text-mode setup + * FILE: subsys/system/usetup/errcode.h + * PURPOSE: + * PROGRAMMER: + */

1 0

Re: [ros-dev] cursoricon.c
by tamlin＠algonet.se 02 Jan '08

02 Jan '08

oripipa wrote: >IS this correct? interpreting a shared cursos should never be destroyed? No. But then shared resources are not yet implemented (at least wasn't last I checked) why this code wasn't too incorrect. Your change most certainly is not right, as it'd make the code never remove anything from the list. Current code removes the process-owned icons (from the list) when the process terminates. Is this case really properly locked? I don't know. More research is needed for shared resources. -- Mike

2 1

Re: [ros-dev] [ros-diffs] [zguo] 31552: Finish editing all the documentation in ntddraw.
by Aleksey Bragin 02 Jan '08

02 Jan '08

On Jan 2, 2008, at 8:26 AM, zguo(a)svn.reactos.org wrote: > Author: zguo > Date: Wed Jan 2 08:26:00 2008 > New Revision: 31552 > > +* Before calling this function please set the > puCanCreateSurfaceData->ddRVal to an error value such as > DDERR_NOTUSPORTED, > +* The Function NtGdiD3dContextDestroy destorys the context data we > got from NtGdiD3dContextCreate Editing Magnus' text leads to a temporary syndrome of an obtained greatlordia (light form, fortunately) ;) WBR, Aleksey Bragin.

1 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 31536: [FORMATTING] Fix indentation
by Aleksey Bragin 01 Jan '08

01 Jan '08

It looks like the first part of the patch contains some new stuff along with reformatting. WBR, Aleksey Bragin. On Jan 1, 2008, at 9:55 PM, pschweitzer(a)svn.reactos.org wrote: > Author: pschweitzer > Date: Tue Jan 1 21:55:52 2008 > New Revision: 31536 > > URL: http://svn.reactos.org/svn/reactos?rev=31536&view=rev > Log: > [FORMATTING] Fix indentation > > Modified: > trunk/reactos/drivers/filesystems/ntfs/fsctl.c > > Modified: trunk/reactos/drivers/filesystems/ntfs/fsctl.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/ > filesystems/ntfs/fsctl.c?rev=31536&r1=31535&r2=31536&view=diff > ====================================================================== > ======== > --- trunk/reactos/drivers/filesystems/ntfs/fsctl.c (original) > +++ trunk/reactos/drivers/filesystems/ntfs/fsctl.c Tue Jan 1 > 21:55:52 2008 > @@ -54,64 +54,64 @@ > > like this: > - if (DiskGeometry.MediaType == FixedMedia) > + if (PartitionInfo.PartitionType != PARTITION_IFS)

1 0

Invitation to exhibit at SoCal Linux Expo 6x
by Gareth J. Greenaway 01 Jan '08

01 Jan '08

Greetings, I would like to formerly invite the ReactOS project to participate in the 6th Annual Southern California Linux Expo. The show will be taking place February 8th - 10th, 2008 in Los Angeles, CA conveniently located near the LAX airport. ReactOS had a presence at SCALE 5x, Alex Ionescu and a few community members showed off ReactOS and answered questions from attendees. It would be great having ReactOS at the show again for 2008. Because ReactOS is a dotORG organization, we would provide a complementary booth including all amenities such as electricity, Internet access, etc. We would also provide 3 complementary passes to the show for those people interested in representing ReactOS. If this sounds like something that someone from the ReactOS project might be interested in, I encourage you to fill out our dotORG Exhibitor Application which can be found here, http://www.socallinuxexpo.org/scale6x/conference-info/calls-for-papers/call… Any questions, please do not hesitate to ask. Thank you and Happy Holidays! Gareth -- Gareth J. Greenaway <g(a)socallinuxexpo.org> Voice - 877-831-2569 x130 Southern California Linux Expo http://www.socallinuxexpo.org

1 0

Happy New Year, ReactOS!
by Aleksey Bragin 31 Dec '07

31 Dec '07

Hi, it's 2 hours before the new year comes here, and I take this chance to wish our developers, testers, supporters, helpers, and everyone else a good, happy and lucky new year! It's been (and it still is!) a pleasure to work with you all (during all years, even if there were troubles), a lot of progress has been done. Everyone worked as hard as he was able to, and results are truly fantastic. I appreciate that a lot, and the new, coming year is going to be even more interesting! Happy New Year! With the best regards, Aleksey Bragin.

1 0

About GDIOBJHDR header changes
by Magnus Olsen 31 Dec '07

31 Dec '07

Hi I been working on dxg.sys some time now and documented some behovir, I started blackbox how DxLock work. it is base on gdi how thing it work, using same GDIOBJHDR struct. I do not go into detail here we all known who dx is handle in win32k in xp and higher. here is the public header of GDIOBJHDR typedef struct _GDIOBJHDR { HGDIOBJ hHmgr; PVOID unknownCount; ULONG cExcLock; ULONG Tid; }GDIOBJHDR, PGDIOBJHDR; I want change it to typedef struct _GDIOBJHDR { HGDIOBJ hHmgr; WORD Count; WORD Type; ULONG cExcLock; ULONG Tid; }GDIOBJHDR, PGDIOBJHDR; hHmgr Handle for this object. Count A counter of a kind Type which GDI Object type it is cExcLock if the object is lock or not Tid The Thread it belong to I hope we can do this change and I want comment and verify from Timo and Jim about this change

4 16

cursoricon.c
by Oriol 31 Dec '07

31 Dec '07

IS this correct? interpreting a shared cursos should never be destroyed? IntDestroyCurIconObject(PWINSTATION_OBJECT WinSta, PCURICON_OBJECT CurIcon, BOOL ProcessCleanup) { PSYSTEM_CURSORINFO CurInfo; HBITMAP bmpMask, bmpColor; BOOLEAN Ret; PCURICON_PROCESS Current = NULL; PW32PROCESS W32Process = PsGetCurrentProcessWin32Process(); /* Private objects can only be destroyed by their own process */ if (NULL == CurIcon->hModule) { ASSERT(CurIcon->ProcessList.Flink->Flink == &CurIcon->ProcessList); Current = CONTAINING_RECORD(CurIcon->ProcessList.Flink, CURICON_PROCESS, ListEntry); if (Current->Process != W32Process) { DPRINT1("Trying to destroy private icon/cursor of another process\n"); return FALSE; } } *--> else if (TRUE/*! ProcessCleanup*/) { DPRINT("Trying to destroy shared icon/cursor\n"); return FALSE; } ______________________________________________ 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

Re: [ros-dev] [ros-diffs] [greatlrd] 31509: Implement DxDdUnlockDirectDrawSurface Fixed smaller typo in DxDdLockDirectDrawSurface sorry
by Alex Ionescu 31 Dec '07

31 Dec '07

On 30-Dec-07, at 6:12 PM, greatlrd(a)svn.reactos.org wrote: > > + pSurfacelcl = (PDD_SURFACE_LOCAL)(((PBYTE)&pSurfacelcl) + > sizeof(DD_BASEOBJECT)); > This code makes absolutely no sense. You do realize you're returning a stack address, right? Best regards, Alex Ionescu

2 1

0.3.4 release
by Aleksey Bragin 27 Dec '07

27 Dec '07

Hi, the only critical blocker left on the release is the keyboard/mouse detection problem in qemu. There are a couple of other major issues related to the installation in qemu, but if they aren't solved by january, I'm ok to release with them. LiveCD is going to be partly broken too, because hardly any application starts in it, but I don't have time to fix this issue (if anyone volunteers - feel free to). The CursorIcon problem would be fun to have solved too (hint: janderwald & shell32). With the best regards, Aleksey Bragin.

4 3

Re: [ros-dev] compiling multiple .mcs
by Aleksey Bragin 24 Dec '07

24 Dec '07

Maybe let's postpone mc translations to further releases (like 0.4)? WBR, Aleksey Bragin. On Dec 24, 2007, at 5:21 AM, Timo Kreuzer wrote: > I have just compiled kernel32 with 2 different .mcs in the rbuild file > and it compiles without problems. > The resources shown by PE explorer were as expected the German ones > (2nd > mc file) > It also created 2 headers. > A slight change to the rbuild syntax could fix that problem: > > <file locale="en-US">lang/errcodes-en-US.mc</file> > <file locale="de-DE">lang/errcodes-de-DE.mc</file> > <mcheader target="include/psdk/errcodes.h>msg-en-US.mc</file> > > I had to manually add the #include to the rc file. This job should > also > be done by rbuild. > rbuild should create the rsrc.rc in the intermediate dir and > include all > locaized rcs and precompiled mcs for the languages > that are to be compiled. IIRC this feature is already in the rbuild > branch. > > Greeting, > Timo

1 0

compiling multiple .mcs
by Timo Kreuzer 24 Dec '07

24 Dec '07

I have just compiled kernel32 with 2 different .mcs in the rbuild file and it compiles without problems. The resources shown by PE explorer were as expected the German ones (2nd mc file) It also created 2 headers. A slight change to the rbuild syntax could fix that problem: <file locale="en-US">lang/errcodes-en-US.mc</file> <file locale="de-DE">lang/errcodes-de-DE.mc</file> <mcheader target="include/psdk/errcodes.h>msg-en-US.mc</file> I had to manually add the #include to the rc file. This job should also be done by rbuild. rbuild should create the rsrc.rc in the intermediate dir and include all locaized rcs and precompiled mcs for the languages that are to be compiled. IIRC this feature is already in the rbuild branch. Greeting, Timo

1 0

BETA Version of RosBE-Unix 1.1
by Colin Finck 22 Dec '07

22 Dec '07

Hello everybody, For your information, I finished a new version of RosBE-Unix. To be on the safe side, I marked it as a BETA version, so you still have time to try it out :-) You can get the BETA version of RosBE-Unix 1.1 from http://reactos.colinfinck.de. The major changes are updated compilers (they are exactly the same as in RosBE-Windows 1.1 now) and several bug fixes. A complete list of changes is available here: http://www.reactos.org/forum/viewtopic.php?p=39179#39179. Please try it out and report bugs if you find some. Best regards, Colin Finck

1 0

Re: [ros-dev] [ros-diffs] [hpoussin] 31369: No need to compile libxml2, as it is not used
by Steven Edwards 21 Dec '07

21 Dec '07

On Dec 21, 2007 5:26 AM, <hpoussin(a)svn.reactos.org> wrote: > Author: hpoussin > Date: Fri Dec 21 13:26:41 2007 > New Revision: 31369 > > URL: http://svn.reactos.org/svn/reactos?rev=31369&view=rev > Log: > No need to compile libxml2, as it is not used It should be. If you change the config.h for the wine modules and add an include path so that msi and msxml can find the libxml2 public headers and compile I bet Office 2003 and friends will install on ReactOS. -- 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

1 0

Re: [ros-dev] [ros-diffs] [fireball] 31324: - Changed .spec back to .def again (this time .def is a modified output of that .spec, so that stdcall exported symbols are not decorated with @X). - Added winebuild-generated "real" stubs, to be converted to real implementation in the future.
by Aleksey Bragin 19 Dec '07

19 Dec '07

Generic behavior is to 1) use .spec for DLLs (because usually DLLs are shared with Wine, which uses the same format), but for msvcrt it was not possible. 2) implement a stub as soon as possible whenever it is hit WBR, Aleksey Bragin. On Dec 19, 2007, at 4:20 PM, Sylvain Petreolle wrote: > Could these stubs be added to other dlls too ? > > For example, audiosrv crashes is being killed by EXCEPTION_WINE_STUB, > because setupapi misses the CMP_RegisterNotification function. > > Kind regards, > Sylvain Petreolle (aka Usurp)

1 0

[ros-diffs] [fireball] 31324: - Changed .spec back to .def again (this time .def is a modified output of that .spec, so that stdcall exported symbols are not decorated with @X). - Added winebuild-generated "real" stubs, to be converted to real implementation in the future.
by Sylvain Petreolle 19 Dec '07

19 Dec '07

Could these stubs be added to other dlls too ? For example, audiosrv crashes is being killed by EXCEPTION_WINE_STUB, because setupapi misses the CMP_RegisterNotification function. 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

1 0

Re: [ros-dev] [ros-diffs] [cfinck] 31298: Revert 31292, 31294 and 31297. Every change I try for fixing the build in one component breaks the build for another component. winebuild wasn't synchronized completely to the Wine version anyway, and the cur
by Steven Edwards 19 Dec '07

19 Dec '07

On Dec 18, 2007 6:03 AM, Aleksey Bragin <aleksey(a)reactos.org> wrote: > I merged it, taking in account winebuild's changes (using output() > function for example), so in 31300 it seems to work correctly. > > I didn't really understood that AJ's message - Wine does not need > stubs as stubbed functions at all, but rather want all of them to be > manually implemented in a standalone .c file as stubs? or? As we discused on IRC he wants to do away with pseudo-stubs or at least does not think they should be used in a PE build. I tend to agree a function should either be implemented, fully stubbed or not there at all unless an application is proven to need it. Needless stubbing results in breakage when an application calls GetProcAddress/LoadLibrary and would normally fail with grace if the function is not there. Instead it can hit one of these fake stubs, assume its safe to keep working and blow up on you. As for your other question about decoration in mangled symbols for stdcall functions I am not quite sure I understand it. The only decorated functions I saw in the spec file were all cdecl. There were others that are exported variables and some stdcall functions but they did not have decoration unless I just missed it. -- 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

1 0

Re: [ros-dev] [ros-diffs] [cfinck] 31298: Revert 31292, 31294 and 31297. Every change I try for fixing the build in one component breaks the build for another component. winebuild wasn't synchronized completely to the Wine version anyway, and the current Wine
by Aleksey Bragin 18 Dec '07

18 Dec '07

I merged it, taking in account winebuild's changes (using output() function for example), so in 31300 it seems to work correctly. I didn't really understood that AJ's message - Wine does not need stubs as stubbed functions at all, but rather want all of them to be manually implemented in a standalone .c file as stubs? or? WBR, Aleksey Bragin. On Dec 18, 2007, at 5:11 AM, Steven Edwards wrote: > On Dec 17, 2007 6:36 PM, <cfinck(a)svn.reactos.org> wrote: >> Every change I try for fixing the build in one component breaks >> the build for another component. >> winebuild wasn't synchronized completely to the Wine version >> anyway, and the current Wine version removed support for the -- >> pedll option we use, so a full clean sync isn't possible. > > Can you merge the --pedll patch up to the trunk rather than reverting? > You might want to comment out the stubs anyway or add real stubs and > submit them to wine as per Alexandre's rejection of the patch by GvG > > http://www.winehq.org/pipermail/wine-devel/2004-December/031978.html > > Thanks > -- > 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

1 0

Re: [ros-dev] [ros-diffs] [cfinck] 31298: Revert 31292, 31294 and 31297. Every change I try for fixing the build in one component breaks the build for another component. winebuild wasn't synchronized completely to the Wine version anyway, and the current Wine
by Steven Edwards 18 Dec '07

18 Dec '07

On Dec 17, 2007 6:36 PM, <cfinck(a)svn.reactos.org> wrote: > Every change I try for fixing the build in one component breaks the build for another component. > winebuild wasn't synchronized completely to the Wine version anyway, and the current Wine version removed support for the --pedll option we use, so a full clean sync isn't possible. Can you merge the --pedll patch up to the trunk rather than reverting? You might want to comment out the stubs anyway or add real stubs and submit them to wine as per Alexandre's rejection of the patch by GvG http://www.winehq.org/pipermail/wine-devel/2004-December/031978.html Thanks -- 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

1 0

Re: [ros-dev] DLL Base Addresses (For Marc)
by Aleksey Bragin 17 Dec '07

17 Dec '07

On Dec 16, 2007, at 4:10 PM, Marc Piulachs wrote: > Hi Alex, > > Let me see if I understood this correctly. The problem is not > really on > manually choosing the base address, the problem is that module's > "baseaddress" attribute is optional, even when the module is of type > "win32dll", if this attribute is empty rbuild sets a common default > base > address (0x10000000 for win32 dll's). No, the problem is exactly choosing the address: modules overlap with each other, and manually calculating baseaddresses often doesn't work. Alex proposed to automate this process and do a baseaddress.rbuild file generator. There are not many dlls with baseaddress missing, and if it's missing, it should be added to those (in trunk). > AFAIK we are using the same base address that the equivalent > component has > on windows so auto generating it using any sort of tool is not > really an > option. Not really, in most cases (might be with a few exceptions), it's not possible to use exactly Windows' base address (because size of our modules and windows modules often differs). The problem is to distribute the dlls in the memory address space so that they don't overlap. As for baseaddress in xml form - baseaddress is a module's property, it's not a standalone object which is part of the module. I don't see why it should be given a standalone tag (maybe I'm missing something). WBR, Aleksey Bragin.

6 7

Re: [ros-dev] [ros-diffs] [cfinck] 31296: Rename DSOUND_DllRegisterServer to DllRegisterServer and DSOUND_DllUnregisterServer to DllUnregisterServer. (the same is already done in the other DirectX DLL's with SPEC files) I wonder how dsound.dll could be compile
by Steven Edwards 17 Dec '07

17 Dec '07

Hello, On Dec 17, 2007 5:01 PM, <cfinck(a)svn.reactos.org> wrote: > URL: http://svn.reactos.org/svn/reactos?rev=31296&view=rev > Log: > Rename DSOUND_DllRegisterServer to DllRegisterServer and DSOUND_DllUnregisterServer to DllUnregisterServer. (the same is already done in the other DirectX DLL's with SPEC files) > I wonder how dsound.dll could be compiled in the past cause the SPEC file never referenced to these functions. Maybe there was a bug in older versions of binutils. Perhaps it was ignoring unresolved exports marked PRIVATE. -- 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

1 1

MESSAGETABLE localisation
by Timo Kreuzer 16 Dec '07

16 Dec '07

I have thought about localizing our messagetables, like kernel32's errorcodes.mc Now the question is: how do we do this? We could simply add all localisations inside the current file without changing anything else in the build process. I didn't test if it works, but it should. But it would lead to huge files full of different languages and would also remove the possibility for custom selection of the languages that are compiled. I would prefer to go the way we do with other localisation: put different .mc files in the lang subfolder. But afaik mc files don't allow inclusion of external files, so we need some build process that compiles the different mc files into rc files and include those into a main rc file. Currently our mcs are defined in makefile. This should move to the rbuild files and rbuild should compile the mc files and create the needed rc: <module...> ... <file>foo.c</file> <file>foo.rc</file> ... <autoresource>auto.rc</autoresource> <localization isoname="de-DE">lang/de-DE.rc</localization> <msgtable isoname="de-DE">lang/msgtable-de-DE.mc</msgtable> </module> rbuild would generate <intermediate dir>\lang\msgtable-de-DE.mc.rc and auto.rc containing includes to the generated files. IMO auto.rc should be the file that is compiled, including all localizations and the unlocalized resource file. #include "lang/de-DE.rc" #include "lang/msgtable-de-DE.mc.rc" If I understood Fireball correctly, this is also msvc compatible. And if not, rbuild just would have to generate the files differently. Some ideas for simplifying the rbuild definitions: Instead of <file>, <localization> and <msgtable> we could simply use <file> for unconditional compilation, <file locale="en-US"> for localized conditional compilation. And then let rbuild decide from the file extension what to do with it. resources/messagetables could automatically be included in an autogenerated rc file, without explicitly defining it in the rbuild file. Regards, Timo

3 3

Re: [ros-dev] [ros-diffs] [greatlrd] 31268: fix a typo
by Simon Blomqvist 16 Dec '07

16 Dec '07

Is this code for human ? "@@ -81,7 +81,7 @@ * if they forget set it, the ddraw will autoamtic * set it for system memory. */ - if ((pDDSD->dwFlags & DDSCAPS_SYSTEMMEMORY) != DDSCAPS_SYSTEMMEMORY) + if ((pDDSD->ddsCaps.dwCaps & DDSCAPS_SYSTEMMEMORY) == DDSCAPS_SYSTEMMEMORY) { pDDSD->dwFlags = pDDSD->dwFlags | DDSD_LPSURFACE; }" On Dec 16, 2007 1:46 AM, <greatlrd(a)svn.reactos.org> wrote: > Author: greatlrd > Date: Sun Dec 16 03:46:43 2007 > New Revision: 31268 > > URL: http://svn.reactos.org/svn/reactos?rev=31268&view=rev > Log: > fix a typo > > Modified: > trunk/reactos/dll/directx/ddraw/Surface/createsurface.c > > Modified: trunk/reactos/dll/directx/ddraw/Surface/createsurface.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/directx/ddraw/Surface/… > > ============================================================================== > --- trunk/reactos/dll/directx/ddraw/Surface/createsurface.c (original) > +++ trunk/reactos/dll/directx/ddraw/Surface/createsurface.c Sun Dec 16 > 03:46:43 2007 > @@ -81,7 +81,7 @@ > * if they forget set it, the ddraw will autoamtic > * set it for system memory. > */ > - if ((pDDSD->dwFlags & DDSCAPS_SYSTEMMEMORY) != DDSCAPS_SYSTEMMEMORY) > + if ((pDDSD->ddsCaps.dwCaps & DDSCAPS_SYSTEMMEMORY) == > DDSCAPS_SYSTEMMEMORY) > { > pDDSD->dwFlags = pDDSD->dwFlags | DDSD_LPSURFACE; > } > > > -- MVH Simon Blomqvist Tel - 0735307474 IT www.AgentEyes.com Internet Café www.cafe.agenteyes.com Konst www.konstgrossisten.com/ Jag ringer gratis med www.skype.se mitt id är: simonblomqvist

1 0

gdi object code optimization
by James Tabor 14 Dec '07

14 Dec '07

Hi! Let us start on this now.... It is time to restructure the GDI OBJ Lock Unlock mess! Don't wait for me. I'm working on the DCE issue which is a mess due to gdiobj.c over think object locking system. The new ideas I have will not be compatible with the current system. Thanks, James

3 2

GDI_TABLE_ENTRY structure
by James Tabor 14 Dec '07

14 Dec '07

Hi! Sorry for the delay here,,, This is what we know to be correct sofar. The "Book" section 3.4 GdiTableCell structure is not necessarily correct. typedef struct _GDI_TABLE_ENTRY { PVOID KernelData; SHORT Count:15; Count number of refs. SHORT Lock:1; Does set if locked by process. It also explains why the count shows 1 -> 3 most of the time. SHORT ProcessId; Process Id is here. SHORT nUpper; should match the upper half of the handle. CHAR ObjectType; example-> 0x0401, // not all memdc, dc =1, etc,,, CHAR Flags; --> 0x04 is here, set if memdc, sometimes~. PVOID UserData; } GDI_TABLE_ENTRY, *PGDI_TABLE_ENTRY; Thanks, James

2 1

[ros-diffs] [jimtabor] 31204: Up the handle count to 0x10000, reset adjustment to support change. Add device capabilities to handle table.
by Timo Kreuzer 14 Dec '07

14 Dec '07

why waste the last handle? > author: jimtabor > Date: Thu Dec 13 23:27:28 2007 > New Revision: 31204 > - for ( i = RESERVE_ENTRIES_COUNT; i < GDI_HANDLE_COUNT; i++ ) > + for ( i = RESERVE_ENTRIES_COUNT; i < GDI_HANDLE_COUNT-1; i++ > - if (HandleIndex >= GDI_HANDLE_COUNT) > + if (HandleIndex >= GDI_HANDLE_COUNT-1)

3 3

build error with RoseBE on Fedora 8
by kevin yin 14 Dec '07

14 Dec '07

hello everyone: there some chinese character in the attechment( make.log ),have replaced to english. there is some output on the console below: [root@YINSG664A RosBE-Unix-0.3.6]# ./RosBE-Builder.sh ******************************************************************************* * ReactOS Build Environment for Unix-based Operating Systems * * Builder Tool * * by Colin Finck <mail(a)colinfinck.de> * * * * Version 0.3.6 * ******************************************************************************* This script compiles and installs a complete Build Environment for building ReactOS. Checking for the needed tools... Checking for bison... OK Checking for flex... OK Checking for gcc... OK Checking for g++... OK Checking for grep... OK Checking for makeinfo... OK Checking for GNU Make... OK Installation Directory In which directory do you want to install it? Enter the path to the directory here or simply press ENTER to install it into the default directory. [/usr/RosBE] The directory "/usr/RosBE" does not exist. The installation script will create it for you. Ready to start Ready to build and install the ReactOS Build Environment. Press ENTER to continue or any other key to exit. Building... Extracting mingw-runtime... OK Extracting w32api... OK Extracting binutils... OK Configuring binutils... OK Building binutils... FAILED Please take a look at the log file "/home/enjoyo/RosBE-Unix-0.3.6/make.log" If you did not do something wrong, please save the log file and contact the ReactOS Team. Aborted! make[1]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build' mkdir -p -- ./intl Configuring in ./intl configure: creating cache ./config.cache checking whether make sets $(MAKE)... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether NLS is requested... no checking for msgfmt... /usr/bin/msgfmt checking for gmsgfmt... /usr/bin/msgfmt checking for xgettext... /usr/bin/xgettext checking for msgmerge... /usr/bin/msgmerge checking for i686-pc-linux-gnu-gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for i686-pc-linux-gnu-ranlib... ranlib checking for library containing strerror... none required checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking for ANSI C header files... yes checking for an ANSI C-conforming const... yes checking for inline... inline checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for off_t... yes checking for size_t... yes checking for working alloca.h... yes checking for alloca... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking whether we are using the GNU C Library 2.1 or newer... yes checking whether integer division by zero raises SIGFPE... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unsigned long long... yes checking for inttypes.h... yes checking whether the inttypes.h PRIxNN macros are broken... no checking for ld used by GCC... ld checking if the linker (ld) is GNU ld... yes checking for shared library run path origin... done checking argz.h usability... yes checking argz.h presence... yes checking for argz.h... yes checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking nl_types.h usability... yes checking nl_types.h presence... yes checking for nl_types.h... yes checking malloc.h usability... yes checking malloc.h presence... yes checking for malloc.h... yes checking stddef.h usability... yes checking stddef.h presence... yes checking for stddef.h... yes checking for stdlib.h... (cached) yes checking for string.h... (cached) yes checking for unistd.h... (cached) yes checking sys/param.h usability... yes checking sys/param.h presence... yes checking for sys/param.h... yes checking for feof_unlocked... yes checking for fgets_unlocked... yes checking for getc_unlocked... yes checking for getcwd... yes checking for getegid... yes checking for geteuid... yes checking for getgid... yes checking for getuid... yes checking for mempcpy... yes checking for munmap... yes checking for putenv... yes checking for setenv... yes checking for setlocale... yes checking for stpcpy... yes checking for strcasecmp... yes checking for strdup... yes checking for strtoul... yes checking for tsearch... yes checking for __argz_count... yes checking for __argz_stringify... yes checking for __argz_next... yes checking for __fsetlocking... yes checking for iconv... yes checking for iconv declaration... extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft); checking for nl_langinfo and CODESET... yes checking for LC_MESSAGES... yes checking for bison... bison checking version of bison... 2.3, ok checking whether NLS is requested... no checking whether to use NLS... no checking for aclocal... aclocal checking for autoconf... autoconf checking for autoheader... autoheader updating cache ./config.cache configure: creating ./config.status config.status: creating Makefile config.status: creating config.intl config.status: creating config.h config.status: executing default-1 commands mkdir -p -- ./libiberty Configuring in ./libiberty configure: creating cache ./config.cache checking whether to enable maintainer-specific portions of Makefiles... no checking for makeinfo... /home/enjoyo/RosBE-Unix-0.3.6/sources/binutils/missing makeinfo --split-size=5000000 configure: WARNING: *** Makeinfo is missing. Info documentation will not be built. checking for perl... perl checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for i686-pc-linux-gnu-ar... ar checking for i686-pc-linux-gnu-ranlib... ranlib checking for i686-pc-linux-gnu-gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E checking whether gcc accepts -Wc++-compat... yes checking whether gcc and cc understand -c and -o together... yes checking for an ANSI C-conforming const... yes checking for inline... inline checking whether byte ordering is bigendian... no checking for a BSD-compatible install... /usr/bin/install -c checking for sys/file.h... yes checking for sys/param.h... yes checking for limits.h... yes checking for stdlib.h... yes checking for malloc.h... yes checking for string.h... yes checking for unistd.h... yes checking for strings.h... yes checking for sys/time.h... yes checking for time.h... yes checking for sys/resource.h... yes checking for sys/stat.h... yes checking for sys/mman.h... yes checking for fcntl.h... yes checking for alloca.h... yes checking for sys/pstat.h... no checking for sys/sysmp.h... no checking for sys/sysinfo.h... yes checking for machine/hal_sysinfo.h... no checking for sys/table.h... no checking for sys/sysctl.h... yes checking for sys/systemcfg.h... no checking for stdint.h... yes checking for stdio_ext.h... yes checking for sys/wait.h that is POSIX.1 compatible... yes checking whether time.h and sys/time.h may both be included... yes checking whether errno must be declared... no checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... (cached) yes checking for stdlib.h... (cached) yes checking for string.h... (cached) yes checking for memory.h... yes checking for strings.h... (cached) yes checking for inttypes.h... yes checking for stdint.h... (cached) yes checking for unistd.h... (cached) yes checking for int... yes checking size of int... 4 checking for uintptr_t... yes checking for a 64-bit type... uint64_t checking for pid_t... yes checking for library containing strerror... none required checking for asprintf... yes checking for atexit... yes checking for basename... yes checking for bcmp... yes checking for bcopy... yes checking for bsearch... yes checking for bzero... yes checking for calloc... yes checking for clock... yes checking for ffs... yes checking for getcwd... yes checking for getpagesize... yes checking for gettimeofday... yes checking for index... yes checking for insque... yes checking for memchr... yes checking for memcmp... yes checking for memcpy... yes checking for memmove... yes checking for mempcpy... yes checking for memset... yes checking for mkstemps... no checking for putenv... yes checking for random... yes checking for rename... yes checking for rindex... yes checking for setenv... yes checking for snprintf... yes checking for sigsetmask... yes checking for stpcpy... yes checking for stpncpy... yes checking for strcasecmp... yes checking for strchr... yes checking for strdup... yes checking for strncasecmp... yes checking for strndup... yes checking for strrchr... yes checking for strstr... yes checking for strtod... yes checking for strtol... yes checking for strtoul... yes checking for strverscmp... yes checking for tmpnam... yes checking for vasprintf... yes checking for vfprintf... yes checking for vprintf... yes checking for vsnprintf... yes checking for vsprintf... yes checking for waitpid... yes checking whether alloca needs Cray hooks... no checking stack direction for C alloca... -1 checking for unistd.h... (cached) yes checking for vfork.h... no checking for fork... yes checking for vfork... yes checking for working fork... yes checking for working vfork... (cached) yes checking for _doprnt... no checking for sys_errlist... yes checking for sys_nerr... yes checking for sys_siglist... yes checking for external symbol _system_configuration... no checking for getrusage... yes checking for on_exit... yes checking for psignal... yes checking for strerror... yes checking for strsignal... yes checking for sysconf... yes checking for times... yes checking for sbrk... yes checking for gettimeofday... (cached) yes checking for realpath... yes checking for canonicalize_file_name... yes checking for pstat_getstatic... no checking for pstat_getdynamic... no checking for sysmp... no checking for getsysinfo... no checking for table... no checking for sysctl... yes checking for wait3... yes checking for wait4... yes checking for __fsetlocking... yes checking whether basename is declared... no checking whether ffs is declared... yes checking whether asprintf is declared... no checking whether vasprintf is declared... no checking whether snprintf is declared... yes checking whether vsnprintf is declared... yes checking whether calloc is declared... yes checking whether getenv is declared... yes checking whether getopt is declared... yes checking whether malloc is declared... yes checking whether realloc is declared... yes checking whether sbrk is declared... yes checking whether strverscmp is declared... no checking whether canonicalize_file_name must be declared... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... (cached) yes checking for working mmap... yes checking for working strncmp... yes updating cache ./config.cache configure: creating ./config.status config.status: creating Makefile config.status: creating testsuite/Makefile config.status: creating config.h config.status: executing default commands mkdir -p -- ./bfd Configuring in ./bfd configure: creating cache ./config.cache checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i386-pc-mingw32 checking for i686-pc-linux-gnu-gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for library containing strerror... none required checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for i686-pc-linux-gnu-ar... ar checking for i686-pc-linux-gnu-ranlib... ranlib checking for i686-pc-linux-gnu-gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking for ld used by GCC... ld checking if the linker (ld) is GNU ld... yes checking for ld option to reload object files... -r checking for BSD-compatible nm... nm checking whether ln -s works... yes checking how to recognise dependant libraries... pass_all checking the maximum length of command line arguments... none checking for i686-pc-linux-gnu-ranlib... (cached) ranlib checking for i686-pc-linux-gnu-strip... no checking for strip... strip updating cache ./config.cache loading cache ./config.cache within ltconfig checking for objdir... .libs checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... yes finding the maximum length of command line arguments... 49153 checking if gcc supports -c -o file.o... yes checking if gcc supports -fno-rtti -fno-exceptions ... no checking whether the linker (ld) supports shared libraries... yes checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... GNU/Linux ld.so checking command to parse nm output... ok checking if libtool supports shared libraries... yes checking whether to build shared libraries... no checking whether to build static libraries... yes creating libtool updating cache ./config.cache configure: loading cache ./config.cache Setting warning flags = -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror checking whether to enable maintainer-specific portions of Makefiles... no checking whether to install libbfd... no checking whether NLS is requested... no checking whether NLS is requested... no checking for msgfmt... /usr/bin/msgfmt checking for gmsgfmt... /usr/bin/msgfmt checking for xgettext... /usr/bin/xgettext checking for msgmerge... /usr/bin/msgmerge checking for a BSD-compatible install... /usr/bin/install -c checking for long long... yes checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for long long... yes checking size of long long... 8 checking for long... yes checking size of long... 4 checking stddef.h usability... yes checking stddef.h presence... yes checking for stddef.h... yes checking for string.h... (cached) yes checking for strings.h... (cached) yes checking for stdlib.h... (cached) yes checking time.h usability... yes checking time.h presence... yes checking for time.h... yes checking for unistd.h... (cached) yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking whether time.h and sys/time.h may both be included... yes checking for dirent.h that defines DIR... yes checking for library containing opendir... none required checking whether string.h and strings.h may both be included... yes checking for fcntl... yes checking for getpagesize... yes checking for setitimer... yes checking for sysconf... yes checking for fdopen... yes checking for getuid... yes checking for getgid... yes checking for strtoull... yes checking whether basename is declared... yes checking whether ftello is declared... yes checking whether ftello64 is declared... yes checking whether fseeko is declared... yes checking whether fseeko64 is declared... yes checking whether ffs is declared... yes checking whether free is declared... yes checking whether getenv is declared... yes checking whether malloc is declared... yes checking whether realloc is declared... yes checking whether stpcpy is declared... yes checking whether strstr is declared... yes checking whether snprintf is declared... yes checking whether vsnprintf is declared... yes checking for ftello... yes checking for ftello64... yes checking for fseeko... yes checking for fseeko64... yes checking for fopen64... yes checking for off_t... yes checking size of off_t... 4 checking file_ptr type... BFD_HOST_64_BIT checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... (cached) yes checking for working mmap... yes checking for madvise... yes checking for mprotect... yes updating cache ./config.cache configure: creating ./config.status config.status: creating Makefile config.status: creating doc/Makefile config.status: creating bfd-in3.h config.status: creating po/Makefile.in config.status: creating config.h config.status: executing depfiles commands config.status: executing default-1 commands config.status: executing default commands make[2]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/libiberty' if [ x"" != x ] && [ ! -d pic ]; then \ mkdir pic; \ else true; fi touch stamp-picdir if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/regex.c -o pic/regex.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/regex.c -o regex.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/cplus-dem.c -o pic/cplus-dem.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/cplus-dem.c -o cplus-dem.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/cp-demangle.c -o pic/cp-demangle.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/cp-demangle.c -o cp-demangle.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/md5.c -o pic/md5.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/md5.c -o md5.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/alloca.c -o pic/alloca.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/alloca.c -o alloca.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/argv.c -o pic/argv.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/argv.c -o argv.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/choose-temp.c -o pic/choose-temp.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/choose-temp.c -o choose-temp.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/concat.c -o pic/concat.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/concat.c -o concat.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/cp-demint.c -o pic/cp-demint.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/cp-demint.c -o cp-demint.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/dyn-string.c -o pic/dyn-string.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/dyn-string.c -o dyn-string.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/fdmatch.c -o pic/fdmatch.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/fdmatch.c -o fdmatch.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/fibheap.c -o pic/fibheap.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/fibheap.c -o fibheap.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/filename_cmp.c -o pic/filename_cmp.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/filename_cmp.c -o filename_cmp.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/floatformat.c -o pic/floatformat.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/floatformat.c -o floatformat.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/fnmatch.c -o pic/fnmatch.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/fnmatch.c -o fnmatch.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/fopen_unlocked.c -o pic/fopen_unlocked.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/fopen_unlocked.c -o fopen_unlocked.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/getopt.c -o pic/getopt.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/getopt.c -o getopt.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/getopt1.c -o pic/getopt1.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/getopt1.c -o getopt1.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/getpwd.c -o pic/getpwd.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/getpwd.c -o getpwd.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/getruntime.c -o pic/getruntime.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/getruntime.c -o getruntime.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/hashtab.c -o pic/hashtab.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/hashtab.c -o hashtab.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/hex.c -o pic/hex.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/hex.c -o hex.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/lbasename.c -o pic/lbasename.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/lbasename.c -o lbasename.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/lrealpath.c -o pic/lrealpath.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/lrealpath.c -o lrealpath.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/make-relative-prefix.c -o pic/make-relative-prefix.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/make-relative-prefix.c -o make-relative-prefix.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/make-temp-file.c -o pic/make-temp-file.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/make-temp-file.c -o make-temp-file.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/objalloc.c -o pic/objalloc.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/objalloc.c -o objalloc.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/obstack.c -o pic/obstack.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/obstack.c -o obstack.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/partition.c -o pic/partition.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/partition.c -o partition.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/pexecute.c -o pic/pexecute.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/pexecute.c -o pexecute.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/physmem.c -o pic/physmem.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/physmem.c -o physmem.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/pex-common.c -o pic/pex-common.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/pex-common.c -o pex-common.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/pex-one.c -o pic/pex-one.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/pex-one.c -o pex-one.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/pex-unix.c -o pic/pex-unix.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/pex-unix.c -o pex-unix.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/safe-ctype.c -o pic/safe-ctype.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/safe-ctype.c -o safe-ctype.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/sort.c -o pic/sort.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/sort.c -o sort.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/spaces.c -o pic/spaces.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/spaces.c -o spaces.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/splay-tree.c -o pic/splay-tree.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/splay-tree.c -o splay-tree.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/strerror.c -o pic/strerror.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/strerror.c -o strerror.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/strsignal.c -o pic/strsignal.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/strsignal.c -o strsignal.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/ternary.c -o pic/ternary.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/ternary.c -o ternary.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/unlink-if-ordinary.c -o pic/unlink-if-ordinary.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/unlink-if-ordinary.c -o unlink-if-ordinary.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/xatexit.c -o pic/xatexit.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/xatexit.c -o xatexit.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/xexit.c -o pic/xexit.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/xexit.c -o xexit.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/xmalloc.c -o pic/xmalloc.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/xmalloc.c -o xmalloc.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/xmemdup.c -o pic/xmemdup.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/xmemdup.c -o xmemdup.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/xstrdup.c -o pic/xstrdup.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/xstrdup.c -o xstrdup.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/xstrerror.c -o pic/xstrerror.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/xstrerror.c -o xstrerror.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/xstrndup.c -o pic/xstrndup.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/xstrndup.c -o xstrndup.o if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/mkstemps.c -o pic/mkstemps.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -O2 -fno-exceptions -I. -I../../binutils/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../binutils/libiberty/mkstemps.c -o mkstemps.o rm -f ./libiberty.a pic/./libiberty.a ar rc ./libiberty.a \ ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./alloca.o ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./dyn-string.o ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o ./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative-prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./safe-ctype.o ./sort.o ./spaces.o ./splay-tree.o ./strerror.o ./strsignal.o ./ternary.o ./unlink-if-ordinary.o ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./xstrndup.o ./mkstemps.o ranlib ./libiberty.a if [ x"" != x ]; then \ cd pic; \ ar rc ./libiberty.a \ ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./alloca.o ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./dyn-string.o ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o ./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative-prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./safe-ctype.o ./sort.o ./spaces.o ./splay-tree.o ./strerror.o ./strsignal.o ./ternary.o ./unlink-if-ordinary.o ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./xstrndup.o ./mkstemps.o; \ ranlib ./libiberty.a; \ cd ..; \ else true; fi rm -f needed-list; touch needed-list; \ for f in atexit calloc memchr memcmp memcpy memmove memset rename strchr strerror strncmp strrchr strstr strtol strtoul tmpnam vfprintf vprintf vfork waitpid bcmp bcopy bzero; do \ for g in ./mkstemps.o ; do \ case "$g" in \ *$f*) echo $g >> needed-list ;; \ esac; \ done; \ done echo ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./alloca.o ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./dyn-string.o ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o ./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative-prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./safe-ctype.o ./sort.o ./spaces.o ./splay-tree.o ./strerror.o ./strsignal.o ./ternary.o ./unlink-if-ordinary.o ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./xstrndup.o > required-list make[3]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/libiberty/testsuite' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/libiberty/testsuite' make[2]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/libiberty' make[2]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/intl' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/intl' make[2]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd' Making info in doc make[3]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' make chew make[4]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' gcc -o chew.$$ ../../../binutils/bfd/doc/chew.c \ -g -O2 \ -I.. -I../../../binutils/bfd/doc/.. -I../../../binutils/bfd/doc/../../include -I../../../binutils/bfd/doc/../../intl -I../../intl; \ /bin/sh ../../../binutils/bfd/doc/../../move-if-change chew.$$ chew make[4]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' ./chew -f ../../../binutils/bfd/doc/doc.str <../../../binutils/bfd/doc/../aoutx.h >aoutx.tmp /bin/sh ../../../binutils/bfd/doc/../../move-if-change aoutx.tmp aoutx.texi make chew make[4]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' make[4]: "chew" is the newest. make[4]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' ./chew -f ../../../binutils/bfd/doc/doc.str <../../../binutils/bfd/doc/../archive.c >archive.tmp /bin/sh ../../../binutils/bfd/doc/../../move-if-change archive.tmp archive.texi make chew make[4]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' make[4]: "chew" is the newest. make[4]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' ./chew -f ../../../binutils/bfd/doc/doc.str < ../../../binutils/bfd/doc/../archures.c >archures.tmp /bin/sh ../../../binutils/bfd/doc/../../move-if-change archures.tmp archures.texi make chew make[4]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' make[4]: "chew" is the newest. make[4]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' ./chew -f ../../../binutils/bfd/doc/doc.str < ../../../binutils/bfd/doc/../bfd.c >bfd.tmp /bin/sh ../../../binutils/bfd/doc/../../move-if-change bfd.tmp bfdt.texi make chew make[4]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' make[4]: "chew" is the newest. make[4]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' ./chew -f ../../../binutils/bfd/doc/doc.str < ../../../binutils/bfd/doc/../cache.c >cache.tmp /bin/sh ../../../binutils/bfd/doc/../../move-if-change cache.tmp cache.texi make chew make[4]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' make[4]: "chew" is the newest. make[4]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' ./chew -f ../../../binutils/bfd/doc/doc.str <../../../binutils/bfd/doc/../coffcode.h >coffcode.tmp /bin/sh ../../../binutils/bfd/doc/../../move-if-change coffcode.tmp coffcode.texi make chew make[4]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' make[4]: "chew" is the newest. make[4]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' ./chew -f ../../../binutils/bfd/doc/doc.str <../../../binutils/bfd/doc/../corefile.c >core.tmp /bin/sh ../../../binutils/bfd/doc/../../move-if-change core.tmp core.texi make chew make[4]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' make[4]: "chew" is the newest. make[4]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' ./chew -f ../../../binutils/bfd/doc/doc.str <../../../binutils/bfd/doc/../elf.c >elf.tmp /bin/sh ../../../binutils/bfd/doc/../../move-if-change elf.tmp elf.texi make chew make[4]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' make[4]: "chew" is the newest. make[4]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' ./chew -f ../../../binutils/bfd/doc/doc.str <../../../binutils/bfd/doc/../elfcode.h >elfcode.tmp /bin/sh ../../../binutils/bfd/doc/../../move-if-change elfcode.tmp elfcode.texi make chew make[4]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' make[4]: "chew" is the newest. make[4]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' ./chew -f ../../../binutils/bfd/doc/doc.str <../../../binutils/bfd/doc/../format.c >format.tmp /bin/sh ../../../binutils/bfd/doc/../../move-if-change format.tmp format.texi make chew make[4]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' make[4]: "chew" is the newest. make[4]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' ./chew -f ../../../binutils/bfd/doc/doc.str < ../../../binutils/bfd/doc/../libbfd.c >libbfd.tmp /bin/sh ../../../binutils/bfd/doc/../../move-if-change libbfd.tmp libbfd.texi make chew make[4]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' make[4]: "chew" is the newest. make[4]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' ./chew -f ../../../binutils/bfd/doc/doc.str < ../../../binutils/bfd/doc/../bfdwin.c >bfdwin.tmp /bin/sh ../../../binutils/bfd/doc/../../move-if-change bfdwin.tmp bfdwin.texi make chew make[4]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' make[4]: "chew" is the newest. make[4]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' ./chew -f ../../../binutils/bfd/doc/doc.str < ../../../binutils/bfd/doc/../bfdio.c >bfdio.tmp /bin/sh ../../../binutils/bfd/doc/../../move-if-change bfdio.tmp bfdio.texi make chew make[4]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' make[4]: "chew" is the newest. make[4]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' ./chew -f ../../../binutils/bfd/doc/doc.str <../../../binutils/bfd/doc/../opncls.c >opncls.tmp /bin/sh ../../../binutils/bfd/doc/../../move-if-change opncls.tmp opncls.texi make chew make[4]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' make[4]: "chew" is the newest. make[4]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' ./chew -f ../../../binutils/bfd/doc/doc.str <../../../binutils/bfd/doc/../reloc.c >reloc.tmp /bin/sh ../../../binutils/bfd/doc/../../move-if-change reloc.tmp reloc.texi make chew make[4]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' make[4]: "chew" is the newest. make[4]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' ./chew -f ../../../binutils/bfd/doc/doc.str <../../../binutils/bfd/doc/../section.c >section.tmp /bin/sh ../../../binutils/bfd/doc/../../move-if-change section.tmp section.texi make chew make[4]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' make[4]: "chew" is the newest. make[4]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' ./chew -f ../../../binutils/bfd/doc/doc.str <../../../binutils/bfd/doc/../syms.c >syms.tmp /bin/sh ../../../binutils/bfd/doc/../../move-if-change syms.tmp syms.texi make chew make[4]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' make[4]: "chew" is the newest. make[4]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' ./chew -f ../../../binutils/bfd/doc/doc.str <../../../binutils/bfd/doc/../targets.c >targets.tmp /bin/sh ../../../binutils/bfd/doc/../../move-if-change targets.tmp targets.texi make chew make[4]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' make[4]: "chew" is the newest. make[4]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' ./chew -f ../../../binutils/bfd/doc/doc.str <../../../binutils/bfd/doc/../init.c >init.tmp /bin/sh ../../../binutils/bfd/doc/../../move-if-change init.tmp init.texi make chew make[4]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' make[4]: "chew" is the newest. make[4]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' ./chew -f ../../../binutils/bfd/doc/doc.str <../../../binutils/bfd/doc/../hash.c >hash.tmp /bin/sh ../../../binutils/bfd/doc/../../move-if-change hash.tmp hash.texi make chew make[4]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' make[4]: "chew" is the newest. make[4]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' ./chew -f ../../../binutils/bfd/doc/doc.str <../../../binutils/bfd/doc/../linker.c >linker.tmp /bin/sh ../../../binutils/bfd/doc/../../move-if-change linker.tmp linker.texi make chew make[4]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' make[4]: "chew" is the newest. make[4]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' ./chew -f ../../../binutils/bfd/doc/doc.str <../../../binutils/bfd/doc/../mmo.c >mmo.tmp /bin/sh ../../../binutils/bfd/doc/../../move-if-change mmo.tmp mmo.texi creating bfdver.texi restore=: && backupdir=".am$$" && \ rm -rf $backupdir && mkdir $backupdir && \ if (/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils/missing makeinfo --split-size=5000000 --split-size=5000000 --version) >/dev/null 2>&1; then \ for f in bfd.info bfd.info-[0-9] bfd.info-[0-9][0-9] bfd.i[0-9] bfd.i[0-9][0-9]; do \ if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \ done; \ else :; fi && \ if /home/enjoyo/RosBE-Unix-0.3.6/sources/binutils/missing makeinfo --split-size=5000000 --split-size=5000000 -I ../../../binutils/bfd/doc \ -o bfd.info `test -f 'bfd.texinfo' || echo '../../../binutils/bfd/doc/'`bfd.texinfo; \ then \ rc=0; \ else \ rc=$?; \ $restore $backupdir/* `echo "./bfd.info" | sed 's|[^/]*$||'`; \ fi; \ rm -rf $backupdir; exit $rc WARNING: `makeinfo' is missing on your system. You should only need it if you modified a `.texi' or `.texinfo' file, or any other file indirectly affecting the aspect of the manual. The spurious call might also be the consequence of using a buggy `make' (AIX, DU, IRIX). You might want to install the `Texinfo' package or the `GNU make' package. Grab either from any GNU archive site. make[3]: *** [bfd.info] ERROR 1 make[3]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/doc' Making info in po make[3]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/po' ( if test 'x../../../binutils/bfd/po' != 'x.'; then \ posrcprefix='../../../binutils/bfd/'; \ else \ posrcprefix="../"; \ fi; \ rm -f SRC-POTFILES-t SRC-POTFILES \ && (sed -e '/^#/d' \ -e '/^[ ]*$/d' \ -e "s@.*@ $posrcprefix& \\\\@" < ../../../binutils/bfd/po/SRC-POTFILES.in \ | sed -e '$s/\\$//') > SRC-POTFILES-t \ && chmod a-w SRC-POTFILES-t \ && mv SRC-POTFILES-t SRC-POTFILES ) ( rm -f BLD-POTFILES-t BLD-POTFILES \ && (sed -e '/^#/d' \ -e '/^[ ]*$/d' \ -e "s@.*@ ../& \\\\@" < ../../../binutils/bfd/po/BLD-POTFILES.in \ | sed -e '$s/\\$//') > BLD-POTFILES-t \ && chmod a-w BLD-POTFILES-t \ && mv BLD-POTFILES-t BLD-POTFILES ) cd .. \ && CONFIG_FILES=po/Makefile.in:po/Make-in \ CONFIG_HEADERS= /bin/sh ./config.status config.status: creating po/Makefile.in config.status: executing depfiles commands config.status: executing default-1 commands config.status: executing default commands make[3]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/po' make[3]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/po' make[3]: Nothing to be done for `info'. make[3]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd/po' make[3]: Entering directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd' make[3]: Nothing to be done for `info-am'. make[3]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd' make[2]: *** [info-recursive] ERROR 1 make[2]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build/bfd' make[1]: *** [all-bfd] ERROR 2 make[1]: Leaving directory `/home/enjoyo/RosBE-Unix-0.3.6/sources/binutils-build' make: *** [all] ERROR 2

2 2

[ros-diffs] [jimtabor] 31174: A partial implementation of NtGdiCreate/DeleteClientObj.
by Timo Kreuzer 13 Dec '07

13 Dec '07

You probably meant GDI_OBJECT_TYPE_CLIOBJ > Author: jimtabor > Date: Wed Dec 12 05:29:21 2007 > New Revision: 31174 > > > + HANDLE handle = GDIOBJ_AllocObj(GdiHandleTable, GDI_OBJECT_TAG_CLIOBJ); > + return GDIOBJ_FreeObj(GdiHandleTable, h, GDI_OBJECT_TAG_CLIOBJ); >

2 1

Re: [ros-dev] [ros-diffs] [hpoussin] 31182: Remove useless test
by Steven Edwards 12 Dec '07

12 Dec '07

On Dec 12, 2007 7:08 AM, <hpoussin(a)svn.reactos.org> wrote: > Author: hpoussin > Date: Wed Dec 12 15:08:11 2007 > New Revision: 31182 > - * Copyright (C) 2002, 2003, 2004 ReactOS Team > + * Copyright (C) ReactOS Team A proper copyright header needs to show all of the years like * Copyright (C) 2002-2004,2007 ReactOS Team Thanks -- 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

1 0

Re: [ros-dev] [ros-diffs] [dchapyshev] 31048: - Move all hardcode strings to resource
by Ged Murphy 06 Dec '07

06 Dec '07

dchapyshev(a)svn.reactos.org wrote: > Author: dchapyshev > Date: Thu Dec 6 22:49:12 2007 > New Revision: 31048 > URL: http://svn.reactos.org/svn/reactos?rev=31048&view=rev > Log: > - Move all hardcode strings to resource This isn't actually used. It should be deleted. Ged.

1 0

Re: [ros-dev] [ros-diffs] [fireball] 31043: - Fix Greatlordisms: * Don't try to link *user*mode program to static *kernelmode* libcntpr. msvcrt.dll exists for this. * Fix main()'s declaration and definition. * The above changes fix compiling of rostest module.
by Alex Ionescu 06 Dec '07

06 Dec '07

Something is wrong with your development process if you believe libcntpr is a "kernel-mode" library. I always compile my native programs with it on Windows -- in fact so should ntdll in ReactOS. If it doesn't you may want to check your brains before bashing Greatlord... including msvcrt in a native program is a sure recipe for disaster... -- Best regards, Alex Ionescu On 6-Dec-07, at 10:44 AM, fireball(a)svn.reactos.org wrote: > Author: fireball > Date: Thu Dec 6 18:44:23 2007 > New Revision: 31043 > > URL: http://svn.reactos.org/svn/reactos?rev=31043&view=rev > Log: > - Fix Greatlordisms: > * Don't try to link *user*mode program to static *kernelmode* > libcntpr. msvcrt.dll exists for this. > * Fix main()'s declaration and definition. > * The above changes fix compiling of rostest module. > > Modified: > trunk/rostests/tests/D3DParseUnknownCommand_show/ > D3DParseUnknownCommand_show.rbuild > trunk/rostests/tests/D3DParseUnknownCommand_show/main.c > > Modified: trunk/rostests/tests/D3DParseUnknownCommand_show/ > D3DParseUnknownCommand_show.rbuild > URL: http://svn.reactos.org/svn/reactos/trunk/rostests/tests/ > D3DParseUnknownCommand_show/D3DParseUnknownCommand_show.rbuild? > rev=31043&r1=31042&r2=31043&view=diff > ====================================================================== > ======== > --- trunk/rostests/tests/D3DParseUnknownCommand_show/ > D3DParseUnknownCommand_show.rbuild (original) > +++ trunk/rostests/tests/D3DParseUnknownCommand_show/ > D3DParseUnknownCommand_show.rbuild Thu Dec 6 18:44:23 2007 > @@ -5,7 +5,6 @@ > <library>kernel32</library> > <library>gdi32</library> > <library>ddraw</library> > - <library>libcntpr</library> > <library>user32</library> > <file>main.c</file> > </module> > > Modified: trunk/rostests/tests/D3DParseUnknownCommand_show/main.c > URL: http://svn.reactos.org/svn/reactos/trunk/rostests/tests/ > D3DParseUnknownCommand_show/main.c? > rev=31043&r1=31042&r2=31043&view=diff > ====================================================================== > ======== > --- trunk/rostests/tests/D3DParseUnknownCommand_show/main.c (original) > +++ trunk/rostests/tests/D3DParseUnknownCommand_show/main.c Thu > Dec 6 18:44:23 2007 > @@ -22,10 +22,10 @@ > * > */ > > -INT main(INT argc, CHAR argv[]); > +INT main(INT argc, TCHAR *argv[]); > VOID BuildReturnCode(DWORD * ReturnCode); > > -INT main(INT argc, TCHAR argv[]) > +INT main(INT argc, TCHAR *argv[]) > { > DWORD ReturnCode[256]; > > @@ -44,6 +44,6 @@ > { > dp2command.bCommand = t; > ReturnCode[t] = D3DParseUnknownCommand ( (LPVOID) > &dp2command, (LPVOID *) lplpvReturnedCommand) ; > - printf("D3DParseUnknownCommand return code = %x command %d > \n", ReturnCode[t], t); > + printf("D3DParseUnknownCommand return code = %x command %d > \n", (UINT)ReturnCode[t], t); > } > } > >

1 0

Re: [ros-dev] [ros-diffs] [fireball] 31019: - Fix a bug.
by Ged Murphy 05 Dec '07

05 Dec '07

fireball(a)svn.reactos.org wrote: > Author: fireball > Date: Wed Dec 5 22:07:23 2007 > New Revision: 31019 > > URL: http://svn.reactos.org/svn/reactos?rev=31019&view=rev > Log: > - Fix a bug. janderwald??

1 0

Re: [ros-dev] Autogenerating compiler specific .def files
by Aleksey Bragin 03 Dec '07

03 Dec '07

Marc, I think I haven't been very clear on this. What I mean, is that the .spec format already includes *everything* needed to produce either gcc or msvc-format .def file. So no point in creating yet another format. Nothing more nothing less, that's what I ment. I'm glad to hear disadvantages of that way. WBR, Aleksey Bragin. On Nov 24, 2007, at 7:01 PM, Marc Piulachs wrote: > >> There is absolutely no need to invent yet another format for storing >> export functions. It was invented once by MSVC, it was invented by >> GCC/MinGW, both are incompatible, it was invented by Wine to have >> ability of easy functions stubbing. Should there be another invention >> of the same wheel by ReactOS now? > >> If GCC/MinGW wouldn't be that *strange*, it could stdcall-fixup, and >> then properly link, this way .def could be created in the lowest >> common denominator format. > > That's the problem I'm trying to solve..:) The point on this change > is not > really store them in xml inset of plain text, is not that > important, for me > there are two reasons, first declare this information so rbuild can > manipulate it as objects and apply checking , logic , whatever ... > and the > most important store the information on a neutral , compiler > agnostic and > rich format that allow us to generate (export to) ANY format we > desire out > of it. Currently def files are tided to mingw which is bad. > > At the end the information must be there so what's the difference > between > having it in a file with extension .def or .spec and having it on a > file > with .rbuild extension? IMO It's not reinventing the wheel > > /Marc

6 5

Build is broken as of Eric's change in r30958
by Colin Finck 02 Dec '07

02 Dec '07

Hello, As I don't know how to contact Eric, I post this on the mailing list now: With the change in r30958, the build is broken (at least for the BuildBot, see http://reactos.org:8010/ReactOS_%28Debug%29/builds/5979/step-shell_2/0). LD misses the "NetUserSetInfo" function. I looked into dll/win32/netapi32/netapi32.spec and it's declared there, but only as a stub. Don't know how to properly fix this now. Maybe it requires a real implementation of this function. Regards, Colin

2 2

Re: [ros-dev] [ros-diffs] [tkreuzer] 30929: patch by jimtabor: add GdiBCSelObj to GdiFlushUserBatch
by Aleksey Bragin 01 Dec '07

01 Dec '07

> + if(!dc) break; This additional check is not needed, because dc is checked at the beginning of the function now. WBR, Aleksey Bragin. On Dec 1, 2007, at 5:09 AM, tkreuzer(a)svn.reactos.org wrote: > Author: tkreuzer > Date: Sat Dec 1 05:09:39 2007 > New Revision: 30929 > > URL: http://svn.reactos.org/svn/reactos?rev=30929&view=rev > Log: > patch by jimtabor: add GdiBCSelObj to GdiFlushUserBatch > > Modified: > trunk/reactos/subsystems/win32/win32k/objects/gdibatch.c > > Modified: trunk/reactos/subsystems/win32/win32k/objects/gdibatch.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/ > win32/win32k/objects/gdibatch.c?rev=30929&r1=30928&r2=30929&view=diff > ====================================================================== > ======== > --- trunk/reactos/subsystems/win32/win32k/objects/gdibatch.c > (original) > +++ trunk/reactos/subsystems/win32/win32k/objects/gdibatch.c Sat > Dec 1 05:09:39 2007 > @@ -49,7 +49,13 @@ > case GdiBCExtSelClipRgn: > break; > case GdiBCSelObj: > - break; > + { > + PGDIBSOBJECT pgO; > + if(!dc) break; > + pgO = (PGDIBSOBJECT) pHdr; > + if(NT_SUCCESS(TextIntRealizeFont((HFONT) pgO->hgdiobj))) > + Dc_Attr->hlfntNew = (HFONT) pgO->hgdiobj; > + } > case GdiBCDelObj: > case GdiBCDelRgn: > { > @@ -115,3 +121,4 @@ > return STATUS_SUCCESS; > } > > + > >

2 1

ros-diffs] [cwittich] 30916: revert r28932
by James Tabor 30 Nov '07

30 Nov '07

Hi! That is why I hate CONTAINING_RECORD! It is so cheesy! Thanks Christoph, James

1 0

Re: [ros-dev] [ros-diffs] [cwittich] 30899: remove the const from the DrawShadowText function to be compatible to PSDK
by Steven Edwards 30 Nov '07

30 Nov '07

On Nov 29, 2007 11:04 AM, <cwittich(a)svn.reactos.org> wrote: > Author: cwittich > Date: Thu Nov 29 19:04:38 2007 > New Revision: 30899 > > URL: http://svn.reactos.org/svn/reactos?rev=30899&view=rev > Log: > remove the const from the DrawShadowText function to be compatible to PSDK Please send this on to winehq. Thanks -- 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

3 2

Re: [ros-dev] [ros-diffs] [cwittich] 30829: translated some DPRINTs from GreatLordish into a human readable format
by Ged Murphy 28 Nov '07

28 Nov '07

Cwittich wrote: > - DPRINT1("Warring no dxg.sys in ReactOS"); > + DPRINT1("Warning: dxg.sys not found\n"); The 'warring' returns, lmao, brilliant :)

1 0

Re: [ros-dev] [ros-diffs] [jimtabor] 30807: Revert 30780 for gdibatch. Size, space and time are very critical in here. If you dont know what your are doing? Do not play in here.
by Aleksey Bragin 27 Nov '07

27 Nov '07

How come size, space and time matter in this particular case of where the variable is declared (it's still defined in the stack, wherever you write it)? In the kernel, there is a rule to allocate all variables at top of the function (not in subsequent {} blocks). It should be extended to win32k too, it's cleaner, gives the developer an overview of all vars used in the function, and prevents possible cases of defining vars with the same name both atop of the function and in some subsequent block of code. Not to mention this is not fully correct to do in a C language. With the best regards, Aleksey Bragin. On Nov 27, 2007, at 4:14 AM, jimtabor(a)svn.reactos.org wrote: > Author: jimtabor > Date: Tue Nov 27 04:14:38 2007 > New Revision: 30807 > > URL: http://svn.reactos.org/svn/reactos?rev=30807&view=rev > Log: > Revert 30780 for gdibatch. Size, space and time are very critical > in here. If you dont know what your are doing? Do not play in here. > > Modified: > trunk/reactos/subsystems/win32/win32k/objects/gdibatch.c > > Modified: trunk/reactos/subsystems/win32/win32k/objects/gdibatch.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/ > win32/win32k/objects/gdibatch.c?rev=30807&r1=30806&r2=30807&view=diff > ====================================================================== > ======== > --- trunk/reactos/subsystems/win32/win32k/objects/gdibatch.c > (original) > +++ trunk/reactos/subsystems/win32/win32k/objects/gdibatch.c Tue > Nov 27 04:14:38 2007 > @@ -20,7 +20,6 @@ > { > PDC dc = NULL; > PDC_ATTR Dc_Attr = NULL; > - PGDIBSSETBRHORG pgSBO; > if (hDC) > { > dc = DC_LockDc(hDC); > @@ -40,6 +39,7 @@ > break; > case GdiBCSetBrushOrg: > { > + PGDIBSSETBRHORG pgSBO; > if (!dc) break; > pgSBO = (PGDIBSSETBRHORG) pHdr; > Dc_Attr->ptlBrushOrigin = pgSBO->ptlBrushOrigin; > >

2 1

Paste service
by Sylvain Petreolle 27 Nov '07

27 Nov '07

Looking at bug #933 in bugzilla, I see the following paste : http://www.reactos.org/paste/index.php/37693cf/ It has been posted on november 14th and set to expire after 7 days. Today is november 27, therefore this paste should have expired. 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. - Voltaire Run your favorite Windows apps with free ReactOS : http://www.reactos.org Listen to non-DRMised Music: http://www.jamendo.com

2 1

Re: [ros-dev] Autogenerating compiler specific .def files
by Aleksey Bragin 24 Nov '07

24 Nov '07

Theoretically extending this logic to infinity will lead to creation of a new high level language, stored in xml documents, parsing which rbuild generates source code in C or other language needed. :-). The thing is, .def is rather simple, .spec is a bit more advanced to include more stuff ("stub", what else does reactos use from it?). There is absolutely no need to invent yet another format for storing export functions. It was invented once by MSVC, it was invented by GCC/MinGW, both are incompatible, it was invented by Wine to have ability of easy functions stubbing. Should there be another invention of the same wheel by ReactOS now? If GCC/MinGW wouldn't be that *strange*, it could stdcall-fixup, and then properly link, this way .def could be created in the lowest common denominator format. With the best regards, Aleksey Bragin. On Nov 24, 2007, at 4:36 PM, Marc Piulachs wrote: > I wouldn't use .spec files for several reasons, first of all is > that it > violates the way how rbuild currently works. Rbuild reads xml > documents in a > custom format and produce different outputs depending on various > conditions. > IMO rbuild shouldn't be extended to parse anything else but > just .rbuild > files. > > Also, winebuild from the rbuild point of view is not different from > any > other compiler , so I think the problem is just the opposite , > rbuild should > use the information stored in it's rbuild file to produce the spec > file in > addition to the specific def file (it shouldn't be produced by > winebuild > anymore) as both files are required to compile wine module XYZ. > > Having the information in rbuild files has also other advantages, > the most > important is that it would allow us to use the conditional logic to > export > functions based on a given condition, for example hacks like > /lib/debugsup.rbuild won't be necessary anymore. > > I wouldn't fork winebuild. > > Regards, > Marc

4 8

Autogenerating compiler specific .def files
by Marc Piulachs 24 Nov '07

24 Nov '07

Hi All, I have lately seen a big effort to make more modules compilable under Visual C , one of our current problems when building dlls is that our .def files are mingw/gcc specific not directly compatible with msvc or any other future compiler we may support. Currently we are using not very elegant solutions to archive compatibility with msvc like stripping some information from mingw def files. As Alex suggested I think it's a good idea to move that information to rbuild files and let rbuild generate full compatible compiler def files in the intermediate folder. The advantages are obvious. As I have little experience with mingw def files I would like to request some help from other developers to evaluate/validate my proposal. >From my research on the ros codebase I have found that possible variations: - CcRosInitializeFileCache@8 - FsRtlGetFileSize - @HalExamineMBR@16 - PsChargeProcessNonPagedPoolQuota@4=PsDereferenceImpersonationToken@4 - ConvertSecurityDescriptorToAccessNamedA=ConvertSecurityDescriptorToAccessA@2 8 - GetSecurityDescriptorLength(a)4=NTDLL.RtlLengthSecurityDescriptor - ??1type_info@@UAE@XZ=__thiscall_MSVCRT_type_info_dtor @15 - ChkdskEx=VfatChkdsk@24 My proposed syntax is as following and it should support all of the above cases: <exportfunction name="CcRosInitializeFileCache" ordinal="8" /> (required) (optional) <exportfunction name="CcRosInitializeFileCache" ordinal="8" mappedname="PsDereferenceImpersonationToken" mappedordinal="4"/> (required) (optional) (optional) (optional) <exportfunction name="GetSecurityDescriptorLength" ordinal="4" mappedname="RtlLengthSecurityDescriptor" mappedordinal="4" module="ntdll"/> (required) (optional) (optional) (optional) (optional) With this information rbuild will generate a modulename_gcc.def when you type "make" and modulename_msvc.def on the intermediate folder when you type "make msvc". Opinions, comments? Regards, Marc

3 3

Re: [ros-dev] Autogenerating compiler specific .def files
by Aleksey Bragin 24 Nov '07

24 Nov '07

Hi, why can't .spec be used for this purpose (extended to support msvc files generation)? They are going to stay anyway for wine-shared modules. With the best regards, Aleksey Bragin. On Nov 24, 2007, at 3:04 AM, Marc Piulachs wrote: > Hi All, > > > > I have lately seen a big effort to make more modules compilable > under Visual C , one of our current problems when building dlls is > that our .def files are mingw/gcc specific not directly compatible > with msvc or any other future compiler we may support. Currently we > are using not very elegant solutions to archive compatibility with > msvc like stripping some information from mingw def files. As Alex > suggested I think it’s a good idea to move that information to > rbuild files and let rbuild generate full compatible compiler def > files in the intermediate folder. The advantages are obvious. > > > > As I have little experience with mingw def files I would like to > request some help from other developers to evaluate/validate my > proposal. > > > > From my research on the ros codebase I have found that possible > variations:

3 2

Re: [ros-dev] [ros-diffs] [cwittich] 30460: sync CryptAcquireContext to wine (this fixes some Unicode issues)
by Alex Ionescu 23 Nov '07

23 Nov '07

"HCRYPTHASH hPrivate; /*CSP's handle - Should not be given to application under any circumstances!*/" Are Wine people aware that DLLs load in the same address space as applications? There is no way to protect this handle from the application unless you store it in kernel-mode. On Nov 15, 2007 9:08 AM, <cwittich(a)svn.reactos.org> wrote: > Author: cwittich > Date: Thu Nov 15 17:08:18 2007 > New Revision: 30460 > > URL: http://svn.reactos.org/svn/reactos?rev=30460&view=rev > Log: > sync CryptAcquireContext to wine (this fixes some Unicode issues) > > Modified: > trunk/reactos/dll/win32/advapi32/crypt/crypt.c > trunk/reactos/dll/win32/advapi32/crypt/crypt.h > > Modified: trunk/reactos/dll/win32/advapi32/crypt/crypt.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/advapi32/crypt/c… > > ============================================================================== > --- trunk/reactos/dll/win32/advapi32/crypt/crypt.c (original) > +++ trunk/reactos/dll/win32/advapi32/crypt/crypt.c Thu Nov 15 17:08:18 > 2007 > @@ -55,45 +55,56 @@ > #define CRYPT_Alloc(size) ((LPVOID)LocalAlloc(LMEM_ZEROINIT, size)) > #define CRYPT_Free(buffer) (LocalFree((HLOCAL)buffer)) > > -static inline PSTR CRYPT_GetProvKeyName(PCSTR pProvName) > -{ > - PCSTR KEYSTR = > "Software\\Microsoft\\Cryptography\\Defaults\\Provider\\"; > - PSTR keyname; > - > - keyname = CRYPT_Alloc(strlen(KEYSTR) + strlen(pProvName) +1); > +static inline PWSTR CRYPT_GetProvKeyName(PCWSTR pProvName) > +{ > + static const WCHAR KEYSTR[] = { > + 'S','o','f','t','w','a','r','e','\\', > + 'M','i','c','r','o','s','o','f','t','\\', > + 'C','r','y','p','t','o','g','r','a','p','h','y','\\', > + 'D','e','f','a','u','l','t','s','\\', > + 'P','r','o','v','i','d','e','r','\\',0 > + }; > + PWSTR keyname; > + > + keyname = CRYPT_Alloc((wcslen(KEYSTR) + wcslen(pProvName) > +1)*sizeof(WCHAR)); > if (keyname) > { > - strcpy(keyname, KEYSTR); > - strcpy(keyname + strlen(KEYSTR), pProvName); > - } > - else > - { > + wcscpy(keyname, KEYSTR); > + wcscpy(keyname + wcslen(KEYSTR), pProvName); > + } else > SetLastError(ERROR_NOT_ENOUGH_MEMORY); > - } > - > return keyname; > } > > -static inline PSTR CRYPT_GetTypeKeyName(DWORD dwType, BOOL user) > -{ > - PCSTR MACHINESTR = > "Software\\Microsoft\\Cryptography\\Defaults\\Provider Types\\Type XXX"; > - PCSTR USERSTR = "Software\\Microsoft\\Cryptography\\Provider Type > XXX"; > - PSTR keyname; > - PSTR ptr; > - > - keyname = CRYPT_Alloc( (user ? strlen(USERSTR) : > strlen(MACHINESTR)) +1); > +static inline PWSTR CRYPT_GetTypeKeyName(DWORD dwType, BOOL user) > +{ > + static const WCHAR MACHINESTR[] = { > + 'S','o','f','t','w','a','r','e','\\', > + 'M','i','c','r','o','s','o','f','t','\\', > + 'C','r','y','p','t','o','g','r','a','p','h','y','\\', > + 'D','e','f','a','u','l','t','s','\\', > + 'P','r','o','v','i','d','e','r',' > ','T','y','p','e','s','\\', > + 'T','y','p','e',' ','X','X','X',0 > + }; > + static const WCHAR USERSTR[] = { > + 'S','o','f','t','w','a','r','e','\\', > + 'M','i','c','r','o','s','o','f','t','\\', > + 'C','r','y','p','t','o','g','r','a','p','h','y','\\', > + 'P','r','o','v','i','d','e','r',' ','T','y','p','e',' > ','X','X','X',0 > + }; > + PWSTR keyname; > + PWSTR ptr; > + > + keyname = CRYPT_Alloc( ((user ? wcslen(USERSTR) : > wcslen(MACHINESTR)) +1)*sizeof(WCHAR)); > if (keyname) > { > - user ? strcpy(keyname, USERSTR) : strcpy(keyname, > MACHINESTR); > - ptr = keyname + strlen(keyname); > + user ? wcscpy(keyname, USERSTR) : wcscpy(keyname, > MACHINESTR); > + ptr = keyname + wcslen(keyname); > *(--ptr) = (dwType % 10) + '0'; > *(--ptr) = ((dwType / 10) % 10) + '0'; > *(--ptr) = (dwType / 100) + '0'; > - } > - else > - { > + } else > SetLastError(ERROR_NOT_ENOUGH_MEMORY); > - } > return keyname; > } > > @@ -178,26 +189,23 @@ > > #define CRYPT_GetProvFunc(name) \ > if ( !(provider->pFuncs->p##name = > (void*)GetProcAddress(provider->hModule, #name)) ) goto error > - > #define CRYPT_GetProvFuncOpt(name) \ > provider->pFuncs->p##name = > (void*)GetProcAddress(provider->hModule, #name) > -PCRYPTPROV CRYPT_LoadProvider(PSTR pImage) > +static PCRYPTPROV CRYPT_LoadProvider(PCWSTR pImage) > { > PCRYPTPROV provider; > DWORD errorcode = ERROR_NOT_ENOUGH_MEMORY; > > - if (!(provider = CRYPT_Alloc(sizeof(CRYPTPROV)))) > + if ( !(provider = CRYPT_Alloc(sizeof(CRYPTPROV))) ) goto error; > + if ( !(provider->pFuncs = CRYPT_Alloc(sizeof(PROVFUNCS))) ) goto > error; > + if ( !(provider->pVTable = CRYPT_Alloc(sizeof(VTableProvStruc))) ) > goto error; > + if ( !(provider->hModule = LoadLibraryW(pImage)) ) > + { > + errorcode = (GetLastError() == ERROR_FILE_NOT_FOUND) ? > NTE_PROV_DLL_NOT_FOUND : NTE_PROVIDER_DLL_FAIL; > + DPRINT("Failed to load dll %S\n", pImage); > goto error; > - if (!(provider->pFuncs = CRYPT_Alloc(sizeof(PROVFUNCS)))) > - goto error; > - if (!(provider->pVTable = CRYPT_Alloc(sizeof(VTableProvStruc)))) > - goto error; > - if (!(provider->hModule = LoadLibraryA(pImage))) > - { > - errorcode = (GetLastError() == ERROR_FILE_NOT_FOUND) ? > NTE_PROV_DLL_NOT_FOUND : NTE_PROVIDER_DLL_FAIL; > - DPRINT1("Failed to load dll %s\n", pImage); > - goto error; > - } > + } > + provider->dwMagic = MAGIC_CRYPTPROV; > provider->refcount = 1; > > errorcode = NTE_PROVIDER_DLL_FAIL; > @@ -243,6 +251,7 @@ > SetLastError(errorcode); > if (provider) > { > + provider->dwMagic = 0; > if (provider->hModule) > FreeLibrary(provider->hModule); > CRYPT_Free(provider->pVTable); > @@ -256,30 +265,35 @@ > > > > /****************************************************************************** > - * CryptAcquireContextA (ADVAPI32.@) > + * CryptAcquireContextW (ADVAPI32.@) > + * > * Acquire a crypto provider context handle. > * > * PARAMS > - * phProv: Pointer to HCRYPTPROV for the output. > - * pszContainer: Key Container Name > - * pszProvider: Cryptographic Service Provider Name > - * dwProvType: Crypto provider type to get a handle. > - * dwFlags: flags for the operation > - * > - * RETURNS TRUE on success, FALSE on failure. > - */ > -BOOL WINAPI CryptAcquireContextA (HCRYPTPROV *phProv, LPCSTR > pszContainer, > - LPCSTR pszProvider, DWORD dwProvType, DWORD dwFlags) > + * phProv [O] Pointer to HCRYPTPROV for the output. > + * pszContainer [I] Key Container Name > + * pszProvider [I] Cryptographic Service Provider Name > + * dwProvType [I] Crypto provider type to get a handle. > + * dwFlags [I] flags for the operation > + * > + * RETURNS > + * TRUE on success, FALSE on failure. > + */ > +BOOL WINAPI CryptAcquireContextW (HCRYPTPROV *phProv, LPCWSTR > pszContainer, > + LPCWSTR pszProvider, DWORD dwProvType, DWORD dwFlags) > { > PCRYPTPROV pProv = NULL; > HKEY key; > - PSTR imagepath = NULL, keyname = NULL, provname = NULL, temp = > NULL; > - BYTE* signature; > + PWSTR imagepath = NULL, keyname = NULL, provname = NULL, temp = > NULL; > + PSTR provnameA = NULL, pszContainerA = NULL; > DWORD keytype, type, len; > ULONG r; > - > - DPRINT("(%p, %s, %s, %ld, %08lx)\n", phProv, pszContainer, > - pszProvider, dwProvType, dwFlags); > + static const WCHAR nameW[] = {'N','a','m','e',0}; > + static const WCHAR typeW[] = {'T','y','p','e',0}; > + static const WCHAR imagepathW[] = {'I','m','a','g','e',' > ','P','a','t','h',0}; > + > + DPRINT("(%p, %S, %S, %d, %08x)\n", phProv, pszContainer, > + pszProvider, dwProvType, dwFlags); > > if (dwProvType < 1 || dwProvType > MAXPROVTYPES) > { > @@ -298,26 +312,21 @@ > /* No CSP name specified so try the user default CSP first > * then try the machine default CSP > */ > - if (!(keyname = CRYPT_GetTypeKeyName(dwProvType, TRUE))) > - { > - DPRINT("No provider registered for crypto provider > type %ld.\n", dwProvType); > + if ( !(keyname = CRYPT_GetTypeKeyName(dwProvType, TRUE)) ) > { > + DPRINT("No provider registered for crypto provider > type %d.\n", dwProvType); > SetLastError(NTE_PROV_TYPE_NOT_DEF); > return FALSE; > } > - > - if (RegOpenKeyA(HKEY_CURRENT_USER, keyname, &key)) > + if (RegOpenKeyW(HKEY_CURRENT_USER, keyname, &key)) > { > CRYPT_Free(keyname); > - if (!(keyname = CRYPT_GetTypeKeyName(dwProvType, > FALSE))) > - { > - DPRINT("No type registered for crypto > provider type %ld.\n", dwProvType); > + if ( !(keyname = CRYPT_GetTypeKeyName(dwProvType, > FALSE)) ) { > + DPRINT("No type registered for crypto > provider type %d.\n", dwProvType); > RegCloseKey(key); > SetLastError(NTE_PROV_TYPE_NOT_DEF); > goto error; > } > - > - if (RegOpenKeyA(HKEY_LOCAL_MACHINE, keyname, > &key)) > - { > + if (RegOpenKeyW(HKEY_LOCAL_MACHINE, keyname, > &key)) { > DPRINT("Did not find registry entry of > crypto provider for %S.\n", keyname); > CRYPT_Free(keyname); > RegCloseKey(key); > @@ -325,44 +334,41 @@ > goto error; > } > } > - > CRYPT_Free(keyname); > - r = RegQueryValueExA(key, "Name", NULL, &keytype, NULL, > &len); > - if (r != ERROR_SUCCESS || !len || keytype != REG_SZ) > + r = RegQueryValueExW(key, nameW, NULL, &keytype, NULL, > &len); > + if( r != ERROR_SUCCESS || !len || keytype != REG_SZ) > { > - DPRINT("error %ld reading size of 'Name' from > registry\n", r ); > + DPRINT("error %d reading size of 'Name' from > registry\n", r ); > RegCloseKey(key); > SetLastError(NTE_PROV_TYPE_ENTRY_BAD); > goto error; > } > - if (!(provname = CRYPT_Alloc(len))) > + if(!(provname = CRYPT_Alloc(len))) > { > RegCloseKey(key); > SetLastError(ERROR_NOT_ENOUGH_MEMORY); > goto error; > } > - r = RegQueryValueExA(key, "Name", NULL, NULL, > (LPBYTE)provname, &len); > - if (r != ERROR_SUCCESS) > + r = RegQueryValueExW(key, nameW, NULL, NULL, > (LPBYTE)provname, &len); > + if( r != ERROR_SUCCESS ) > { > - DPRINT("error %ld reading 'Name' from registry\n", > r ); > + DPRINT("error %d reading 'Name' from registry\n", > r ); > RegCloseKey(key); > SetLastError(NTE_PROV_TYPE_ENTRY_BAD); > goto error; > } > RegCloseKey(key); > - } > - else > - { > - if (!(provname = CRYPT_Alloc(strlen(pszProvider) +1))) > + } else { > + if ( !(provname = CRYPT_Alloc((wcslen(pszProvider) > +1)*sizeof(WCHAR))) ) > { > SetLastError(ERROR_NOT_ENOUGH_MEMORY); > goto error; > } > - strcpy(provname, pszProvider); > + wcscpy(provname, pszProvider); > } > > keyname = CRYPT_GetProvKeyName(provname); > - r = RegOpenKeyA(HKEY_LOCAL_MACHINE, keyname, &key); > + r = RegOpenKeyW(HKEY_LOCAL_MACHINE, keyname, &key); > CRYPT_Free(keyname); > if (r != ERROR_SUCCESS) > { > @@ -370,7 +376,7 @@ > goto error; > } > len = sizeof(DWORD); > - r = RegQueryValueExA(key, "Type", NULL, NULL, (BYTE*)&type, &len); > + r = RegQueryValueExW(key, typeW, NULL, NULL, (BYTE*)&type, &len); > if (r != ERROR_SUCCESS) > { > SetLastError(NTE_PROV_TYPE_ENTRY_BAD); > @@ -378,15 +384,15 @@ > } > if (type != dwProvType) > { > - DPRINT("Crypto provider has wrong type (%ld vs expected > %ld).\n", type, dwProvType); > + DPRINT("Crypto provider has wrong type (%d vs expected > %d).\n", type, dwProvType); > SetLastError(NTE_PROV_TYPE_NO_MATCH); > goto error; > } > > - r = RegQueryValueExA(key, "Image Path", NULL, &keytype, NULL, > &len); > + r = RegQueryValueExW(key, imagepathW, NULL, &keytype, NULL, &len); > if ( r != ERROR_SUCCESS || keytype != REG_SZ) > { > - DPRINT("error %ld reading size of 'Image Path' from > registry\n", r ); > + DPRINT("error %d reading size of 'Image Path' from > registry\n", r ); > RegCloseKey(key); > SetLastError(NTE_PROV_TYPE_ENTRY_BAD); > goto error; > @@ -397,90 +403,44 @@ > SetLastError(ERROR_NOT_ENOUGH_MEMORY); > goto error; > } > - r = RegQueryValueExA(key, "Image Path", NULL, NULL, (LPBYTE)temp, > &len); > - if (r != ERROR_SUCCESS) > - { > - DPRINT("error %ld reading 'Image Path' from registry\n", r > ); > + r = RegQueryValueExW(key, imagepathW, NULL, NULL, (LPBYTE)temp, > &len); > + if( r != ERROR_SUCCESS ) > + { > + DPRINT("error %d reading 'Image Path' from registry\n", r > ); > RegCloseKey(key); > SetLastError(NTE_PROV_TYPE_ENTRY_BAD); > goto error; > } > - > - r = RegQueryValueExA(key, "Signature", NULL, &keytype, NULL, > &len); > - if (r == ERROR_SUCCESS && keytype == REG_BINARY) > - { > - if (!(signature = CRYPT_Alloc(len))) > - { > - RegCloseKey(key); > - SetLastError(ERROR_NOT_ENOUGH_MEMORY); > - goto error; > - } > - r = RegQueryValueExA(key, "Signature", NULL, NULL, > signature, &len); > - if (r != ERROR_SUCCESS) > - { > - DPRINT("error %ld reading 'Signature'\n", r ); > - CRYPT_Free(signature); > - RegCloseKey(key); > - SetLastError(NTE_PROV_TYPE_ENTRY_BAD); > - goto error; > - } > - } > - else > - { > - r = RegQueryValueExA(key, "SigInFile", NULL, &keytype, > NULL, &len); > - if (r != ERROR_SUCCESS) > - { > - DPRINT("error %ld reading size of 'SigInFile'\n", > r ); > - RegCloseKey(key); > - SetLastError(NTE_PROV_TYPE_ENTRY_BAD); > - goto error; > - } > - else > - { > - /* FIXME: The presence of the SigInFile value > indicates the > - * provider's signature is in its resources, so > need to read it. > - * But since CRYPT_VerifyImage is stubbed, provide > any old thing > - * for now. > - */ > - if (!(signature = CRYPT_Alloc(1))) > - { > - RegCloseKey(key); > - SetLastError(ERROR_NOT_ENOUGH_MEMORY); > - goto error; > - } > - } > - } > RegCloseKey(key); > - len = ExpandEnvironmentStringsA(temp, NULL, 0); > - if (!(imagepath = CRYPT_Alloc(len))) > - { > - CRYPT_Free(signature); > + len = ExpandEnvironmentStringsW(temp, NULL, 0); > + if ( !(imagepath = CRYPT_Alloc(len*sizeof(WCHAR))) ) > + { > SetLastError(ERROR_NOT_ENOUGH_MEMORY); > goto error; > } > - if (!ExpandEnvironmentStringsA(temp, imagepath, len)) > - { > - CRYPT_Free(signature); > + if (!ExpandEnvironmentStringsW(temp, imagepath, len)) > + { > /* ExpandEnvironmentStrings will call SetLastError */ > goto error; > } > - > - if (!CRYPT_VerifyImage(imagepath, signature)) > - { > - CRYPT_Free(signature); > - SetLastError(NTE_SIGNATURE_FILE_BAD); > - goto error; > - } > pProv = CRYPT_LoadProvider(imagepath); > - CRYPT_Free(signature); > - if (!pProv) > - { > + if (!pProv) { > /* CRYPT_LoadProvider calls SetLastError */ > goto error; > } > pProv->pVTable->dwProvType = dwProvType; > - pProv->pVTable->pszProvName = provname; > - if (pProv->pFuncs->pCPAcquireContext(&pProv->hPrivate, > (CHAR*)pszContainer, dwFlags, pProv->pVTable)) > + if(!CRYPT_UnicodeToANSI(provname, &provnameA, -1)) > + { > + /* CRYPT_UnicodeToANSI calls SetLastError */ > + goto error; > + } > + pProv->pVTable->pszProvName = provnameA; > + if(!CRYPT_UnicodeToANSI(pszContainer, &pszContainerA, -1)) > + { > + /* CRYPT_UnicodeToANSI calls SetLastError */ > + goto error; > + } > + if (pProv->pFuncs->pCPAcquireContext(&pProv->hPrivate, > pszContainerA, dwFlags, pProv->pVTable)) > { > /* MSDN: When this flag is set, the value returned in > phProv is undefined, > * and thus, the CryptReleaseContext function need > not be called afterwards. > @@ -488,15 +448,17 @@ > */ > if (dwFlags & CRYPT_DELETEKEYSET) > { > + pProv->dwMagic = 0; > FreeLibrary(pProv->hModule); > - CRYPT_Free(provname); > + CRYPT_Free(provnameA); > + CRYPT_Free(pProv->pVTable); > CRYPT_Free(pProv->pFuncs); > CRYPT_Free(pProv); > - } > - else > - { > + } else { > *phProv = (HCRYPTPROV)pProv; > } > + CRYPT_Free(pszContainerA); > + CRYPT_Free(provname); > CRYPT_Free(temp); > CRYPT_Free(imagepath); > return TRUE; > @@ -505,51 +467,51 @@ > error: > if (pProv) > { > + pProv->dwMagic = 0; > if (pProv->hModule) > FreeLibrary(pProv->hModule); > - if (pProv->pVTable) > - CRYPT_Free(pProv->pVTable); > - if (pProv->pFuncs) > - CRYPT_Free(pProv->pFuncs); > + CRYPT_Free(pProv->pVTable); > + CRYPT_Free(pProv->pFuncs); > CRYPT_Free(pProv); > } > - if (provname) > - CRYPT_Free(provname); > - if (temp) > - CRYPT_Free(temp); > - if (imagepath) > - CRYPT_Free(imagepath); > + CRYPT_Free(pszContainerA); > + CRYPT_Free(provnameA); > + CRYPT_Free(provname); > + CRYPT_Free(temp); > + CRYPT_Free(imagepath); > return FALSE; > } > > > /****************************************************************************** > - * CryptAcquireContextW (ADVAPI32.@) > - * > - * see CryptAcquireContextA > - */ > -BOOL WINAPI CryptAcquireContextW (HCRYPTPROV *phProv, LPCWSTR > pszContainer, > - LPCWSTR pszProvider, DWORD dwProvType, DWORD dwFlags) > -{ > - PSTR pProvider = NULL, pContainer = NULL; > + * CryptAcquireContextA (ADVAPI32.@) > + * > + * See CryptAcquireContextW. > + */ > +BOOL WINAPI CryptAcquireContextA (HCRYPTPROV *phProv, LPCSTR > pszContainer, > + LPCSTR pszProvider, DWORD dwProvType, DWORD dwFlags) > +{ > + PWSTR pProvider = NULL, pContainer = NULL; > BOOL ret = FALSE; > > - DPRINT("(%p, %S, %S, %ld, %08lx)\n", phProv, pszContainer, > + DPRINT("(%p, %s, %s, %d, %08x)\n", phProv, pszContainer, > pszProvider, dwProvType, dwFlags); > > - if (!CRYPT_UnicodeToANSI(pszContainer, &pContainer, -1)) > - CRYPT_ReturnLastError(ERROR_NOT_ENOUGH_MEMORY); > - if (!CRYPT_UnicodeToANSI(pszProvider, &pProvider, -1)) > + if ( !CRYPT_ANSIToUnicode(pszContainer, &pContainer, -1) ) > + { > + SetLastError(ERROR_NOT_ENOUGH_MEMORY); > + return FALSE; > + } > + if ( !CRYPT_ANSIToUnicode(pszProvider, &pProvider, -1) ) > { > CRYPT_Free(pContainer); > - CRYPT_ReturnLastError(ERROR_NOT_ENOUGH_MEMORY); > - } > - > - ret = CryptAcquireContextA(phProv, pContainer, pProvider, > dwProvType, dwFlags); > - > - if (pContainer) > - CRYPT_Free(pContainer); > - if (pProvider) > - CRYPT_Free(pProvider); > + SetLastError(ERROR_NOT_ENOUGH_MEMORY); > + return FALSE; > + } > + > + ret = CryptAcquireContextW(phProv, pContainer, pProvider, > dwProvType, dwFlags); > + > + CRYPT_Free(pContainer); > + CRYPT_Free(pProvider); > > return ret; > } > @@ -1256,7 +1218,7 @@ > } > > > /****************************************************************************** > - * CryptGetDefaultProviderA (ADVAPI32.@) > + * CryptGetDefaultProviderW (ADVAPI32.@) > * > * Finds the default CSP of a certain provider type. > * > @@ -1275,29 +1237,43 @@ > * If pszProvName is NULL, pcbProvName will hold the size of the buffer > for > * memory allocation purposes on return. > */ > -BOOL WINAPI CryptGetDefaultProviderA (DWORD dwProvType, DWORD > *pdwReserved, > - DWORD dwFlags, LPSTR pszProvName, DWORD *pcbProvName) > +BOOL WINAPI CryptGetDefaultProviderW (DWORD dwProvType, DWORD > *pdwReserved, > + DWORD dwFlags, LPWSTR pszProvName, DWORD *pcbProvName) > { > HKEY hKey; > - PSTR keyname; > + PWSTR keyname; > DWORD result; > + static const WCHAR nameW[] = {'N','a','m','e',0}; > > if (pdwReserved || !pcbProvName) > - CRYPT_ReturnLastError(ERROR_INVALID_PARAMETER); > + { > + SetLastError(ERROR_INVALID_PARAMETER); > + return FALSE; > + } > if (dwFlags & ~(CRYPT_USER_DEFAULT | CRYPT_MACHINE_DEFAULT)) > - CRYPT_ReturnLastError(NTE_BAD_FLAGS); > + { > + SetLastError(NTE_BAD_FLAGS); > + return FALSE; > + } > if (dwProvType > 999) > - CRYPT_ReturnLastError(NTE_BAD_PROV_TYPE); > - if (!(keyname = CRYPT_GetTypeKeyName(dwProvType, dwFlags & > CRYPT_USER_DEFAULT))) > - CRYPT_ReturnLastError(ERROR_NOT_ENOUGH_MEMORY); > - if (RegOpenKeyA((dwFlags & CRYPT_USER_DEFAULT) ? > HKEY_CURRENT_USER : HKEY_LOCAL_MACHINE ,keyname, &hKey)) > + { > + SetLastError(NTE_BAD_PROV_TYPE); > + return FALSE; > + } > + if ( !(keyname = CRYPT_GetTypeKeyName(dwProvType, dwFlags & > CRYPT_USER_DEFAULT)) ) > + { > + SetLastError(ERROR_NOT_ENOUGH_MEMORY); > + return FALSE; > + } > + if (RegOpenKeyW((dwFlags & CRYPT_USER_DEFAULT) ? > HKEY_CURRENT_USER : HKEY_LOCAL_MACHINE ,keyname, &hKey)) > { > CRYPT_Free(keyname); > - CRYPT_ReturnLastError(NTE_PROV_TYPE_NOT_DEF); > + SetLastError(NTE_PROV_TYPE_NOT_DEF); > + return FALSE; > } > CRYPT_Free(keyname); > - > - result = RegQueryValueExA(hKey, "Name", NULL, NULL, > (LPBYTE)pszProvName, pcbProvName); > + > + result = RegQueryValueExW(hKey, nameW, NULL, NULL, > (LPBYTE)pszProvName, pcbProvName); > if (result) > { > if (result != ERROR_MORE_DATA) > @@ -1313,29 +1289,38 @@ > } > > > /****************************************************************************** > - * CryptGetDefaultProviderW (ADVAPI32.@) > - * > - * see CryptGetDefaultProviderA > - */ > -BOOL WINAPI CryptGetDefaultProviderW (DWORD dwProvType, DWORD > *pdwReserved, > - DWORD dwFlags, LPWSTR pszProvName, DWORD *pcbProvName) > -{ > - PSTR str = NULL; > + * CryptGetDefaultProviderA (ADVAPI32.@) > + * > + * See CryptGetDefaultProviderW. > + */ > +BOOL WINAPI CryptGetDefaultProviderA (DWORD dwProvType, DWORD > *pdwReserved, > + DWORD dwFlags, LPSTR pszProvName, DWORD *pcbProvName) > +{ > + PWSTR str = NULL; > DWORD strlen; > BOOL ret = FALSE; > > - DPRINT("(%ld, %p, %08ld, %p, %p)\n", dwProvType, pdwReserved, > dwFlags, pszProvName, pcbProvName); > - > - strlen = *pcbProvName / sizeof(WCHAR); > - if (pszProvName && !(str = CRYPT_Alloc(strlen))) > - CRYPT_ReturnLastError(ERROR_NOT_ENOUGH_MEMORY); > - ret = CryptGetDefaultProviderA(dwProvType, pdwReserved, dwFlags, > str, &strlen); > + DPRINT("(%d, %p, %08x, %p, %p)\n", dwProvType, pdwReserved, > dwFlags, pszProvName, pcbProvName); > + > + CryptGetDefaultProviderW(dwProvType, pdwReserved, dwFlags, NULL, > &strlen); > + if ( pszProvName && !(str = CRYPT_Alloc(strlen)) ) > + { > + SetLastError(ERROR_NOT_ENOUGH_MEMORY); > + return FALSE; > + } > + ret = CryptGetDefaultProviderW(dwProvType, pdwReserved, dwFlags, > str, &strlen); > if (str) > - { > - CRYPT_ANSIToUnicode(str, &pszProvName, *pcbProvName); > + CRYPT_UnicodeToANSI(str, &pszProvName, *pcbProvName); > + *pcbProvName = strlen / sizeof(WCHAR); > + if (str) > + { > CRYPT_Free(str); > - } > - *pcbProvName = strlen * sizeof(WCHAR); > + if (GetLastError() == ERROR_INSUFFICIENT_BUFFER) > + { > + SetLastError(ERROR_MORE_DATA); > + return FALSE; > + } > + } > return ret; > } > > @@ -1726,7 +1711,7 @@ > } > > > /****************************************************************************** > - * CryptSetProviderExA (ADVAPI32.@) > + * CryptSetProviderExW (ADVAPI32.@) > * > * Specifies the default CSP. > * > @@ -1740,58 +1725,75 @@ > * Success: TRUE > * Failure: FALSE > */ > -BOOL WINAPI CryptSetProviderExA (LPCSTR pszProvName, DWORD dwProvType, > DWORD *pdwReserved, DWORD dwFlags) > +BOOL WINAPI CryptSetProviderExW (LPCWSTR pszProvName, DWORD dwProvType, > DWORD *pdwReserved, DWORD dwFlags) > { > HKEY hProvKey, hTypeKey; > - PSTR keyname; > - > - DPRINT("(%s, %ld, %p, %08ld)\n", pszProvName, dwProvType, > pdwReserved, dwFlags); > + PWSTR keyname; > + static const WCHAR nameW[] = {'N','a','m','e',0}; > + > + DPRINT("(%S, %d, %p, %08x)\n", pszProvName, dwProvType, > pdwReserved, dwFlags); > > if (!pszProvName || pdwReserved) > - CRYPT_ReturnLastError(ERROR_INVALID_PARAMETER); > + { > + SetLastError(ERROR_INVALID_PARAMETER); > + return FALSE; > + } > if (dwProvType > MAXPROVTYPES) > - CRYPT_ReturnLastError(NTE_BAD_PROV_TYPE); > + { > + SetLastError(NTE_BAD_PROV_TYPE); > + return FALSE; > + } > if (dwFlags & ~(CRYPT_MACHINE_DEFAULT | CRYPT_USER_DEFAULT | > CRYPT_DELETE_DEFAULT) > || dwFlags == CRYPT_DELETE_DEFAULT) > - CRYPT_ReturnLastError(NTE_BAD_FLAGS); > + { > + SetLastError(NTE_BAD_FLAGS); > + return FALSE; > + } > > if (!(keyname = CRYPT_GetTypeKeyName(dwProvType, dwFlags & > CRYPT_USER_DEFAULT))) > - CRYPT_ReturnLastError(ERROR_NOT_ENOUGH_MEMORY); > - if (RegOpenKeyA((dwFlags & CRYPT_USER_DEFAULT) ? HKEY_CURRENT_USER > : HKEY_LOCAL_MACHINE, > + { > + SetLastError(ERROR_NOT_ENOUGH_MEMORY); > + return FALSE; > + } > + if (RegOpenKeyW((dwFlags & CRYPT_USER_DEFAULT) ? HKEY_CURRENT_USER > : HKEY_LOCAL_MACHINE, > keyname, &hTypeKey)) > { > CRYPT_Free(keyname); > - CRYPT_ReturnLastError(NTE_BAD_PROVIDER); > + SetLastError(NTE_BAD_PROVIDER); > + return FALSE; > } > CRYPT_Free(keyname); > - > + > if (dwFlags & CRYPT_DELETE_DEFAULT) > { > - RegDeleteValueA(hTypeKey, "Name"); > + RegDeleteValueW(hTypeKey, nameW); > } > else > { > if (!(keyname = CRYPT_GetProvKeyName(pszProvName))) > { > RegCloseKey(hTypeKey); > - CRYPT_ReturnLastError(ERROR_NOT_ENOUGH_MEMORY); > + SetLastError(ERROR_NOT_ENOUGH_MEMORY); > + return FALSE; > } > - if (RegOpenKeyA((dwFlags & CRYPT_USER_DEFAULT) ? > HKEY_CURRENT_USER : HKEY_LOCAL_MACHINE, > + if (RegOpenKeyW((dwFlags & CRYPT_USER_DEFAULT) ? > HKEY_CURRENT_USER : HKEY_LOCAL_MACHINE, > keyname, &hProvKey)) > { > CRYPT_Free(keyname); > RegCloseKey(hTypeKey); > - CRYPT_ReturnLastError(NTE_BAD_PROVIDER); > + SetLastError(NTE_BAD_PROVIDER); > + return FALSE; > } > CRYPT_Free(keyname); > - > - if (RegSetValueExA(hTypeKey, "Name", 0, REG_SZ, > (LPBYTE)pszProvName, strlen(pszProvName) + 1)) > + > + if (RegSetValueExW(hTypeKey, nameW, 0, REG_SZ, (const BYTE > *)pszProvName, > + (wcslen(pszProvName) + 1)*sizeof(WCHAR))) > { > RegCloseKey(hTypeKey); > RegCloseKey(hProvKey); > return FALSE; > } > - > + > RegCloseKey(hProvKey); > } > RegCloseKey(hTypeKey); > @@ -1800,20 +1802,20 @@ > } > > > /****************************************************************************** > - * CryptSetProviderExW (ADVAPI32.@) > - * > - * See CryptSetProviderExA > - */ > -BOOL WINAPI CryptSetProviderExW (LPCWSTR pszProvName, DWORD dwProvType, > DWORD *pdwReserved, DWORD dwFlags) > + * CryptSetProviderExA (ADVAPI32.@) > + * > + * See CryptSetProviderExW. > + */ > +BOOL WINAPI CryptSetProviderExA (LPCSTR pszProvName, DWORD dwProvType, > DWORD *pdwReserved, DWORD dwFlags) > { > BOOL ret = FALSE; > - PSTR str = NULL; > - > - DPRINT("(%S, %ld, %p, %08ld)\n", pszProvName, dwProvType, > pdwReserved, dwFlags); > - > - if (CRYPT_UnicodeToANSI(pszProvName, &str, -1)) > - { > - ret = CryptSetProviderExA(str, dwProvType, pdwReserved, > dwFlags); > + PWSTR str = NULL; > + > + DPRINT("(%s, %d, %p, %08x)\n", pszProvName, dwProvType, > pdwReserved, dwFlags); > + > + if (CRYPT_ANSIToUnicode(pszProvName, &str, -1)) > + { > + ret = CryptSetProviderExW(str, dwProvType, pdwReserved, > dwFlags); > CRYPT_Free(str); > } > return ret; > > Modified: trunk/reactos/dll/win32/advapi32/crypt/crypt.h > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/advapi32/crypt/c… > > ============================================================================== > --- trunk/reactos/dll/win32/advapi32/crypt/crypt.h (original) > +++ trunk/reactos/dll/win32/advapi32/crypt/crypt.h Thu Nov 15 17:08:18 > 2007 > @@ -15,7 +15,7 @@ > * > * You should have received a copy of the GNU Lesser General Public > * License along with this library; if not, write to the Free Software > - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 > USA > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, > USA > */ > > #ifndef __WINE_CRYPT_H > @@ -56,25 +56,28 @@ > BOOL (WINAPI *pCPVerifySignature)(HCRYPTPROV hProv, HCRYPTHASH > hHash, CONST BYTE *pbSignature, DWORD dwSigLen, HCRYPTKEY hPubKey, LPCWSTR > sDescription, DWORD dwFlags); > } PROVFUNCS, *PPROVFUNCS; > > +#define MAGIC_CRYPTPROV 0xA39E741F > + > typedef struct tagCRYPTPROV > { > + DWORD dwMagic; > UINT refcount; > HMODULE hModule; > PPROVFUNCS pFuncs; > - HCRYPTPROV hPrivate; /*CSP's handle - Should not be given to > application under any circumstances!*/ > + HCRYPTPROV hPrivate; /*CSP's handle - Should not be given to > application under any circumstances!*/ > PVTableProvStruc pVTable; > } CRYPTPROV, *PCRYPTPROV; > > typedef struct tagCRYPTKEY > { > PCRYPTPROV pProvider; > - HCRYPTKEY hPrivate; /*CSP's handle - Should not be given to > application under any circumstances!*/ > + HCRYPTKEY hPrivate; /*CSP's handle - Should not be given to > application under any circumstances!*/ > } CRYPTKEY, *PCRYPTKEY; > > typedef struct tagCRYPTHASH > { > PCRYPTPROV pProvider; > - HCRYPTHASH hPrivate; /*CSP's handle - Should not be given to > application under any circumstances!*/ > + HCRYPTHASH hPrivate; /*CSP's handle - Should not be given to > application under any circumstances!*/ > } CRYPTHASH, *PCRYPTHASH; > > #define MAXPROVTYPES 999 > @@ -82,7 +85,17 @@ > extern unsigned char *CRYPT_DESkey8to7( unsigned char *dst, const > unsigned char *key ); > extern unsigned char *CRYPT_DEShash( unsigned char *dst, const unsigned > char *key, > const unsigned char *src ); > +extern unsigned char *CRYPT_DESunhash( unsigned char *dst, const unsigned > char *key, > + const unsigned char *src ); > > extern VOID byteReverse(unsigned char *buf, unsigned longs); > > +struct ustring { > + DWORD Length; > + DWORD MaximumLength; > + unsigned char *Buffer; > +}; > + > +NTSTATUS WINAPI SystemFunction032(struct ustring *data, struct ustring > *key); > + > #endif /* __WINE_CRYPT_H_ */ > > > -- Best regards, Alex Ionescu

3 2

High-side Redzone Overwritten
by James Tabor 15 Nov '07

15 Nov '07

Hi, This does happen often with Qemu Linux and Windows. Very intermittent, one out of 50. Rev is at 30454. (ntoskrnl/kd/kdio.c:191) ----------------------------------------------------- (ntoskrnl/kd/kdio.c:192) ReactOS 0.4-SVN (Build 20071115-rUNKNOWN) (ntoskrnl/kd/kdio.c:193) Command Line: NOGUIBOOT DEBUGPORT=COM1 NOGUIBOOT DEBUGPORT=COM1 (ntoskrnl/kd/kdio.c:194) ARC Paths: multi(0)disk(0)cdrom(224) \ multi(0)disk(0)cdrom(224) \reactos\ (ntoskrnl/mm/mminit.c:266) Base Length Type (ntoskrnl/mm/mminit.c:272) 000000A0 00000060 FirmwarePermanent (ntoskrnl/mm/mminit.c:272) 00000800 0000028E SystemCode (ntoskrnl/mm/mminit.c:272) 00000A8E 0000000E BootDriver (ntoskrnl/mm/mminit.c:272) 00000A9C 0000001A HalCode (ntoskrnl/mm/mminit.c:272) 00000AB6 00000009 BootDriver (ntoskrnl/mm/mminit.c:272) 00000ABF 00000003 RegistryData (ntoskrnl/mm/mminit.c:272) 00000AC2 00000011 NlsData (ntoskrnl/mm/mminit.c:272) 00000AD3 00000011 NlsData (ntoskrnl/mm/mminit.c:272) 00000AE4 00000002 NlsData (ntoskrnl/mm/mminit.c:272) 00000AE6 0000002A BootDriver (ntoskrnl/mm/mminit.c:272) 00000B10 00000015 BootDriver (ntoskrnl/mm/mminit.c:272) 00000B25 00000017 BootDriver (ntoskrnl/mm/mminit.c:272) 00000B3C 0000000D BootDriver (ntoskrnl/mm/mminit.c:272) 00000B49 00000011 BootDriver (ntoskrnl/mm/mminit.c:272) 00000B5A 00000019 BootDriver (ntoskrnl/mm/mminit.c:272) 00000B73 00000012 BootDriver (ntoskrnl/mm/mminit.c:272) 00000B85 00000011 BootDriver (ntoskrnl/mm/mminit.c:272) 00000B96 00000013 BootDriver (ntoskrnl/mm/mminit.c:272) 00000BA9 00000013 BootDriver (ntoskrnl/mm/mminit.c:272) 00000BBC 0000000D BootDriver (ntoskrnl/mm/mminit.c:272) 00000BC9 00000009 BootDriver (ntoskrnl/mm/mminit.c:272) 00000BD2 0000042E Free (ntoskrnl/mm/mminit.c:272) 00000FC0 FFFFF840 SpecialMemory (ntoskrnl/mm/mminit.c:276) Total: 000000A0 (0 MB) Used memory 131008Kb (ntoskrnl/ke/i386/kiinit.c:47) Large Page support detected but not yet taken advantage of! (drivers/storage/scsiport/scsiport.c:1101) SpiCreatePortConfig() failed with Status 0xC00000C0 (drivers/storage/scsiport/scsiport.c:1101) SpiCreatePortConfig() failed with Status 0xC00000C0 WARNING: IoReportResourceUsage at ntoskrnl/io/iomgr/iorsrce.c:701 is UNIMPLEMENTED! WARNING: IoReportResourceUsage at ntoskrnl/io/iomgr/iorsrce.c:701 is UNIMPLEMENTED! (drivers/storage/scsiport/scsiport.c:1101) SpiCreatePortConfig() failed with Status 0xC00000C0 (drivers/storage/scsiport/scsiport.c:1101) SpiCreatePortConfig() failed with Status 0xC00000C0 (drivers/storage/scsiport/scsiport.c:1101) SpiCreatePortConfig() failed with Status 0xC00000C0 (ntoskrnl/io/iomgr/driver.c:1283) '\Driver\BUSLOGIC' initialization failed, status (0xc00000c0) (drivers/storage/class/disk/disk.c:1161) IoReadPartitionTable() status: 0x00000000 (ntoskrnl/io/iomgr/driver.c:1283) '\Driver\FLOPPY' initialization failed, status (0xc000000e) (ntoskrnl/io/iomgr/file.c:414) Using IopParseDevice() hack (ntoskrnl/io/iomgr/file.c:414) Using IopParseDevice() hack (ntoskrnl/io/iomgr/file.c:414) Using IopParseDevice() hack (ntoskrnl/io/iomgr/file.c:414) Using IopParseDevice() hack (ntoskrnl/io/iomgr/file.c:414) Using IopParseDevice() hack NPPOL: High-side redzone overwritten, Block 81281b98, Size 64, Tag 4552414d(ERAM), Caller 80854458 KeBugCheck at ntoskrnl/mm/npool.c:1514 *** Fatal System Error: 0x00000000 (0x00000000,0x00000000,0x00000000,0x00000000) <\SystemRoot\System32\NTOSKRNL.EXE: 2ae0> ke/bug.c:1359 (KeBugCheck@4) <\SystemRoot\System32\NTOSKRNL.EXE: 56c6c> mm/npool.c:1514 (check_redzone_header) <\SystemRoot\System32\NTOSKRNL.EXE: 56d6e> mm/npool.c:1579 (ExFreeNonPagedPool@4) <\SystemRoot\System32\NTOSKRNL.EXE: 59c64> mm/pool.c:239 (ExFreePool@4) <\SystemRoot\System32\NTOSKRNL.EXE: 59ca2> mm/pool.c:249 (ExFreePoolWithTag@8) <\SystemRoot\System32\NTOSKRNL.EXE: 54803> mm/marea.c:854 (MmFreeMemoryArea@16) <\SystemRoot\System32\NTOSKRNL.EXE: dde5> cc/view.c:923 (CcRosInternalFreeCacheSegment) <\SystemRoot\System32\NTOSKRNL.EXE: f350> cc/view.c:381 (CcRosTrimCache) <\SystemRoot\System32\NTOSKRNL.EXE: 51c6d> mm/balance.c:147 (MiTrimMemoryConsumer@4) <\SystemRoot\System32\NTOSKRNL.EXE: 51fc0> mm/balance.c:205 (MmRequestPageMemoryConsumer@12) <\SystemRoot\System32\NTOSKRNL.EXE: ef81> cc/view.c:709 (CcRosCreateCacheSegment) <\SystemRoot\System32\NTOSKRNL.EXE: f0dd> cc/view.c:817 (CcRosGetCacheSegment@24) <\SystemRoot\System32\NTOSKRNL.EXE: f114> cc/view.c:860 (CcRosRequestCacheSegment@20) <\SystemRoot\System32\NTOSKRNL.EXE: da90> cc/pin.c:64 (CcMapData@24) <\SystemRoot\System32\drivers\VFATFS.SYS: 5274> fat.c:415 (CountAvailableClusters) <\SystemRoot\System32\drivers\VFATFS.SYS: ba1c> volume.c:119 (VfatQueryVolumeInformation) <\SystemRoot\System32\drivers\VFATFS.SYS: 97ac> misc.c:121 (VfatDispatchRequest) <\SystemRoot\System32\drivers\VFATFS.SYS: 98ab> misc.c:167 (VfatBuildRequest@8) <\SystemRoot\System32\NTOSKRNL.EXE: 44f96> io/iomgr/irp.c:1134 (@IofCallDriver@8) <\SystemRoot\System32\NTOSKRNL.EXE: 3f924> io/iomgr/iofunc.c:137 (IopPerformSynchronousRequest@28) <\SystemRoot\System32\NTOSKRNL.EXE: 41c2d> io/iomgr/iofunc.c:3157 (NtQueryVolumeInformationFile@20) <\SystemRoot\System32\NTOSKRNL.EXE: 893ba> ke/i386/trap.s:244 (KiFastCallEntry) <\SystemRoot\System32\NTOSKRNL.EXE: 84ab9> ex/zw.S:1694 (ZwQueryVolumeInformationFile) <\SystemRoot\System32\NTOSKRNL.EXE: 18208> config/cmsysini.c:101 (CmpInitHiveFromFile@20) <\SystemRoot\System32\NTOSKRNL.EXE: 1b7d2> cm/regfile.c:38 (CmiLoadHive) <\SystemRoot\System32\NTOSKRNL.EXE: 1ba0d> cm/registry.c:408 (CmiInitHives) <\SystemRoot\System32\NTOSKRNL.EXE: 1a6ae> cm/ntfunc.c:637 (NtInitializeRegistry@4) <\SystemRoot\System32\NTOSKRNL.EXE: 893ba> ntoskrnl/ke/i386/trap.s:244 (KiFastCallEntry)

1 0

[ros-diffs] [weiden] 29670: Tweak the ScrollDC implementation a bit so that it produces a better output. The implementation still is completely incorrect as it should call the driver for this operation instead of doing a BitBlt operation...
by Timo Kreuzer 14 Nov '07

14 Nov '07

NtGdiBitBlt calls IntEngBitBlt, wich calls DrvBitBlt if available. There's no DrvScroll function. Timo > Author: weiden > Date: Fri Oct 19 07:23:04 2007 > New Revision: 29670 > > URL: http://svn.reactos.org/svn/reactos?rev=29670&view=rev <http://svn.reactos.org/svn/reactos?rev=29670&view=rev> > Log: > Tweak the ScrollDC implementation a bit so that it produces a better output. The implementation still is completely incorrect as it should call the driver for this operation instead of doing a BitBlt operation... > > Modified: > trunk/reactos/subsystems/win32/win32k/ntuser/painting.c >

3 2

Re: [ros-dev] About UNICODE<->ASCII support.
by carlo.bramix 14 Nov '07

14 Nov '07

Hello, honestly, your enthusiasm seems a bit to exagerated to me! In the specific case, it looks like that all TCHARs in Taskmgr have been converted to WCHAR because the programme receives from the API some informations that are UNICODE only. I can understand and I agree to that, afterall it can be made working with unicows layer, if someone wants (and infact, I did it). Athough you should also admit that two WideCharToMultiByte() calls are not exactly something we can call "drammatic" code, which is automatically excluded by the presence of the magic UNICODE macro. I also agree with the fact that there could be the source code which interacts with UNICODE-only variables and the direct usage of WCHAR instead of TCHAR is very helpful and clean. But how many functions have this behavior (WCHAR-only)? It is not too difficult to count them and in my opinion this does not justify a refresh of sources for making TCHAR>WCHAR, or MessageBox>MessageBoxW... Last but not last... human beings can do errors, their changes may always introduce new errors, so more time for testing, etc... If I can do a suggestion, I would avoid unnecesary changes for this reason too. Afterall the binary code of the executable won't change by a single bit when TCHARs are converted to WCHARs at compile time, if there are not drawbacks like tons of conversions which will make the source code unreadable (it's also important that people understand the code for contribuiting). But if there are just TCHARs/_tcscpy/... I don't understand the reason. Sincerely, Carlo Bramini. ---------- Initial Header ----------- >From : ros-dev-bounces(a)reactos.org To : "ReactOS Development List" ros-dev(a)reactos.org Cc : Date : Mon, 5 Nov 2007 23:55:35 +0000 Subject : Re: [ros-dev] About UNICODE<->ASCII support. > On Nov 5, 2007 5:53 PM, Colin Finck <mail(a)colinfinck.de> wrote: > > Hi Ged, > > > > > Ged wrote: > > > This is the wrong way to be working. We should be dropping > > > support for ASCII where ever possible now. > > > > Is this really the official course now? > > This has pretty much always been the course. > There is absolutely no reason to use TCHAR, it was relevant 10 years > ago, but not any more. > > (btw, in case anyone thinks I'm contradicting myself with mstsc, TCHAR > is only being used as it's currently a port of an ASCII app) > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

4 3

Re: [ros-dev] Introduction
by Aleksey Bragin 13 Nov '07

13 Nov '07

Hi, welcome. The best is to join #reactos on freenode and have a live talk with devs. The language used throughout ReactOS is mostly C, with very few exceptions to C++. And if you have WinAPI knowledge, it would be appreciated. WBR, Aleksey Bragin. On Nov 14, 2007, at 12:16 AM, James Holland wrote: > My name is James Holland. I am interested in helping with the > development of ReactOS. I am fairly adept with C++. I also have used > APL (not very well) and MS Visual Basic at past times. I am currently > using Java in my Computer Science class. > > For background, I am a Student at New Mexico Tech. My major is > Electrical Engineering. > > I am open for any suggestions as to what I should do. > > James Holland

1 0

Introduction
by James Holland 13 Nov '07

13 Nov '07

My name is James Holland. I am interested in helping with the development of ReactOS. I am fairly adept with C++. I also have used APL (not very well) and MS Visual Basic at past times. I am currently using Java in my Computer Science class. For background, I am a Student at New Mexico Tech. My major is Electrical Engineering. I am open for any suggestions as to what I should do. James Holland

1 0

Re: [ros-dev] About UNICODE<->ASCII support.
by carlo.bramix 13 Nov '07

13 Nov '07

Hello, Probably, you are right. It's better to close this discussion here. I will move my interests elsewhere, where your nice replies won't reach me. Greetings to all. Sincerely, Carlo Bramini. "unsubscribe"... <click> ---------- Initial Header ----------- >From : ros-dev-bounces(a)reactos.org To : "ReactOS Development List" ros-dev(a)reactos.org Cc : Date : Tue, 13 Nov 2007 15:07:35 -0000 Subject : Re: [ros-dev] About UNICODE<->ASCII support. > carlo.bramix wrote: > > > But, for an ascii-based OS, it's a compromise for getting the > > application working because that application, if compiled in that > > configuration, will work only on Win9x/ME. > > We have no interest in ascii-based OS's, we have no interest in 9x/ME. > > > And this is what I cannot understand: the ability to work in both > enviroment > > is an *added*value* to the software, not a defect. > > Why? ReactOS apps have no value in being built as ASCII. > ASCII is both rude and prehistoric. Move on, this is the 21st century, > ReactOS is a unicode operating system. > As far as we're concerned Win9x is dead. > > > Just another small bit: besides the functions with the 'W' suffix (while > the > > remaining part of the planet uses at least the unified function names), > > sometimes debugging directly unicode is a pain, at least for me... > > Well you stay on your prefered half of the planet and stop bothering us with > your > ASCII ranting... > > I'd hate to see you work with C#, you'd have a fit as it's unicode only. > I have visions of you p/invoking everything to make sure you can still build > your .NET apps as ASCII. > > > The strings into the debuggers are shown as a vector of words instead of a > > > clear string, same condition when declaring some constant strings into the > > > sources, as vector of single chars... > > Horrible (urgh!). > > Get yourself a decent debugger then, or close your eyes, or give up. > > > Ged. > > > > > > > > > > > > > > > > > > This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. > > Amteus Secure Communications Ltd > 57 Cardigan Lane, > Leeds, > LS4 2LE > t: +44 (0) 870 8368770 > f: +44 (0) 870 8368701 > > Registered in England No 4760795 > > http://www.amteus.com > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

1 0

Re: [ros-dev] About UNICODE<->ASCII support.
by carlo.bramix 13 Nov '07

13 Nov '07

Hello, > > Athough you should also admit that two WideCharToMultiByte() > > calls are not exactly something we can call "drammatic" code > As I also said, WideCharToMultiByte() can cause data corruption if a Unicode > character isn't supported by the currently selected ANSI codepage. > MultiByteToWideChar() is no problem, but the other direction can be > problematic. > After all, we're coding for Windows Server 2003-compatibility here. > We don't have to care about compatibility with Win9x (ANSI-only) or previous > NT versions. That's right, it can cause corruption. But, for an ascii-based OS, it's a compromise for getting the application working because that application, if compiled in that configuration, will work only on Win9x/ME. If someone wants to make an object working on his old OS, he must also be ready to the drawbacks, this has never been a news. Afterall, unicows is doing the same job when wrapping the vaious widechar APIs. But for NT and later, everything just need to be compiled as UNICODE, no? And this is what I cannot understand: the ability to work in both enviroment is an *added*value* to the software, not a defect. I just wanted to clarify that I was not asking to release the accessories and/or other parts of ReactOS' binaries compiled for ASCII. Absolutely not, in no way! Read: I want the most flexible international support available. Just another small bit: besides the functions with the 'W' suffix (while the remaining part of the planet uses at least the unified function names), sometimes debugging directly unicode is a pain, at least for me... The strings into the debuggers are shown as a vector of words instead of a clear string, same condition when declaring some constant strings into the sources, as vector of single chars... Horrible (urgh!). Sincerely, Carlo Bramini

2 1

rbuild auto generated resources
by Marc Piulachs 13 Nov '07

13 Nov '07

>From all changes introduced on my rbuild branch auto generated resources seems to be the most controversial by far so I will try to explain here the design decision behind it One of my particular obsessions is trying to optimize and automate the maxium ammout of things, if something can be reasonably created automatically why do it by hand? CURRENT SITUATION ================= Currently the version common defines REACTOS_STR_FILE_DESCRIPTION , REACTOS_STR_INTERNAL_NAME and REACTOS_STR_ORIGINAL_FILENAME , localized resources and theme manifest are added to [modulename].rc , rsrc.rc or splitted between both. Problems: - Theme manifests files "manifest.xml" are architecture dependent (X86) - Duplicated content, we will have hundreds of identical manifest files for every aplication - No way to compile an aplication without manifest - No way to compile an aplication with only specified localizations - Duplicated work, rbuild has all the information required to automatically generate the defines - If we decide to rename or introduce a new define in the future we will have to edit all resources by hand. - Resource localizations are compiled with any control , the only way to check if they are included is by hand. Advantatges to my proposal: - It solve all the above problems. - Reduce man work - Allows future changes in the format (editing the resource generator source code (1 file) vs all resources files on SVN) - It's the base to other future enchancments , when a new feature is added to rbuild we have just to modify it and all modules will automatically inherit it. An most important of all , it represents a change of the model to a metadata oriented build process. You describe the content (source code , resources ...) rather than the build , rbuild uses that information to generate the apropiate image (as always) but this information can also be used for multiple other things, analitics , reports , web .... How does it work? ================= First of all IT'S OPTIONAL , you can decide to use it or not, your choice. We will use the eventvwr.rbuild as sample: <?xml version="1.0"?> <module name="eventvwr" type="win32gui" installbase="system32" installname="eventvwr.exe"> <include base="eventvwr">.</include> <include base="eventvwr" root="intermediate">.</include> ...  <automanifest>manifest.xml</automanifest> <autoresource>auto.rc</autoresource>  <developer>mpiulachs</developer> <translator>cfinck</translator> <translator>fireball</translator> <translator>mpiulachs</translator> <metadata description="ReactOS Event Log Viewer" />  <localization isoname="de-DE">lang/de-DE.rc</localization> <localization isoname="en-US">lang/en-US.rc</localization> <localization isoname="es-ES">lang/es-ES.rc</localization> <localization isoname="fr-FR">lang/fr-FR.rc</localization> <localization isoname="ru-RU">lang/ru-RU.rc</localization> </module> to turn auto resources on we have to add the <autoresource> element with the name of the resource that will be created in the INTERMEDIATE folder in this case it will be named "auto.rc". It will also automatically create the apropiate manifest.xml file for the architecture being build (x86 or PPC) and will reference it in "auto.rc" Also it will validate and include the localizations, even it has localizations for 5 languages it will only compile those specified on languages.rbuild See attached files for autogenerated content I tried to explain the motivation behind my changes and why I think they are positive , of course I'm open to your questions , ideas or comments but please be contructive and argument your point of view , "I don't like it , we won't use it" as someone said is not an expected opinion. /Marc

8 21

question
by David Johnson 13 Nov '07

13 Nov '07

How is it possible to tell XP what specific IRQ to put your audio card on in Standard PC mode? 1 In the motherboard BIOS. 2 In the Device Manager. 3 Put the card in the corresponding slot. 4 There are jumpers on most motherboards that you can change to direct IRQs. 5 None of the above. _________________________________ Dave Johnson http://www.davefilms.us DaveFILMS® San Diego, CA & Nashville, TN http://perditioncity.us/ Voice Talent Writer, Producer, Director Independent Audio Theater Producer Voice mail and Fax#:(206)350-2915 Voice (615)722-2249 Skype & Msn Live messanger "DaveFilms" AIM / iChat AV "DaveFilms2007"

1 0

vr IRQ in windows
by David Johnson 13 Nov '07

13 Nov '07

Please list all VR IRQ in NT 5.1 and VI IF my computer is not in ACPI m ode is it in Standard PC mode? Please reply.. It is vary important. _________________________________ Dave Johnson http://www.davefilms.us DaveFILMS® San Diego, CA & Nashville, TN http://perditioncity.us/ Voice Talent Writer, Producer, Director Independent Audio Theater Producer Voice mail and Fax#:(206)350-2915 Voice (615)722-2249 Skype & Msn Live messanger "DaveFilms" AIM / iChat AV "DaveFilms2007"

1 0

Re: [ros-dev] [ros-diffs] [arty] 30352: Add structures related to devtree.c
by Aleksey Bragin 12 Nov '07

12 Nov '07

Why not use a linked list structure in LOADER_PARAMETER_BLOCK, describing hardware device tree? (I implemented a bit of it in winldr). Or is it for a different purpose? WBR, Aleksey Bragin. On Nov 11, 2007, at 12:27 PM, arty(a)svn.reactos.org wrote: > Author: arty > Date: Sun Nov 11 12:27:07 2007 > New Revision: 30352 > > URL: http://svn.reactos.org/svn/reactos?rev=30352&view=rev > Log: > Add structures related to devtree.c > > Modified: > trunk/reactos/include/reactos/ppcboot.h

2 1

Re: [ros-dev] Tracking implementation API status
by Aleksey Bragin 12 Nov '07

12 Nov '07

Hi, no, I was speaking about something different. Take a look - http://www.reactos.org/wiki/index.php/Coding_Style there I mean this: /*++ * @name SomeAPI * @implemented NT4 * * Do nothing for 500ms. * * @param SomeParameter * Description of the parameter. Wrapped to more lines on ~70th * column. * * @param YetAnotherParameter * Bleh, bleh :) * * @return STATUS_SUCCESS in case of success, STATUS_UNSUCCESSFUL * othwerwise. * * @remarks Must be called at IRQL == DISPATCH_LEVEL * *--*/ NTSTATUS STDCALL SomeAPI( ... rgenstat-alike tool should be able to parse such header, not only the old-style simple /* @implemented */ WBR, Aleksey Bragin. On Nov 10, 2007, at 1:06 AM, Marc Piulachs wrote: > Hi Aleksey, > > > > I don’t know if I understood you completely, rgenstat works by > parsing c/cpp source files not header files. What do you mean with > “standard function header”? > > > > If we are seriously going to use it I would like to make some > slightly modifications to it to make it more powerful but would > require help from someone with more experience than me writing > parsers in C. > > > > Regards, > > /Marc

4 4

Re: [ros-dev] rbuild auto generated resources
by Aleksey Bragin 11 Nov '07

11 Nov '07

On Nov 12, 2007, at 1:56 AM, Timo Kreuzer wrote: >> Once again, the data extracted from parsing is not TRUE metadata just >> meaningless strings that you can guess or interpret : "author : >> jdoe" , >> "author : jhondoe" , "author : jhon doe" are 3 different persons and >> Jhon Doe just one , I think it's obvious. >> > I disagree here. IMO information about developers and translators > belong to svn. They should neither go into the sources nor into > rbuild files. If you want to find out about it, ask svn and it will > tell you the exact name. We also don't really have maintainers for > most modules, so most rbuild files would be spammed with the names > of lots of developers without saying anything about who wrote a > paticular piece of code. There is standard per-file header for ReactOS source code (if it's not used everywhere, it's a temporary problem), which lists programmers, and it's usually (almost always) maintained. Whenever our code is indexed by systems like Google codesearch, everyone can clearly see the license and authorship from the source file. Additionally, SVN holds exact per-line history of changes. What's the benefit of storing authoship in .rbuild too? (I agree it is logical, but if there is no benefit, then...) WBR, Aleksey Bragin.

2 1

Re: [ros-dev] Tracking implementation API status
by Aleksey Bragin 11 Nov '07

11 Nov '07

Your opinion does have a strong point. Implemented/unimplemented were useful in the early stages, I think. Right now, for both Wine and ReactOS, the quality of implementation matters, not quantity. How is Wine's system done, about documenting functions - where is it done? Source code comments? Can it be adjusted to fit ReactOS coding style? WBR, Aleksey Bragin. On Nov 10, 2007, at 10:16 PM, Steven Edwards wrote: > On Nov 10, 2007 4:00 AM, Aleksey Bragin <aleksey(a)reactos.org> wrote: >> Hi, >> no, I was speaking about something different. >> Take a look - http://www.reactos.org/wiki/index.php/Coding_Style >> there I mean this: > > The implemented/unimplemented tags are really worthless because what > if the API takes 20 params and 18 of them are implemented > and nothing known uses the other 2 params? Do you call it implemented > or unimplemented? Its better to autogenerate the docs from the > function comment headers. See here, I think this is a MUCH better > system and it already works. No point in developing another. > > http://source.winehq.org/WineAPI/ > > If the API does not show up in the documented API then it should be > safe to assume its not implemented. If it is implemented and not > documented then its a Janitorial project. > > -- > 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 > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev

5 4

Re: [ros-dev] Tracking implementation API status
by Aleksey Bragin 09 Nov '07

09 Nov '07

I support that, though some modifications should be required, because in the kernel a standard function header [should be]/is used. If it's able to parse that header too (provided it contains the @implemented/ @unimplemented), then it's great. WBR, Aleksey Bragin. On Nov 9, 2007, at 8:29 PM, Marc Piulachs wrote: > As most of you know, Casper created a small tool rgenstat (tools/ > rgenstat) that is able to parse source code for modules specified > on apistatus.lst seeking for public APIs decorated with the > @implemented or @unimplemented C comment. Rgenstat when invoked > typing “make rgenstat” it produces an xml file containing all the > functions and it’s current implementation status. With this > database we can do all sorts of automatic compatibility reports . > see for example wine’s equivalent http://www.winehq.org/site/status > or http://www.codexchange.net/roslib generated from incomplete > reactos data , (work in progress) > > > > As it easy and not intrusive I would suggest using this feature to > kernel and core developers. Fireball , GreatLord , Jim , what do > you think about that ? > > > > /Marc

2 1

Re: [ros-dev] rbuild auto generated resources
by Aleksey Bragin 09 Nov '07

09 Nov '07

If it's impossible to make correct .rc files (without the hassle of using backends), then Marc's way is a way to go. There is such tool by Wine, which uses .spec, it may need writing a MSVC-backend though,. WBR, Aleksey Bragin. On Nov 9, 2007, at 10:56 PM, Alex Ionescu wrote: > I think you're all missing the point. > > As it stands now, MSVC won't even READ most of your resource files > because you've decided to write them in a way that violates the .rc > standard and that only binres/windres/whatever-you-call-that- > incompatible-garbage can parse. > > Mark's proposal, apart from fixing all the problems he brought up, > will finally allow you to write resource files that both MSVC and > your-retarded-rc-compiler-name-goes-here can understand, with minimum > effort. Right now, you're all stuck rewriting all your .rc files and > creating .msvc.rc files. > > By the way Mark, you should extend this to definition files. Once > again, MSVC is incompatible with all the ReactOS .def files, which > have been tailored so that Mangle32-gcc can understand them, so > you'll have to create msvc.def files as well. > > The more rbuild can generate independently, the better. You get MSVC > files *after* running "make msvc8", and it's that step that would be > creating the .def/.rc files for MSVC anyway -- what exaclty is it all > you're complaining about regarding "MSVC" compatibility? You don't > have it, how the hell can you lose it, and more importantly, why is > the only suggestion that will finally let you have it "disliked"?! > > You make no sense. > > -- > Best regards, > Alex Ionescu

1 0

Re: [ros-dev] rbuild auto generated resources
by Marc Piulachs 09 Nov '07

09 Nov '07

Forgot to attach autogenerated sample files _____ From: Marc Piulachs [mailto:marc.piulachs@codexchange.net] Sent: Friday, November 09, 2007 7:24 PM To: 'ReactOS Development List' Subject: rbuild auto generated resources >From all changes introduced on my rbuild branch auto generated resources seems to be the most controversial by far so I will try to explain here the design decision behind it One of my particular obsessions is trying to optimize and automate the maxium ammout of things, if something can be reasonably created automatically why do it by hand? CURRENT SITUATION ================= Currently the version common defines REACTOS_STR_FILE_DESCRIPTION , REACTOS_STR_INTERNAL_NAME and REACTOS_STR_ORIGINAL_FILENAME , localized resources and theme manifest are added to [modulename].rc , rsrc.rc or splitted between both. Problems: - Theme manifests files "manifest.xml" are architecture dependent (X86) - Duplicated content, we will have hundreds of identical manifest files for every aplication - No way to compile an aplication without manifest - No way to compile an aplication with only specified localizations - Duplicated work, rbuild has all the information required to automatically generate the defines - If we decide to rename or introduce a new define in the future we will have to edit all resources by hand. - Resource localizations are compiled with any control , the only way to check if they are included is by hand. Advantatges to my proposal: - It solve all the above problems. - Reduce man work - Allows future changes in the format (editing the resource generator source code (1 file) vs all resources files on SVN) - It's the base to other future enchancments , when a new feature is added to rbuild we have just to modify it and all modules will automatically inherit it. An most important of all , it represents a change of the model to a metadata oriented build process. You describe the content (source code , resources ...) rather than the build , rbuild uses that information to generate the apropiate image (as always) but this information can also be used for multiple other things, analitics , reports , web .... How does it work? ================= First of all IT'S OPTIONAL , you can decide to use it or not, your choice. We will use the eventvwr.rbuild as sample: <?xml version="1.0"?> <module name="eventvwr" type="win32gui" installbase="system32" installname="eventvwr.exe"> <include base="eventvwr">.</include> <include base="eventvwr" root="intermediate">.</include> ...  <automanifest>manifest.xml</automanifest> <autoresource>auto.rc</autoresource>  <developer>mpiulachs</developer> <translator>cfinck</translator> <translator>fireball</translator> <translator>mpiulachs</translator> <metadata description="ReactOS Event Log Viewer" />  <localization isoname="de-DE">lang/de-DE.rc</localization> <localization isoname="en-US">lang/en-US.rc</localization> <localization isoname="es-ES">lang/es-ES.rc</localization> <localization isoname="fr-FR">lang/fr-FR.rc</localization> <localization isoname="ru-RU">lang/ru-RU.rc</localization> </module> to turn auto resources on we have to add the <autoresource> element with the name of the resource that will be created in the INTERMEDIATE folder in this case it will be named "auto.rc". It will also automatically create the apropiate manifest.xml file for the architecture being build (x86 or PPC) and will reference it in "auto.rc" Also it will validate and include the localizations, even it has localizations for 5 languages it will only compile those specified on languages.rbuild See attached files for autogenerated content I tried to explain the motivation behind my changes and why I think they are positive , of course I'm open to your questions , ideas or comments but please be contructive and argument your point of view , "I don't like it , we won't use it" as someone said is not an expected opinion. /Marc

1 0

Tracking implementation API status
by Marc Piulachs 09 Nov '07

09 Nov '07

As most of you know, Casper created a small tool rgenstat (tools/rgenstat) that is able to parse source code for modules specified on apistatus.lst seeking for public APIs decorated with the @implemented or @unimplemented C comment. Rgenstat when invoked typing "make rgenstat" it produces an xml file containing all the functions and it's current implementation status. With this database we can do all sorts of automatic compatibility reports . see for example wine's equivalent http://www.winehq.org/site/status or http://www.codexchange.net/roslib generated from incomplete reactos data , (work in progress) As it easy and not intrusive I would suggest using this feature to kernel and core developers. Fireball , GreatLord , Jim , what do you think about that ? /Marc

1 0

Window Handle Leak
by James Tabor 09 Nov '07

09 Nov '07

Hi, Here is a list of files that use ntuser/object.c As you all see, we Dereference more than we Reference! Reference is 0 so we are using Dereference as a delete? This is a mess! Not once is a Thread referenced! Thanks, James ./callproc.c:52: ObmDeleteObject(Handle, ./hook.c:209: ObmDeleteObject(Hook->Self, otHook); ./cursoricon.c:413: ObmDeleteObject(hCurIcon, otCursorIcon); ./cursoricon.c:487: Ret = ObmDeleteObject(CurIcon->Self, otCursorIcon); ./menu.c:320: ObmDeleteObject(Menu->MenuInfo.Self, otMenu); ./window.c:433: ObmDeleteObject(Window->hSelf, otWindow); ./accelerator.c:365: ObmDeleteObject(hAccel, otAccel); ./accelerator.c:374: ObmDeleteObject(hAccel, otAccel); ./accelerator.c:414: ObmDeleteObject(hAccel, otAccel); ./callproc.c:64: NewCallProc = (PCALLPROC)ObmCreateObject(gHandleTable, ./callproc.c:88: NewCallProc = (PCALLPROC)ObmCreateObject(gHandleTable, ./hook.c:113: Hook = ObmCreateObject(gHandleTable, &Handle, otHook, sizeof(HOOK)); ./monitor.c:92: Monitor = ObmCreateObject(gHandleTable, &Handle, otMonitor, sizeof (MONITOR_OBJECT)); ./cursoricon.c:399: CurIcon = ObmCreateObject(gHandleTable, &hCurIcon, otCursorIcon, sizeof(CURICON_OBJECT)); ./menu.c:333: Menu = (PMENU_OBJECT)ObmCreateObject( ./menu.c:442: Menu = (PMENU_OBJECT)ObmCreateObject( ./window.c:1537: ObmCreateObject(gHandleTable, (PHANDLE)&hWnd, ./accelerator.c:351: Accel = ObmCreateObject(gHandleTable, (PHANDLE)&hAccel, otAccel, sizeof(ACCELERATOR_TABLE)); ./input.c:1045: ObmDereferenceObject(DesktopWindow); ./msgqueue.c:776: ObmDereferenceObject(Window); ./hook.c:449: ObmDereferenceObject(HookObj); ./hook.c:455: ObmDereferenceObject(HookObj); ./hook.c:624: ObmDereferenceObject(Hook); ./hook.c:639: ObmDereferenceObject(Hook); ./hook.c:656: ObmDereferenceObject(Hook); ./hook.c:673: ObmDereferenceObject(Hook); ./hook.c:738: ObmDereferenceObject(HookObj); ./monitor.c:119: ObmDereferenceObject(pMonitor); ./cursoricon.c:375:// ObmDereferenceObject(CurIcon); ./cursoricon.c:386:// ObmDereferenceObject(CurIcon); ./cursoricon.c:414: ObmDereferenceObject(CurIcon); ./cursoricon.c:420: ObmDereferenceObject(CurIcon); ./cursoricon.c:532:// ObmDereferenceObject(Object); ./cursoricon.c:369:// ObmReferenceObject( CurIcon); ./cursoricon.c:519:// ObmReferenceObject(CurIcon);

2 1

Re: [ros-dev] [ros-diffs] [weiden] 29670: Tweak the ScrollDC implementation
by tamlin＠algonet.se 08 Nov '07

08 Nov '07

jimtabor wrote: >I noticed WndProc messages originate from win32k too. The window thread is >locked and then the message is sent out. > >Example: Function call User32 -> Win32k -> send message. > >Maybe we are doing double the work when we scroll on a bar. The rapid >blinking of the bar too. We maybe sending more than one message out. Trying a hypothesis here, could it work if all such w32k-registered- and-managed window classes, if not subclassed by the app, lock visual updates while calling back into usermode (cmp. LockWindowUpdate(hWnd) )? (recursive calls, whether intentional or from buggy user-mode app code could invalidate it) >4. Fix bugs. >5. Get paid! If you solve that... :-) -- Mike

2 2

Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1
by Olaf Siejka 07 Nov '07

07 Nov '07

> > > - Declarative module localizations : Now module localizations are created > in > a declarative way which makes trivial tasks like listing non existent or > outdated language localizations in real time for example : > > http://www.codexchange.net/rosdoc/localizations.htm > > Let me know your opinions and suggestions as I would like to start > finishing > some of this features and merge all/part of my changes back to trunk > I find this part extremely important. It would allow real-time tracking of translation progress/status (if i understood it correctly) which would greatly help maintain all the growing ROS localizations and help all ROS translating teams. Such webpage, as you presented here, should be created on ROS website as soon as it would be possible.

5 17

About UNICODE<->ASCII support.
by carlo.bramix 06 Nov '07

06 Nov '07

Hello everyone, I just would like talk about a recent fix applied to one of the components of ReactOS. It is not my intention to make problems in any way with this topic, or pretending a change of the direction taken by the project (peace!). In that recent change, the hybrid support for both ASCII and UNICODE support into task manager has been dropped. I would like that you try to review your opinion on such changes. Me too, I want final builds of executables in unicode format. I think to know almost all advantages of international support. However, I also believe that you should not see the ASCII support as something to throw out of the window, but as a chance, because not all applications in the world are compiled as unicode, so having something to test the ASCII implementation included into ROS is not a so bad idea. As I said, it is a chance for testing. Some of the work here seems derived from wine, but probably (or better: surely) people behind wine had to face to the problem called "debugging" before they got something stable. A closed-source application may not work, but at least there is a chance (perhaps minimal or even less) to replicate a bug into one of the applications available to us. Technically, it isn't a problem for me to make things working on win9x, since I just need to link to UNICOWS.DLL and the problem is almost solved. I just don't like very much that position. And I also understand that my opinion isn't important at all in front of your decisions or the ReactOS standard. Sincerely, Carlo Bramini.

5 5

Online translation service
by Olaf Siejka 05 Nov '07

05 Nov '07

I have no idea on what is being prepared or planned, nor i do not need any mean for translating RC files online. My only concern is for easier control of localisation for a given language, so i dont have to manually check every single one of the rc files. Best regards

2 1

Mile Stones
by James Tabor 05 Nov '07

05 Nov '07

To all! A monumental mile stone was crossed today at 2000z 05/11/2007. ReactOS is now a true GUI/OS. Thread batching is functional and tested good. Solitaire was the program and it only ran once, the function was SetBrushOrgEx. Thanks goes out to all of you and my excitement is the fun I am having working with all of you with this project. Sorry for things said in the past and knowing in all good intentions you all did your best to bring this project to this point. Thanks! James PS: Keep coding! and go back to work!

1 0

work on rbuild branch
by Marc Piulachs 03 Nov '07

03 Nov '07

As some of you may know I have been working in rbuild on my own branch (http://svn.reactos.org/svn/reactos/branches/rbuild/reactos/) for the last two weeks. I will summarize my most important changes here so anyone can give me their opinion: - Created a new concept "the cd bootstrap folder" . The cd bootstrap folder is a user customizable folder in the cd's root that defaults to the current build architecture for example i386 o ppc. - Modifed the InstallBase from the BootStrap element to be relative to the bootstrap folder, for example the usetup bootstrap: <bootstrap installbase="system32" nameoncd="smss.exe" /> will be created in : (CD)\i386\system32\smss.exe on a I386 build and (CD)\ppc\system32\smss.exe on a powerpc build - Introduced a new element "bootstrapfile" equivalent to the bootstrap for module target but applied to regular files for example : <bootstrapfile>hivecls.inf</bootstrapfile> will be placed in : (CD)\i386\hivecls.inf on a I386 build and (CD)\ppc\hivecls.inf on a powerpc build With these changes we will be able to place complete installation for more than one architecture in the same cd .Only one of the architectures will be able to be booted by default but we can include the cdmake utility + some .bat files in a (CD)\tools folder so the user can download the official CD with all supported architectures and create a bootable boot CD for a particular architecture. cool huh? - Experimental support to autogenerate rsrc.rc equivalent and platform dependent manifest.xml to intermediate folder - Add preliminary support to track authors/contributors/developers/translators for each module. It can be useful to autogenerate uptodate \CREDITS file , module/authors reports (see for example: http://www.codexchange.net/rosdoc/authors.htm or http://www.codexchange.net/rosdoc/eventvwr.htm) or even source code for modules like notevil - Autogenerate CREDITS file in intermediate folder (for now) - Declarative module localizations : Now module localizations are created in a declarative way which makes trivial tasks like listing non existent or outdated language localizations in real time for example : http://www.codexchange.net/rosdoc/localizations.htm Let me know your opinions and suggestions as I would like to start finishing some of this features and merge all/part of my changes back to trunk note: The produced iso images won't boot due to relocation of the \loader folder. boot/freeldr/bootsect/isoboot.asm and isobtrt.asm will have to be modified to search \i386\loader .Probably also setuldr.sys will have to be modified. /Marc

2 1

Re: [ros-dev] [ros-diffs] [gbrunmar] 29929: Made each service have its own pipe name as done in Windows
by Aleksey Bragin 29 Oct '07

29 Oct '07

On Oct 28, 2007, at 5:13 PM, gbrunmar(a)svn.reactos.org wrote: > - DPRINT("CreateNamedPipeW() done\n"); > + DPRINT1("CreateNamedPipeW(%S) done\n", NtControlPipeName); Success reports should usually remain DPRINT, so that they don't pollute the debug log. WBR, Aleksey Bragin.

2 1

Re: [ros-dev] Moving some screensavers to rosapps
by Aleksey Bragin 28 Oct '07

28 Oct '07

Hi, "reactos" should have only bare minimum, so I agree about 1 gdi and 1 opengl. Other must be moved to rosapps. WBR, Aleksey Bragin. On Oct 28, 2007, at 2:32 AM, Colin Finck wrote: > Hello everyone, > > Now that we have 5 screensavers in trunk, and they are all in the > "reactos" > directory, it might be a good idea to move some of them to "rosapps". > The big question is now: Which ones shall be kept in "reactos" and > which > ones shall be moved to "rosapps"? > >> From the technical view, it's probably the best idea to keep one >> OpenGL and > one GDI screensaver in "reactos" (for example 3dtext and logon). > Please share your ideas about that. > > Regards, > > Colin

1 0

Moving some screensavers to rosapps
by Colin Finck 27 Oct '07

27 Oct '07

Hello everyone, Now that we have 5 screensavers in trunk, and they are all in the "reactos" directory, it might be a good idea to move some of them to "rosapps". The big question is now: Which ones shall be kept in "reactos" and which ones shall be moved to "rosapps"? >From the technical view, it's probably the best idea to keep one OpenGL and one GDI screensaver in "reactos" (for example 3dtext and logon). Please share your ideas about that. Regards, Colin

1 0

Re: [ros-dev] [ros-diffs] 29826 ...
by tamlin＠algonet.se 27 Oct '07

27 Oct '07

Alex Ionescu wrote: >>> 1) Why implement new, complex features in the kernel instead of >>> fixing current bugs? >> >> You pay, you get a saying in what I work on. I pay, I decide. > >No, this is an open source project, everyone gets a say on what you >work on -- you're free to ignore such sayings at your leisure. Seems I was too imprecise (or again a language barrier/misunderstanding). Sorry. My intention was to communicate that if you pay, you get the option of (trying to) tell me what to work on. When I pay, I decide. Obviously anyone is at any time free to comment. >The quota code is called by the process functions, and maybe even by >drivers, but it doesn't affect their behavior. I'm going out on a limb here (as I haven't checked it), but can't a JOB (artificially) limit available resources? That's part of their intention, isn't it? (please read on) >Two choices: > >1) Implement a rather complex quota implementation, including commit >charges in Mm (which is several thousand lines of code in NT), I knew I got into a rather large area, but this sounds insane for something as seemingly "simple". > to a fragile kernel If it's that fragile it needs to be fixed. If you got a better idea to do it than implementing previously missing functionality to expose those fragile parts of it, especially as what I started to work on apparently exposed those fragile parts, I'm all ears. > & > Use up a valuable developer's time, probably a couple man-weeks Should that be how I chose to spend my time - what's the difference if I hadn't been around at all? None, except the end result might make Win32 GlobalMemoryStatus and VM_COUNTERS present useful and usable data. > & > Add new bugs to a hot path during process/object creation/ >deletion (I hope you'll agree all new code has bugs) Only by convention, not by definition. :-) >OR > >2) Continue working on bug fixing the fragile parts of the kernel and >OS || Implement critical missing functionality for a target driver/ >application & This actually started as fixing critical missing functionality (Wax: feel free to chime in). Currently ROS does not COMMIT on such allocation requests. It happily allows an exe in a 128MB machine with 32MB pagefile to COMMIT almost 2GB memory. The error is of course in the way ROS handles COMMIT requests to VirtualAlloc, in that it defers committing the memory until something touches it... (that is no joke) The first step to research this was (for me) to see the behaviour of GlobalMemoryStatus, and indeed it was broken - it was unimplemented... So what do I do? I "dig where I stand". I start an attempt implementing the missing functionality. So the reason I came to touch Ps, and am digging way deeper in Mm than I'd really like to, is simply the GlobalMemoryStatus(Ex) Win32 API function(s), to even be able to verify, from user-mode, behaviour. [...] >> On a sidenote, the only public reference to PS_QUOTA_TYPE I could find >> were from a PDB file transcript from ntdll, posted at a french site. > >It should be added to the NDK. Agreed. But as I didn't know if that's still your baby (SVN access or not) and only synched at intervals, or if it has been "adopted", and if adding such data types, even if suspected to be correct, from such few and vague information source was even acceptable... I played it safe and used just the indices. Thanks for sharing the typename. If concensus is that adding that data type introduces no problems, even if from such a vague source, I'm in favor of adding it (as it'd solve more than one immediate problem). >>> 7) The quota routines require interlocks >> >> Yep. Even requires a lock for checking and updating QuotaPeak. > >No it doesn't, you can use Interlocked Compare Exchange. Are you thinking of the, semantically non-obvious for maintenance programmers, OldVal = Interlocked*Add(&Quota, Addend); InterlockedCompareExchange(&Peak, OldVal + Addend, OldVal + Addend); ? I think using a spinlock for that would make it much more obvious. Should profiling display it had a measurable impact on execution, sure. But we should also keep in mind we are then trading a single spinlock for two *locked* (bus-snooping/cache-invalidating) instructions. I don't know which is worse (performance wise). >>> 8) They also require a global spinlock in the "give back" case. >> >> I don't follow. Why? I'd imagine the "give back" case to be simpler >> than the charge case, as the former only needs to decrement the usage >> (InterlockedExchangeAdd with a negative value), while the latter needs >> to increment, followed by comparing with and possibly update Peak. > >The global spinlock is required when inserting new quota blocks, >dereferencing them, expanding the quota and giving back the quota. Ah, right... the quota blocks. As already displayed I didn't touch them (I honestly don't even know what they are for yet). I only looked at the (immediate) process quota entries. The linked lists I never touched. >I still disagree with trunk-is-a-playground I have never disagreed with that, so I'm not sure what you're referring to. >and I think that pseudo-code should go in branches, but you're free to disagree. I suggest you take that discussion with the project coordinator, that I cleared that diff with and he explicitly stated a preference for it even after I mentioned "branch". I disagree with you re. comments. I think pseudo-code in comments (in trunk even) is to prefer, as it can explain behaviours and intentions way better than plain english or even documentation. If those comments help maintenance-programmers ten or more years from now, even if only one single person, the comments were well spent time and place. -- Mike

1 0

Re: [ros-diffs] 29826 ...
by tamlin＠algonet.se 25 Oct '07

25 Oct '07

Alex Ionescu wrote: > 1) Why implement new, complex features in the kernel instead of > fixing current bugs? You pay, you get a saying in what I work on. I pay, I decide. > I had already written all these functions, but deleted them, Wasn't that a bonehead thing to do? > because nobody needed them, ... at the time. > and the Mm part was too complex to do. Guess what; I'm currently trying to actually implement it for Mm. Ps was a first step in that direction. Yes, Mm is complex, and yes I don't understand it enough yet - not by a longshot. But checking in incremental improvements, so that the code doesn't get lost, and disabled by default to not affect the behaviour of trunk - that's a good thing. It means people can both review and test the incremental changes, and perhaps even suggest improvements - like you did in pt. 5 below. > 2) Why are you bothering with PspPoolQuotaIndexFromPoolType? Ignorance of: > In case you haven't noticed, there's something called pool masks PAGED_POOL_MASK. Got it. > 5) Instead of duplicating code, perhaps consider calling a main > worker function such as PspChargeQuota? A sound refactoring suggestion. > 6) Consider using an enum instead of magic numbers inside the > quota entries, I believe it's called PS_QUOTA_TYPE. I just followed the lead of existing code. Had there been any mention of an enumeration for nonpaged, paged and pagefile, I would obviously have used those names. On a sidenote, the only public reference to PS_QUOTA_TYPE I could find were from a PDB file transcript from ntdll, posted at a french site. > 7) The quota routines require interlocks Yep. Even requires a lock for checking and updating QuotaPeak. > 8) They also require a global spinlock in the "give back" case. I don't follow. Why? I'd imagine the "give back" case to be simpler than the charge case, as the former only needs to decrement the usage (InterlockedExchangeAdd with a negative value), while the latter needs to increment, followed by comparing with and possibly update Peak. > 9) Committing code that won't even build, even with the define on, > isn't very appropriate. I agree. > If someone wants to actually test this, they won't be able to build it That's an interesting statement. Care to elaborate on how you reached such a factually wrong conclusion? > because of things like "refuse" Some people prefer pseudo-code over nothing at all. Some prefer void. Some people are able to spot C comment blocks. Some are not. Me, I checked that in with both the approval and a statement of preference for this kind of committs by the project coordinator. It not only compiles, it partially works too. > SVN should contain code that builds at any time. It's > not hard to write /* TODO */.. You really need (new?) glasses. You even quoted it yourself! "/* TODO: Check with Process->QuotaBlock if this can be satisfied, */" -- Mike

2 1

Re: [ros-diffs] 29702 ...
by tamlin＠algonet.se 25 Oct '07

25 Oct '07

Alex Ionescu wrote: > Windows uses the FILE_READ_DATA flag here, not FILE_READ_ATTRIBUTES. Yes? And? Let's study the code and the open modes used here. This code tries to open Device\HarddiskN\Partition0 (N = 0 ...) for the sole purpose of checking for availability, and immediately close the handle if the open succeeded. Why would one use FILE_READ_DATA if one never intended to read anything? The code also uses SYNCHRONIZE. Why would one use SYNCHRONIZE if one never intended to wait on the handle? As I see it, that's just requesting extra work for the purpose of nothing. The purpose of that open call is only to see if the disk exists, and if so create the symbolic link PhysicalDriveN -> HarddiskN\Partition0. I don't buy "Windows does this" without backing it up with any arguments whatsoever as to why Windows does this. Perhaps Windows does more with the returned handle than immediately closing it, something that actually requires READ_DATA? > all this is doing is hiding the bug (which is somewhere in vfat) I'm looking forward to the explanation of how opening HarddiskN\Partition0 (not "Partition1", not "Partition1\", but "Partition0" - aka the whole disk) would involve any filesystem activity whatsoever? > Because it's now gone, it'll probably happen in some mysterious > application 2 years from now and nobody will know why. Hahaha, you really are a joker. An app? Calling xHalIoAssignDriveLetters, that is called with a frickin' LoaderBlock? That function is used exactly once, during system startup. Health reasons suggest not holding your breath while waiting for such an application. :-) -- Mike

2 1

Re: [ros-dev] [ros-diffs] [mnordell] 29702: Don't try to open a harddisk for reading when checking for it to create the PhysicalDriveN links. Instead, request FILE_READ_ATTRIBUTES. This silences a hack-warning in IopParseDevice, that now possibly can be removed.
by Alex Ionescu 23 Oct '07

23 Oct '07

Windows uses the FILE_READ_DATA flag here, not FILE_READ_ATTRIBUTES. Silencing a warning does not mean fixing it -- all this is doing is hiding the bug (which is somewhere in vfat) in a place that's quite exposed. Because it's now gone, it'll probably happen in some mysterious application 2 years from now and nobody will know why. -- Best regards, Alex Ionescu On 20-Oct-07, at 3:36 AM, mnordell(a)svn.reactos.org wrote: > Author: mnordell > Date: Sat Oct 20 11:36:17 2007 > New Revision: 29702 > > URL: http://svn.reactos.org/svn/reactos?rev=29702&view=rev > Log: > Don't try to open a harddisk for reading when checking for it to > create the PhysicalDriveN links. Instead, request > FILE_READ_ATTRIBUTES. This silences a hack-warning in > IopParseDevice, that now possibly can be removed. > > Modified: > trunk/reactos/ntoskrnl/fstub/disksup.c > trunk/reactos/ntoskrnl/io/iomgr/file.c > > Modified: trunk/reactos/ntoskrnl/fstub/disksup.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ > fstub/disksup.c?rev=29702&r1=29701&r2=29702&view=diff > ====================================================================== > ======== > --- trunk/reactos/ntoskrnl/fstub/disksup.c (original) > +++ trunk/reactos/ntoskrnl/fstub/disksup.c Sat Oct 20 11:36:17 2007 > @@ -481,7 +481,7 @@ > NULL); > > Status = ZwOpenFile(&FileHandle, > - FILE_READ_DATA | SYNCHRONIZE, > + FILE_READ_ATTRIBUTES | SYNCHRONIZE, > &ObjectAttributes, > &StatusBlock, > FILE_SHARE_READ, > > Modified: trunk/reactos/ntoskrnl/io/iomgr/file.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/ > iomgr/file.c?rev=29702&r1=29701&r2=29702&view=diff > ====================================================================== > ======== > --- trunk/reactos/ntoskrnl/io/iomgr/file.c (original) > +++ trunk/reactos/ntoskrnl/io/iomgr/file.c Sat Oct 20 11:36:17 2007 > @@ -404,6 +404,9 @@ > > /* FIXME: Small hack still exists, have to check why... > * This is triggered multiple times by usetup and then once > per boot. > + * TMN: NOTE: It might have been fixed now, by changing the > requested > + * openmode in xHalIoAssignDriveLetters from FILE_READ_DATA to > + * FILE_READ_ATTRIBUTES. If verified, this hack should be > removed. > */ > if (!(DirectOpen) && > !(RemainingName->Length) && > >

1 0

Re: [ros-dev] [ros-diffs] [mnordell] 29826: First small attempt at implementing process memory quota. Currently disabled without explicit code modification (enabled by macro) to not modify behaviour of trunk.
by Alex Ionescu 23 Oct '07

23 Oct '07

Couple of comments: 1) Why implement new, complex features in the kernel instead of fixing current bugs? I know it's fun to start hacking on new code, but priorities should be to implement stuff that's required not to break other apps/add functionality, not internal features which will take ages to implement (the Ps functions for quota are "easy", it's the Mm part that's bad). I had already written all these functions, but deleted them, because nobody needed them, and the Mm part was too complex to do. 2) Why are you bothering with PspPoolQuotaIndexFromPoolType? In case you haven't noticed, there's something called pool masks which make the operation very easy without requiring a function call (such as POOL_TYPE_MASK or BASE_POOL_MASK, forgot how it's called). 3) INT is not an acceptable kernel type. 4) We don't use "static" in the kernel. 5) Instead of duplicating code, perhaps consider calling a main worker function such as PspChargeQuota? 6) Consider using an enum instead of magic numbers inside the quota entries, I believe it's called PS_QUOTA_TYPE. 7) The quota routines require interlocks, otherwise they will not be thread safe. 8) They also require a global spinlock in the "give back" case. 9) Committing code that won't even build, even with the define on, isn't very appropriate. Trunk isn't a playground. If someone wants to actually test this, they won't be able to build it because of things like "refuse". SVN should contain code that builds at any time. It's not hard to write /* TODO */.. Just my 2 cents -- Best regards, Alex Ionescu On 23-Oct-07, at 6:05 AM, mnordell(a)svn.reactos.org wrote: > Author: mnordell > Date: Tue Oct 23 14:05:40 2007 > New Revision: 29826 > > URL: http://svn.reactos.org/svn/reactos?rev=29826&view=rev > Log: > First small attempt at implementing process memory quota. Currently > disabled without explicit code modification (enabled by macro) to > not modify behaviour of trunk. > > Modified: > trunk/reactos/ntoskrnl/ps/quota.c > > Modified: trunk/reactos/ntoskrnl/ps/quota.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ps/ > quota.c?rev=29826&r1=29825&r2=29826&view=diff > ====================================================================== > ======== > --- trunk/reactos/ntoskrnl/ps/quota.c (original) > +++ trunk/reactos/ntoskrnl/ps/quota.c Tue Oct 23 14:05:40 2007 > @@ -15,6 +15,12 @@ > > EPROCESS_QUOTA_BLOCK PspDefaultQuotaBlock; > > + > +/* Define this macro to enable quota code testing. Once quota code > is */ > +/* stable and verified, remove this macro and checks for it. */ > +/*#define PS_QUOTA_ENABLE_QUOTA_CODE*/ > + > + > /* FUNCTIONS > ***************************************************************/ > > VOID > @@ -66,9 +72,29 @@ > { > /* Don't do anything for the system process */ > if (Process == PsInitialSystemProcess) return STATUS_SUCCESS; > - > + > +#ifdef PS_QUOTA_ENABLE_QUOTA_CODE > + if (Process) > + { > + /* TODO: Check with Process->QuotaBlock if this can be > satisfied, */ > + /* assuming this indeed is the place to check it. */ > + /* Probably something like: > + if (Process->QuotaUsage[2] + Amount > > + Process->QuotaBlock->QuotaEntry[2].Limit) > + { > + refuse > + } > + */ > + Process->QuotaUsage[2] += Amount; > + if (Process->QuotaPeak[2] < Process->QuotaUsage[2]) > + { > + Process->QuotaPeak[2] = Process->QuotaUsage[2]; > + } > + } > +#else > /* Otherwise, not implemented */ > UNIMPLEMENTED; > +#endif > return STATUS_SUCCESS; > } > > @@ -115,6 +141,38 @@ > return PsChargeProcessPoolQuota(Process, PagedPool, Amount); > } > > +#ifdef PS_QUOTA_ENABLE_QUOTA_CODE > +/* > + * Internal helper function. > + * Returns the index of the Quota* member in EPROCESS for > + * a specified pool type, or -1 on failure. > + */ > +static > +INT > +PspPoolQuotaIndexFromPoolType(POOL_TYPE PoolType) > +{ > + switch (PoolType) > + { > + case NonPagedPool: > + case NonPagedPoolMustSucceed: > + case NonPagedPoolCacheAligned: > + case NonPagedPoolCacheAlignedMustS: > + case NonPagedPoolSession: > + case NonPagedPoolMustSucceedSession: > + case NonPagedPoolCacheAlignedSession: > + case NonPagedPoolCacheAlignedMustSSession: > + return 1; > + case PagedPool: > + case PagedPoolCacheAligned: > + case PagedPoolSession: > + case PagedPoolCacheAlignedSession: > + return 0; > + default: > + return -1; > + } > +} > +#endif > + > /* > * @implemented > */ > @@ -124,10 +182,32 @@ > IN POOL_TYPE PoolType, > IN ULONG Amount) > { > + INT PoolIndex; > /* Don't do anything for the system process */ > if (Process == PsInitialSystemProcess) return STATUS_SUCCESS; > > - UNIMPLEMENTED; > +#ifdef PS_QUOTA_ENABLE_QUOTA_CODE > + PoolIndex = PspPoolQuotaIndexFromPoolType(PoolType); > + if (Process && PoolIndex != -1) > + { > + /* TODO: Check with Process->QuotaBlock if this can be > satisfied, */ > + /* assuming this indeed is the place to check it. */ > + /* Probably something like: > + if (Process->QuotaUsage[PoolIndex] + Amount > > + Process->QuotaBlock->QuotaEntry[PoolIndex].Limit) > + { > + refuse > + } > + */ > + Process->QuotaUsage[PoolIndex] += Amount; > + if (Process->QuotaPeak[PoolIndex] < Process->QuotaUsage > [PoolIndex]) > + { > + Process->QuotaPeak[PoolIndex] = Process->QuotaUsage > [PoolIndex]; > + } > + } > +#else > + UNIMPLEMENTED; > +#endif > return STATUS_SUCCESS; > } > > @@ -140,10 +220,26 @@ > IN POOL_TYPE PoolType, > IN ULONG_PTR Amount) > { > + INT PoolIndex; > /* Don't do anything for the system process */ > if (Process == PsInitialSystemProcess) return; > > - UNIMPLEMENTED; > +#ifdef PS_QUOTA_ENABLE_QUOTA_CODE > + PoolIndex = PspPoolQuotaIndexFromPoolType(PoolType); > + if (Process && PoolIndex != -1) > + { > + if (Process->QuotaUsage[PoolIndex] < Amount) > + { > + DPRINT1("WARNING: Process->QuotaUsage sanity check > failed.\n"); > + } > + else > + { > + Process->QuotaUsage[PoolIndex] -= Amount; > + } > + } > +#else > + UNIMPLEMENTED; > +#endif > } > > /* > @@ -157,7 +253,11 @@ > /* Don't do anything for the system process */ > if (Process == PsInitialSystemProcess) return; > > - UNIMPLEMENTED; > +#ifdef PS_QUOTA_ENABLE_QUOTA_CODE > + PsReturnPoolQuota(Process, NonPagedPool, Amount); > +#else > + UNIMPLEMENTED; > +#endif > } > > /* > @@ -171,7 +271,11 @@ > /* Don't do anything for the system process */ > if (Process == PsInitialSystemProcess) return; > > - UNIMPLEMENTED; > +#ifdef PS_QUOTA_ENABLE_QUOTA_CODE > + PsReturnPoolQuota(Process, PagedPool, Amount); > +#else > + UNIMPLEMENTED; > +#endif > } > > NTSTATUS > @@ -182,8 +286,22 @@ > /* Don't do anything for the system process */ > if (Process == PsInitialSystemProcess) return STATUS_SUCCESS; > > +#ifdef PS_QUOTA_ENABLE_QUOTA_CODE > + if (Process) > + { > + if (Process->QuotaUsage[2] < Amount) > + { > + DPRINT1("WARNING: Process PageFileQuotaUsage sanity > check failed.\n"); > + } > + else > + { > + Process->QuotaUsage[2] -= Amount; > + } > + } > +#else > /* Otherwise, not implemented */ > UNIMPLEMENTED; > +#endif > return STATUS_SUCCESS; > } > > >

1 0

[ros-diffs] [greatlrd] 29788: rename dc.h to win32kdc.h rename driver.h to win32kdriver.h
by James Tabor 22 Oct '07

22 Oct '07

Hi! Good job! But this is all kinds of type of wrong! There are internal calls for win32k dc.c and dcutils.c in there. What you should have done was move the DC object structure to ntgdihdl.h. So, please revert or but back dc.h and then move the DC object to ntgdihld.h where it belongs. Thanks, James

2 3

[RE:] ReactOS 0.3.4 Hardware Support
by James Tabor 22 Oct '07

22 Oct '07

Hi! What was the revision for the floppy driver that made it inoperative? You told me on IRC. I did not take my notes to work. > Hello, > > I think that 0.3.4 should have most hardware regressions (floppy and > vga) fixed. I know I'm not the one to say this but, we are already > closer to this goal than we were with 0.3.3. Fixing the floppy > regression should only involve finding the spot in which floppy is not > reporting correctly to ntoskrnl. I did some tests on this issue and it > fails on line 596-598 of ntoskrnl\io\iomgr\volume.c and floppy was never > mounted as the status reported was STATUS_IO_DEVICE_ERROR from line > 1017-1021 in drivers\storage\floppy\floppy.c. I don't know much about > the vga regression but I'd think that it may only require a few days > work to find and fix the issue. We already have SATA support included > with trunk (uniata.sys) and SCSI is also working now. > > -aicommander > Thanks, James

4 5

Re: [ros-dev] [ros-diffs] [fireball] 29714: Dmitry Chapyshev <lentind@yandex.ru> - Fully implement tapiui.dll, compatible with Windows. - Icons come from SUSE's yast2-industrial; 203,202.ico and 301,302.bmp are done by me based on Tango.
by Ged 21 Oct '07

21 Oct '07

These resources have been lifted straight out of the Windows dll. Absolutley no attempt has been made to change anything. IMO, this should be removed until someone manually implements it. Ged. fireball(a)svn.reactos.org wrote: > Author: fireball > Date: Sat Oct 20 21:16:30 2007 > New Revision: 29714 > > URL: http://svn.reactos.org/svn/reactos?rev=29714&view=rev > Log: > Dmitry Chapyshev <lentind(a)yandex.ru> > - Fully implement tapiui.dll, compatible with Windows. > - Icons come from SUSE's yast2-industrial; 203,202.ico and 301,302.bmp are done by me based on Tango > > >

1 0

ReactOS 0.3.4 Hardware Support
by Cam 20 Oct '07

20 Oct '07

Hello, I think that 0.3.4 should have most hardware regressions (floppy and vga) fixed. I know I'm not the one to say this but, we are already closer to this goal than we were with 0.3.3. Fixing the floppy regression should only involve finding the spot in which floppy is not reporting correctly to ntoskrnl. I did some tests on this issue and it fails on line 596-598 of ntoskrnl\io\iomgr\volume.c and floppy was never mounted as the status reported was STATUS_IO_DEVICE_ERROR from line 1017-1021 in drivers\storage\floppy\floppy.c. I don't know much about the vga regression but I'd think that it may only require a few days work to find and fix the issue. We already have SATA support included with trunk (uniata.sys) and SCSI is also working now. -aicommander

2 1

Porting ReactOS to the L4 micro-kernel
by Henning Schild 20 Oct '07

20 Oct '07

Hi there, i am thinking of porting ros to the L4 micro-kernel as topic for my diploma thesis. The operating systems group in Dresden already ported Linux to L4 (http://os.inf.tu-dresden.de/L4/LinuxOnL4/) and proofed that L4 offers all that is needed to run an operating system in userspace on top of it. The goal of the work would be to be able to run windows applications next to miro-kernel applications. And to compare the performance with that of pure ros, L4Linux/wine and windows. A comparison between the port and L4Linux could also be part of the work. (mapping processes to L4 tasks, memory management, interrupt-handling and so on) I am not very experienced in C or assembler programming but am motivated to learn. But before i start working on that topic i have some questions on the portability of ros. In svn and on the ros website i found that there is a ppc port of ros. And on irc someone told me that there is ongoing work on a ros usermode port. I also read about a xen port. But i did not yet find working copies of the any of that ports. I built ros for i386 on my machine and was able to boot it in vmware. I also tried building the latest svn version with ROS_ARCH=powerpc but that did not succeed. 1. Did anyone ever finish a port to another arch? 2. How portable is ros in general? Meaning how much code would have to be changed. I hope there are abstractions and only 10-15% of the kernel would have to be changed. 3. Do you believe that one person new to ros can finish that kind of work in 6 months? I know that might be hard to answer but how long did any of you need to learn ros in detail? 4. If there are working ports, how long did it take to implement them? If there are not, what are the reasons they where never finished? I am thinking of lots of assembler and i386 hacks. 5. Finally, what do think of the idea itself? I hope you take the time to answer my questions. I am still on the way to determine whether i really want to do that and whether i can do this in 6 months. regards, Henning Schild

11 13

[ros-diffs] [janderwald] 29678: Author: Evan Teran <evan.teran at gmail.com> - Fix typo in GlobalAlloc parameters.
by James Tabor 19 Oct '07

19 Oct '07

Hi! This + hargv=GlobalAlloc(0, size); should be + hargv=GlobalAlloc(GMEM_FIXED, size); No need to rush it! Fix it, in the next update. Thanks, James Ref: http://msdn2.microsoft.com/en-us/library/aa366574.aspx

1 0

Cannot compile, error with WRC
by carlo.bramix 19 Oct '07

19 Oct '07

Hello, after updating to r29681, I cannot compile ROS. The error is: [WRC] obj-i386\base\applications\cacls\cacls.coff output-i386\tools\wrc\wrc.exe: unknown option -- W output-i386\tools\wrc\wrc.exe: unknown option -- n output-i386\tools\wrc\wrc.exe: unknown option -- W output-i386\tools\wrc\wrc.exe: unknown option -- p Error: Too many output files. mingw32-make: *** [obj-i386\base\applications\cacls\cacls.coff] Error 2 Sincerely, Carlo Bramini

2 1

Re: [ros-dev] Targeting multiple Windows versions
by Aleksey Bragin 19 Oct '07

19 Oct '07

Hi Marc, the patch / bug IS valid, Magnus made a mistake and closed it. I wanted to do the same, but it's rather timeconsuming, so I appreciate you took the first steps. Still, some modules may require setting some specific version - that's allright, we can leave some exceptions for now, but otherwise, version number should be set globally, not in every .rbuild file (which is so wrong). WBR, Aleksey Bragin. On Oct 19, 2007, at 2:53 AM, Marc Piulachs wrote: > Hi, > > On the reactos frontpage I see that the project aims to reimplement > WindowsXP , that is NT 5.2 , but currently most of the modules > define their > own target version ranging from NT4 to NT 5.3 (2003) .On recent > shell32 > commits I have even seen someone introducing Vista-only APIs. > > I think an effort has to be done to fix that situation ,IMHO targeting > multiple windows versions is fine but not a mix of them so I > recently posted > a bug report on mozilla to have it present at least. > http://www.reactos.org/bugzilla/show_bug.cgi?id=2745 but It has > been marked > as invalid and I can't understand the reason given, I may be wrong > about > that but I'd like to know what I'm missing here, can anyone clarify? > > /Marc

1 0

Re: [ros-dev] [ros-diffs] [mnordell] 29653: Patch from aicommander. Actually copy uniata.sys from the installation media, and disable VGA resolution selection as VGA is broken.
by Aleksey Bragin 18 Oct '07

18 Oct '07

Shouldn't it be finally fixed, instead? I don't know who broke it. Was it Magnus with the "No PNP videocard" commit? WBR, Aleksey Bragin. On Oct 18, 2007, at 8:01 AM, mnordell(a)svn.reactos.org wrote: > Author: mnordell > Date: Thu Oct 18 08:01:53 2007 > New Revision: 29653 > > URL: http://svn.reactos.org/svn/reactos?rev=29653&view=rev > Log: > Patch from aicommander. Actually copy uniata.sys from the > installation media, and disable VGA resolution selection as VGA is > broken. > [Display] > ;<id> = <user friendly name>,<spare>,<service key > name>,<hight>,<width>,<bpp> > -vga = "VGA Display (640x480x4)",,Vga,640,480,4 > +;vga = "VGA Display (640x480x4)",,Vga,640,480,4

1 0

Re: [ros-dev] ReactOS on VirtualBox
by Mike Leahy 17 Oct '07

17 Oct '07

It's in the User FAQ - third-last question, at the end of the answer it says: "Other virtual machines/x86 emulators should be able to run ReactOS as well, and ReactOS is known to run in at least Bochs, VMWare, VirtualPC and QEMU. If you know of other virtual machines that support it, please send an e-mail to the ros-dev mailing list." I didn't see any mention of it in the recent archives of the mailing list, so I thought I'd mention it. Sorry if I misunderstood. Perhaps I'll try out the other emulation tools, though I've found VirtualBox in general to be very easy to use. Regards, Mike Zachary Gorden wrote: >First, which FAQ? > >Second, I'll talk with Colin about it. Some of the devs don't like >vbox, >but so long as we can get it to work, it's more or less up to the >release >engineers and Aleksey what vm images to release. > >Z98 >Release Engineer (secondary) >

1 0

ReactOS on VirtualBox
by Mike Leahy 17 Oct '07

17 Oct '07

Hello list, As recommended in the FAQ, I thought I'd mention that I gave ReactOS a try as a virtual machine using VirtualBox (http://www.virtualbox.org), and it seems to work okay. It wouldn't be too difficult to post a VirtualBox virtual disk image file, though it only took a couple minutes to setup from the installation CD image. I'd like to know if anyone else has given it a try though, as I had some stability problems (random freezes, etc.). I look forward to the future releases of ReactOS. Regards, Mike

2 1

Re: [ros-dev] [ros-diffs] [tkreuzer] 29617: If cmd was started from a shortcut, use the shortcut's name as window title, else use executable name, like on windows. Doesn't work on ros atm, due to bug 2743, but works on win XP. So if'ed out atm.
by Thomas Weidenmueller 16 Oct '07

16 Oct '07

This is a hack that shouldn't be there. This is csrss' responsibility. - Thomas tkreuzer(a)svn.reactos.org wrote: > Author: tkreuzer > Date: Tue Oct 16 02:23:42 2007 > New Revision: 29617 > > URL: http://svn.reactos.org/svn/reactos?rev=29617&view=rev > Log: > If cmd was started from a shortcut, use the shortcut's name as window title, else use executable name, like on windows. Doesn't work on ros atm, due to bug 2743, but works on win XP. So if'ed out atm. > > Modified: > trunk/reactos/base/shell/cmd/cmd.c > > Modified: trunk/reactos/base/shell/cmd/cmd.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/shell/cmd/cmd.c?rev=2… > ============================================================================== > --- trunk/reactos/base/shell/cmd/cmd.c (original) > +++ trunk/reactos/base/shell/cmd/cmd.c Tue Oct 16 02:23:42 2007 > @@ -1603,6 +1603,53 @@ > } > #endif > > +void > +InitTitle() > +{ > + STARTUPINFOW StartupInfo; > + LPWSTR lpFileName; > + WCHAR szTitle[MAX_PATH+1]; > + > + GetStartupInfoW(&StartupInfo); > + > + if (StartupInfo.lpTitle) > + { > + /* Are we started from a shortcut? */ > + if (StartupInfo.dwFlags & 0x800) > + { > + UINT len; > + > + /* We are started from a shortcut, use the file name only */ > + lpFileName = wcsrchr(StartupInfo.lpTitle, '\\'); > + if (lpFileName == NULL) > + { > + lpFileName = StartupInfo.lpTitle; > + } > + > + /* Drop file extension, we simply assume 3 chars extension */ > + len = wcslen(lpFileName) - 4; > + if (len > 0) > + { > + len = min(len, MAX_PATH); > + wcsncpy(szTitle, lpFileName, len); > + szTitle[len] = 0; > + SetConsoleTitleW(szTitle); > + return; > + } > + } > + > + /* Use lpTitle member of STARTUPINFO */ > + SetConsoleTitleW(StartupInfo.lpTitle); > + return; > + } > + > + /* Set executable path as window title */ > + GetModuleFileNameW(NULL, szTitle, MAX_PATH); > + SetConsoleTitleW(szTitle); > + return; > +} > + > + > /* > * set up global initializations and process parameters > * > @@ -1625,6 +1672,11 @@ > osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFO); > GetVersionEx (&osvi); > > + /* FIXME: Doesn't work in ros yet, because of missing functionality of ShellExecute. > + See bug 2743. Please unif as soon as it get's fixed. */ > +#if 0 > + InitTitle(); > +#endif > /* Some people like to run ReactOS cmd.exe on Win98, it helps in the > * build process. So don't link implicitly against ntdll.dll, load it > * dynamically instead */ > >

1 0

Doubts about the header changes in r29178
by Colin Finck 15 Oct '07

15 Oct '07

Hello, Hervé added some Standard C library headers to the "include/crt" directory in r29178. Now some people noticed that these changes broke building ReactOS components with MSVC using the ReactOS headers ("Debug - ReactOS headers" or "Release - ReactOS headers" configuration). I have some general doubts about these changes. >From my knowledge, the headers added in this commit, are compiler-specific and target-independent. You can easily see that they are specific to GCC/mingw as for example "stdio.h" includes a "_mingw.h" file with mingw-specific stuff. "stdarg.h" even leads to compilation problems with non-GCC-compilers (like MSVC), because it defines a type based on the __builtin_va_list type, and this built-in type only exists for GCC. In my opinion, this commit should be reverted. This way every compiler will use its own Standard C library headers and MSVC should be able to build ReactOS components using the ReactOS Win32 headers again. Regards, Colin

2 1

DC_ATTR with DCE
by James Tabor 13 Oct '07

13 Oct '07

Hi All! (subsystems\win32\win32k\ntuser\windc.c:156) FREE DCATTR!!!! NOT DCE_WINDOW_DC!!!!! hDC-> 6010078 (subsystems\win32\win32k\objects\dc.c:2549) DC_FreeDC DC_ATTR 0x2d80000 (subsystems\win32\win32k\ntuser\windc.c:551) ENTER!!!!!! DCX_CACHE!!!!!! hDC-> 6010078 (subsystems\win32\win32k\ntuser\windc.c:272) Exit!!!!! DCX_CACHE!!!!!! hDC-> 6010078 (subsystems\win32\win32k\objects\dc.c:2549) DC_FreeDC DC_ATTR 0x1020000 (subsystems\win32\win32k\ntuser\windc.c:156) FREE DCATTR!!!! NOT DCE_WINDOW_DC!!!!! hDC-> 14010092 (subsystems\win32\win32k\objects\dc.c:2549) DC_FreeDC DC_ATTR 0x1030000 (subsystems\win32\win32k\ntuser\windc.c:551) ENTER!!!!!! DCX_CACHE!!!!!! hDC-> 14010092 (subsystems\win32\win32k\ntuser\windc.c:272) Exit!!!!! DCX_CACHE!!!!!! hDC-> 14010092 (subsystems\win32\win32k\ntuser\windc.c:551) ENTER!!!!!! DCX_CACHE!!!!!! hDC-> 14010092 (subsystems\win32\win32k\ntuser\windc.c:272) Exit!!!!! DCX_CACHE!!!!!! hDC-> 14010092 Problem, Two Window DCE with DC objects are created and used through out the whole system and the ownership was passed to NULL for both DC objects. The dcattr, allocated and ownership belongs to the original process. So when testing the dcattr in user mode, creates user exception faults. DC object one: 6010078 and object two: 14010092. The Fix: First, I free the "non owned window (DCX_CACHE) DCE DC" dcattr before the DC is placed in "inaccessible mode" so the ownership of the dcattr is not lost. All traces of ownership comes from the DC handle information. Once it is set NULL it is lost. Second, I display the "Enter" (GetDCx) and "Exit" (ReleaseDC) for non owned window DCE DC. I'm doing this so I can trace it out. and,,,.... For DCX_CACHE DCE: ENTER "Get" allocate a new dcattr for the current process. EXIT "Release" free the dcattr for that process. Windows does something similar to this. Here is the patches,,, The test is: click on the time clock at the bottom right. Click on adjust time and date. There you go.... the Gdi patch allows access to the dcattr pen for the DCE DC now. It works,,,,, Thanks, James subsystems/win32/win32k: Index: ntuser/windc.c =================================================================== --- ntuser/windc.c (revision 29544) +++ ntuser/windc.c (working copy) @@ -153,6 +153,8 @@ } else { + DPRINT1("FREE DCATTR!!!! NOT DCE_WINDOW_DC!!!!! hDC-> %x\n", pDce->hDC); + DC_FreeDcAttr(pDce->hDC, NULL); // Free the dcattr! DC_SetOwnership(pDce->hDC, NULL); // This hDC is inaccessible! } @@ -267,6 +269,9 @@ dce->DCXFlags |= DCX_DCEEMPTY; } } + DPRINT1("Exit!!!!! DCX_CACHE!!!!!! hDC-> %x \n", dce->hDC); + DC_FreeDcAttr(dce->hDC, NULL); // Free the dcattr! + DC_SetOwnership(dce->hDC, NULL); } return 1; } @@ -543,6 +548,14 @@ DceUpdateVisRgn(Dce, Window, Flags); } + if (Dce->DCXFlags & DCX_CACHE) + { + DPRINT1("ENTER!!!!!! DCX_CACHE!!!!!! hDC-> %x\n", Dce->hDC); + DC_SetOwnership( Dce->hDC, PsGetCurrentProcess()); + DC_AllocateDcAttr( Dce->hDC, NULL); + DCU_SynchDcAttrtoUser( Dce->hDC, -1); // Copy data from dc to dcattr +// Dce->pProcess = PsGetCurrentProcess(); + } return(Dce->hDC); } dll/win32/gdi32: Index: dc.c =================================================================== --- dc.c (revision 29544) +++ dc.c (working copy) @@ -320,7 +320,7 @@ STDCALL GetDCObject( HDC hDC, INT iType) { -#if 0 +//#if 0 if((iType == GDI_OBJECT_TYPE_BRUSH) || (iType == GDI_OBJECT_TYPE_EXTPEN)|| (iType == GDI_OBJECT_TYPE_PEN) || @@ -348,7 +348,7 @@ } return hGO; } -#endif +//#endif return NtGdiGetDCObject( hDC, iType ); }

1 0

Re: [ros-dev] Porting ReactOS to the L4 micro-kernel
by Aleksey Bragin 10 Oct '07

10 Oct '07

Hi, what I can tell right away, is that it's a very interesting, suitable for diploma thesis work, but it's a challenge. You should posses general knowledge about operating systems development, and more specific knowledge about NT-based kernels, L4, and Linux. The only problem may be > I am not very experienced in C or assembler programming but am > motivated to learn. But before i start working on that topic i have but that could be compensated by outstanding OS dev skills / architecture knowledge. From the side of ReactOS Development Team, I'm sure you will have support in terms of either visiting the irc-channel #reactos on freenode or asking questions in this mailing list. WBR, Aleksey Bragin. On Oct 10, 2007, at 3:08 PM, Henning Schild wrote: > Hi there, > > i am thinking of porting ros to the L4 micro-kernel as topic for my > diploma thesis. The operating systems group in Dresden already ported > Linux to L4 (http://os.inf.tu-dresden.de/L4/LinuxOnL4/) and proofed > that L4 offers all that is needed to run an operating system in > userspace on top of it. > > The goal of the work would be to be able to run windows applications > next to miro-kernel applications. And to compare the performance with > that of pure ros, L4Linux/wine and windows. A comparison between the > port and L4Linux could also be part of the work. (mapping processes to > L4 tasks, memory management, interrupt-handling and so on) > > I am not very experienced in C or assembler programming but am > motivated to learn. But before i start working on that topic i have > some questions on the portability of ros. > > In svn and on the ros website i found that there is a ppc port of ros. > And on irc someone told me that there is ongoing work on a ros > usermode > port. I also read about a xen port. But i did not yet find working > copies of the any of that ports. I built ros for i386 on my > machine and was able to boot it in vmware. I also tried building the > latest svn version with ROS_ARCH=powerpc but that did not succeed. > > 1. Did anyone ever finish a port to another arch? > 2. How portable is ros in general? Meaning how much code would have to > be changed. I hope there are abstractions and only 10-15% of the > kernel > would have to be changed. > 3. Do you believe that one person new to ros can finish that kind of > work in 6 months? I know that might be hard to answer but how long did > any of you need to learn ros in detail? > 4. If there are working ports, how long did it take to implement > them? > If there are not, what are the reasons they where never finished? I am > thinking of lots of assembler and i386 hacks. > > 5. Finally, what do think of the idea itself? > > I hope you take the time to answer my questions. I am still on the way > to determine whether i really want to do that and whether i can do > this > in 6 months. > > regards, > Henning Schild

1 0

Re: [ros-dev] [Bug 2081] Format.exe can be run while reactos is active!
by James Tabor 10 Oct '07

10 Oct '07

Why was I added to this? Ask first! I can not do it all! B^| James ReactOS.Bugzilla(a)www.reactos.org wrote: > http://www.reactos.org/bugzilla/show_bug.cgi?id=2081 > > > amine48rz <amine48rz(a)gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > AssignedTo|ros-bugs(a)reactos.org |jimtabor@adsl-64-217-116- > | |74.dsl.hstntx.swbell.net > > > >

1 0

[Fwd: Re: [Bug 1172] VIA Rhine II net driver doesn't detect miniport]
by James Tabor 09 Oct '07

09 Oct '07

Hi! ReactOS.Bugzilla(a)www.reactos.org wrote: > http://www.reactos.org/bugzilla/show_bug.cgi?id=1172 > ------- Comment #16 From hpoussin 2007-10-08 10:44:44 CET ------- > > The device has been detected by PCI bus, and (as you didn't had any popup for > it), its driver has been found and probably installed. > I fixed a bug in driver installation in r29441, maybe it will help. > If it still doesn't work, can you enable debug output in > dll/win32/setupapi/devinst.c and dll/win32/netcfgx/netcfgx.c? > Okay! Will do! Since the bug report is closed, I guess we can work on the ML. I'll post my tests results. Thanks, James

1 0

Re: [ros-dev] [ros-diffs] [gbrunmar] 29384: Added context menu on right click in treeviews
by Ged 09 Oct '07

09 Oct '07

Have any attempts been made to submit these changes to Wine? local changes will just cause us grief further down the line. Ged. gbrunmar(a)svn.reactos.org wrote: > Author: gbrunmar > Date: Wed Oct 3 23:45:39 2007 > New Revision: 29384 > > URL: http://svn.reactos.org/svn/reactos?rev=29384&view=rev > Log: > Added context menu on right click in treeviews > > Modified: > trunk/reactos/dll/win32/comctl32/comctl32_ros.diff > trunk/reactos/dll/win32/comctl32/treeview.c > > Modified: trunk/reactos/dll/win32/comctl32/comctl32_ros.diff > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/comctl32/comctl3… > ============================================================================== > --- trunk/reactos/dll/win32/comctl32/comctl32_ros.diff (original) > +++ trunk/reactos/dll/win32/comctl32/comctl32_ros.diff Wed Oct 3 23:45:39 2007 > @@ -172,3 +172,26 @@ > if (infoPtr->cdmode & CDRF_NOTIFYPOSTPAINT) > infoPtr->cdmode = > TREEVIEW_SendCustomDrawNotify(infoPtr, CDDS_POSTPAINT, hdc, rect); > +@@ -4160,6 +4158,22 @@ > + static LRESULT > + TREEVIEW_RButtonUp(const TREEVIEW_INFO *infoPtr, const POINT *pPt) > + { > ++ TVHITTESTINFO ht; > ++ > ++ ht.pt = *pPt; > ++ > ++ TREEVIEW_HitTest(infoPtr, &ht); > ++ > ++ if (ht.hItem) > ++ { > ++ /* Change to screen coordinate for WM_CONTEXTMENU */ > ++ ClientToScreen(infoPtr->hwnd, &ht.pt); > ++ > ++ /* Send a WM_CONTEXTMENU message in response to the RBUTTONUP */ > ++ SendMessageW(infoPtr->hwnd, WM_CONTEXTMENU, > ++ (WPARAM)infoPtr->hwnd, MAKELPARAM(ht.pt.x, ht.pt.y)); > ++ } > ++ > + return 0; > + } > + > > Modified: trunk/reactos/dll/win32/comctl32/treeview.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/comctl32/treevie… > ============================================================================== > --- trunk/reactos/dll/win32/comctl32/treeview.c (original) > +++ trunk/reactos/dll/win32/comctl32/treeview.c Wed Oct 3 23:45:39 2007 > @@ -4158,6 +4158,22 @@ > static LRESULT > TREEVIEW_RButtonUp(const TREEVIEW_INFO *infoPtr, const POINT *pPt) > { > + TVHITTESTINFO ht; > + > + ht.pt = *pPt; > + > + TREEVIEW_HitTest(infoPtr, &ht); > + > + if (ht.hItem) > + { > + /* Change to screen coordinate for WM_CONTEXTMENU */ > + ClientToScreen(infoPtr->hwnd, &ht.pt); > + > + /* Send a WM_CONTEXTMENU message in response to the RBUTTONUP */ > + SendMessageW(infoPtr->hwnd, WM_CONTEXTMENU, > + (WPARAM)infoPtr->hwnd, MAKELPARAM(ht.pt.x, ht.pt.y)); > + } > + > return 0; > } > > > > >

7 9

Re: [ros-dev] [ros-diffs] [gedmurphy] 29469: add wine's wordpad asthe default
by Aleksey Bragin 09 Oct '07

09 Oct '07

Ok, that's good then, no need to delete it. But moving to rosapps may be a not bad idea (still including into the build). WBR, Aleksey Bragin. On Oct 9, 2007, at 3:50 PM, Ged wrote: > Aleksey Bragin wrote: >> Is there a reason to keep the wordpad we have? Is it better, >> worse, differences mergeable, etc? > > Our wordpad code is a great framework to build a much better, MDI > implementation of Wordpad. > > I added it in the hope that any potential 'would-be' developers > could use it > as a learning project into the world of Win32. As it is no one has > yet taken > it up, which is a bit of shame. > > It can be taken out of the build and even moved to ros-apps, but it > would be > a shame to delete it completley, as someone might one day take up the > challenge. > > Ged.

4 3

Re: [ros-dev] [ros-diffs] [gedmurphy] 29469: add wine's wordpad as the default
by Aleksey Bragin 09 Oct '07

09 Oct '07

Is there a reason to keep the wordpad we have? Is it better, worse, differences mergeable, etc? WBR, Aleksey Bragin. On Oct 9, 2007, at 1:00 PM, gedmurphy(a)svn.reactos.org wrote: > Author: gedmurphy > Date: Tue Oct 9 13:00:56 2007 > New Revision: 29469 > > URL: http://svn.reactos.org/svn/reactos?rev=29469&view=rev > Log: > add wine's wordpad as the default

2 1

Re: [ros-dev] Clean-room reversing
by Aleksey Bragin 09 Oct '07

09 Oct '07

Yes. Either reverse engineer and write docs (which can be used by ReactOS developers, provided they contain no source code derived from disassembly), or reverse engineer and write test cases. The latter method is [presumably] used by Wine developers, and it provides a very good legal ground. With the best regards, Aleksey Bragin. On Oct 9, 2007, at 5:12 AM, Josh H. wrote: > Is it okay to reverse through disassembly as long as clean room > methods > are used(only writeing docs, not implementing it yourself)? > > http://www.computerworld.com/softwaretopics/software/appdev/story/ > 0,10801,65532,00.html > http://en.wikipedia.org/wiki/Clean_room_design

1 0

Clean-room reversing
by Josh H. 09 Oct '07

09 Oct '07

Is it okay to reverse through disassembly as long as clean room methods are used(only writeing docs, not implementing it yourself)? http://www.computerworld.com/softwaretopics/software/appdev/story/0,10801,6… http://en.wikipedia.org/wiki/Clean_room_design -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

1 0

Re: [ros-dev] rbuild problems/suggestions
by Marc Piulachs 08 Oct '07

08 Oct '07

Anyone wants to comment on this? _____ From: Marc Piulachs [mailto:marc.piulachs@codexchange.net] Sent: Saturday, October 06, 2007 10:24 PM To: 'ros-dev(a)reactos.org' Subject: rbuild problems/suggestions Having worked with rbuild for a few weeks I have identified some problems that would like to share. I also would like to hear the developers' opinions about all of these issues because I want to start working to solving them. A) The behavior of the "include" + "directory" tags are inconsistent when an "include" is placed inside a "directory" for example: Correct: (expected : ke/i386/boot.S) <directory name="ke"> <if property="ARCH" value="i386"> <directory name="i386"> <file first="true">boot.S</file> Incorrect: (expected : reactos/reactos.rbuild real : reactos/reactos/reactos.rbuild) <directory name="reactos"> <xi:include href="reactos/reactos.rbuild" /> </directory> should be: <directory name="reactos"> <xi:include href="reactos.rbuild" /> </directory> B) The "oldcrt" attribute is no longer used and can be removed. C) The module types "Iso" , "LiveIso" , "IsoRegTest" and "LiveIsoRegTest" are IMHO hacks introduced to be able use the makefile generation code. rbuild is C++ so with a small code refactor they can be easly removed. D) Any module is using the "EmbeddedTypeLib" module type , is really needed or can be removed? E) IMHO the "ElfExecutable" is incorrect . I posted my reasons some time ago: http://www.reactos.org/archives/public/ros-dev/2007-September/009770.html http://www.reactos.org/archives/public/ros-dev/2007-September/009771.html http://www.reactos.org/archives/public/ros-dev/2007-September/009779.html F) The module type "alias" is only used for HAL related modules and IMHO it isn't requiered because the problem it tries to solve can be easly solved using "if" tags and conditional compilation. http://www.reactos.org/archives/public/ros-dev/2007-September/009798.html There are several reasons for this change: - Currently every platform requires 3 new HAL modules. In the future if new platforms are supported for example (X86 , XBOX , PPC , AMD64 , MIPS , IA64 , ARM ... ) 3 x 7 = 21 modules .. see what I'm saying? - It simplifies backends work. No need to include logic for alias handling. - Conceptually wrong . every module represents a particular functionality when you compile the module it should just reconfigure itself to produce the appropriate image for the configured architecture .It a good idea to have a true componentized operating system. Regarding the ModuleType IMHO they should be used to provide information that describes the module output/target not the build process! Iso , LiveIso , Alias , ... all of them are meaningless they are not true metadata. Long term enhancements: X) tags like "linkerflag" or "compilerflag" are gcc/mingw specific and should be replaced with other tags that provide the equivalent functionality using a more abstract aproach so other backends/compilers could benefit from it. rbuild files should only describe the source code and the compilation process without including specific information. /Marc

2 2

Re: [ros-dev] Bugzilla error when sending notifications
by carlo.bramix 08 Oct '07

08 Oct '07

Hello, I got this error too... and I made a little disaster. I got that message when writing into bug #2711. I cleaned the off-line cache, I posted my message again, I got success but the message has been posted twice, because the previous message had been accepted despite the error screen. Sorry... Carlo Bramini >I'm getting the same error since some time. > >But for me, it only occurs when hpoussin at reactos.org is >subscribed to the >bug report (by being the bug reporter or by being on the CC >list). Sending >notifications to other E-Mail addresses seems to work fine. >Also only the E-Mail notification part is affected by this >problem, the >other changes will be saved successfully. >Using Deskzilla with such bug reports also leads to the same >problem. > >Regards, > >Colin > > >> --- Original Message --- > From: ros-dev-bounces at reactos.org [mailto:ros-dev-bounces at reactos.org] On Behalf Of Marc Piulachs >> Sent: Tuesday, October 02, 2007 5:11 PM >> To: ros-dev at reactos.org >> Subject: [ros-dev] Bugzilla error when sending notifications >> >> I'm getting this error when posting/modifying a bugreport >> >> Bugzilla has suffered an internal error. Please save this page and send it to aleksey at reactos.org with details of what you were doing at the time this message appeared. >> >> URL: http://www.reactos.org/bugzilla/process_bug.cgi >> >> There was an error sending mail from 'ReactOS.Bugzilla' to 'hpoussin at reactos.org':error when closing pipe to /usr/lib/sendmail: ------------------------------------------------------ Leggi GRATIS le tue mail con il telefonino i-mode di Wind http://i-mode.wind.it/

1 0

Techwiki start
by Timo Kreuzer 07 Oct '07

07 Oct '07

I have started a techwiki inside our wiki. It can be found at http://www.reactos.org/wiki/index.php/Techwiki/main Currently only some stuff for win32k/gdi. Please add any info about nt functionality / links / tools you'd like to share there. I still think it would be a good idea to move it into it's own wiki, so our wiki doesn't get even more messed up ;-) Timo

1 0

Re: [ros-dev] [ros-diffs] [hpoussin] 29433: ntdll.dll is a native dll
by Alex Ionescu 07 Oct '07

07 Oct '07

Nope, it's not :) On 10/7/07, hpoussin(a)svn.reactos.org <hpoussin(a)svn.reactos.org> wrote: > > Author: hpoussin > Date: Sun Oct 7 16:14:02 2007 > New Revision: 29433 > > URL: http://svn.reactos.org/svn/reactos?rev=29433&view=rev > Log: > ntdll.dll is a native dll > > Modified: > trunk/reactos/dll/ntdll/ntdll.rbuild > > Modified: trunk/reactos/dll/ntdll/ntdll.rbuild > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/ntdll/ntdll.rbuild?rev… > > ============================================================================== > --- trunk/reactos/dll/ntdll/ntdll.rbuild (original) > +++ trunk/reactos/dll/ntdll/ntdll.rbuild Sun Oct 7 16:14:02 2007 > @@ -1,6 +1,6 @@ > <?xml version="1.0"?> > <!DOCTYPE module SYSTEM "../../tools/rbuild/project.dtd"> > -<module name="ntdll" type="win32dll" entrypoint="0" > baseaddress="${BASEADDRESS_NTDLL}" installbase="system32" installname=" > ntdll.dll"> > +<module name="ntdll" type="nativedll" entrypoint="0" > baseaddress="${BASEADDRESS_NTDLL}" installbase="system32" installname=" > ntdll.dll"> > <bootstrap installbase="$(CDOUTPUT)/system32" /> > <importlibrary definition="def/ntdll.def" /> > <include base="ntdll">inc</include> > > > -- Best regards, Alex Ionescu

1 0

rbuild problems/suggestions
by Marc Piulachs 06 Oct '07

06 Oct '07

Having worked with rbuild for a few weeks I have identified some problems that would like to share. I also would like to hear the developers' opinions about all of these issues because I want to start working to solving them. A) The behavior of the "include" + "directory" tags are inconsistent when an "include" is placed inside a "directory" for example: Correct: (expected : ke/i386/boot.S) <directory name="ke"> <if property="ARCH" value="i386"> <directory name="i386"> <file first="true">boot.S</file> Incorrect: (expected : reactos/reactos.rbuild real : reactos/reactos/reactos.rbuild) <directory name="reactos"> <xi:include href="reactos/reactos.rbuild" /> </directory> should be: <directory name="reactos"> <xi:include href="reactos.rbuild" /> </directory> B) The "oldcrt" attribute is no longer used and can be removed. C) The module types "Iso" , "LiveIso" , "IsoRegTest" and "LiveIsoRegTest" are IMHO hacks introduced to be able use the makefile generation code. rbuild is C++ so with a small code refactor they can be easly removed. D) Any module is using the "EmbeddedTypeLib" module type , is really needed or can be removed? E) IMHO the "ElfExecutable" is incorrect . I posted my reasons some time ago: http://www.reactos.org/archives/public/ros-dev/2007-September/009770.html http://www.reactos.org/archives/public/ros-dev/2007-September/009771.html http://www.reactos.org/archives/public/ros-dev/2007-September/009779.html F) The module type "alias" is only used for HAL related modules and IMHO it isn't requiered because the problem it tries to solve can be easly solved using "if" tags and conditional compilation. http://www.reactos.org/archives/public/ros-dev/2007-September/009798.html There are several reasons for this change: - Currently every platform requires 3 new HAL modules. In the future if new platforms are supported for example (X86 , XBOX , PPC , AMD64 , MIPS , IA64 , ARM ... ) 3 x 7 = 21 modules .. see what I'm saying? - It simplifies backends work. No need to include logic for alias handling. - Conceptually wrong . every module represents a particular functionality when you compile the module it should just reconfigure itself to produce the appropriate image for the configured architecture .It a good idea to have a true componentized operating system. Regarding the ModuleType IMHO they should be used to provide information that describes the module output/target not the build process! Iso , LiveIso , Alias , ... all of them are meaningless they are not true metadata. Long term enhancements: X) tags like "linkerflag" or "compilerflag" are gcc/mingw specific and should be replaced with other tags that provide the equivalent functionality using a more abstract aproach so other backends/compilers could benefit from it. rbuild files should only describe the source code and the compilation process without including specific information. /Marc

1 0

Re: [ros-dev] [ros-diffs] [hpoussin] 29378: Add back windres, it is still used after wrc invocation
by Steven Edwards 03 Oct '07

03 Oct '07

speaking of resources, Alexandre is now allowing binary resources in winehq git as it actually handles them in a sane way as opposed to cvs. This means you guys can drop bin2res if your using it anywhere and keeping shell32 resources in sync with Wine will be less of a diff now. Thanks Steven On 10/3/07, hpoussin(a)svn.reactos.org <hpoussin(a)svn.reactos.org> wrote: > Author: hpoussin > Date: Wed Oct 3 18:17:46 2007 > New Revision: 29378 > > URL: http://svn.reactos.org/svn/reactos?rev=29378&view=rev > Log: > Add back windres, it is still used after wrc invocation > > Modified: > trunk/reactos/Makefile > > Modified: trunk/reactos/Makefile > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/Makefile?rev=29378&r1=2937… > ============================================================================== > --- trunk/reactos/Makefile (original) > +++ trunk/reactos/Makefile Wed Oct 3 18:17:46 2007 > @@ -298,6 +298,7 @@ > objcopy = $(Q)$(PREFIX_)objcopy > dlltool = $(Q)$(PREFIX_)dlltool > strip = $(Q)$(PREFIX_)strip > +windres = $(Q)$(PREFIX_)windres > > # Set utilities > ifeq ($(OSTYPE),msys) > > > -- 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

1 0

ReactOS Development Process
by Aleksey Bragin 03 Oct '07

03 Oct '07

Hello, recently, different people raised a question: How should development process evolve with time, when ReactOS has more (much more) developers willing to contribute code? There are many possibilities, however all of them assume more or less an overhead, and need additional human resources. I will outline one suggested method, and want you (developers) to "constructively criticize it", improve it, or offer a better method. Even if it involves changing current version control system, or anything - suggest the method. So, the suggestion I've already got is this: Trunk is writable only by a so-called Integrator person (maybe a few persons). Branches are writable by a big amount of developers. Typical development process is as follows: 1. A developer creates a ticket in issue-tracking system (currently Bugzilla), where he describes what's wrong and what his change fixes/ improves. 2. He creates a branch with a name BZ-XYZ (where XYZ is ticket's number), and commits his changes there. 3. An integrator, daily, goes through all BZ-... branches, does svn merge to trunk of each branch, test it, if no regression occurs, he commits changes to trunk and svn deletes the respective BZ-... branch. Some kind of integration system is definitely needed, so please avoid fast answers like "Let's stay as we do now". Better approach is needed, and I'm looking for it. If you can offer something - do so. With the best regards, Aleksey Bragin.

3 2

Re: [ros-dev] ReactOS Development Process
by Aleksey Bragin 03 Oct '07

03 Oct '07

I considered that, but it's a bad idea. Try to remember what the hell it was to merge changes into release branch ("stable"), done since 0.3.3-RC1 was released? And that was only to do a RC2, about 1-2 weeks, and complete hell to merge so it was decided that a rebranch was easier (and in fact it worked very well). WBR, Aleksey Bragin. On Oct 3, 2007, at 9:03 PM, Magnus Olsen wrote: > Hi > I think we should have something call stable trunk and devloping trunk > > The stable trunk getting all changes that are ready and stable and > it will > be > the release version of trunk. > > the devloping trunk is where everyone working in > > > But the main problem is we do not have any good tools for regress > testing > and we are missing testcase for each api. I am working at moment > writing > testcase for gdi32, I hope this will make lest gdi32 allot more > stable at > end > then I will start making testcase for win32k later maybe for user32 > then start fixing the real bugs and implement things. or working with > everthing same times. we should need a test kit for each api and > test for evertging invaild param, pointers, and real data in all case > I known it is not fun todo but that is what we need to make ReactOS > more stable and less bugs. Testcase for everthing.

1 0

Re: [ros-dev] ReactOS Development Process
by Aleksey Bragin 03 Oct '07

03 Oct '07

Herve suggests using a kind of a continuous integration system, describing it this way: * precommit hook if commit not to trunk, abort precommit hook create a REV-abc branch from trunk and do the commit here * regularly go through all REV-abc branches (increasing ABC numbers) test it if not, inform user or whatever that test failed and go to next branch try to merge to trunk if not, inform user or whatever that merge failed and go to next branch commit to trunk delete the branch go to next branch * pros: devs and users will have new version to trunk once they are tested devs and users only have to know trunk * cons: changes are not immediatly available for everyone, except in REV-abc branch On Oct 3, 2007, at 12:50 PM, Aleksey Bragin wrote: > Hello, > recently, different people raised a question: How should development > process evolve with time, when ReactOS has more (much more) > developers willing to contribute code?

5 4

Bugzilla error when sending notifications
by Marc Piulachs 02 Oct '07

02 Oct '07

I'm getting this error when posting/modifying a bugreport Bugzilla has suffered an internal error. Please save this page and send it to aleksey(a)reactos.org with details of what you were doing at the time this message appeared. URL: http://www.reactos.org/bugzilla/process_bug.cgi There was an error sending mail from 'ReactOS.Bugzilla' to 'hpoussin(a)reactos.org':error when closing pipe to /usr/lib/sendmail:

2 1

Re: [ros-dev] [ros-diffs] [hpoussin] 29352: Do not hardcode cdrom directory
by Pablo Menichini 02 Oct '07

02 Oct '07

> --- trunk/reactos/base/setup/usetup/drivesup.c (original) > +++ trunk/reactos/base/setup/usetup/drivesup.c Tue Oct 2 16:16:45 2007 > @@ -35,7 +35,8 @@ ... > + if (Ptr) > + RtlCreateUnicodeString(SourceRootDir, Ptr); > + else > + RtlCreateUnicodeString(SourceRootDir, L""); > + > if (Ptr != NULL) > - *Ptr = 0; > - > + *Ptr = 0; You can put *Ptr = 0 in the if-else Pablo

1 0

SmartPDF (aka SumatraPDF) in rosapps, linking problems
by Klemens Friedl 02 Oct '07

02 Oct '07

SumatraPDF is a lightweight Win32 pdf viewer app http://blog.kowalczyk.info/software/sumatrapdf/ http://code.google.com/p/sumatrapdf/ The name "sumatra" sounds weird (for an app), so I renamed the directory and the output exe file to "SmartPDF" (based on suggestions from #reactos). SumatraPDF comes with VS 2k5 project files. I have fixed various compile issues so that libjpeg, poppler, fitz/mupdf and sumatra app itself compile without errors in mingw (RosBE 0.3.7.2 Win32). All code changes can be found by grep/search for "@note:", I added a comment to each changed code line. The remaining problem is the linking issue. Currently it does NOT link correctly. Timo Kreuzer mentioned on 2007-09-27 in #reactos something that may be related to the issue: "it [sumatrapdf] imports a function from winspool.drv by number, when you add that number to winspool.def, it starts" Please have a look at it, fixes are appreciated :) Klemens

4 9

Kernel streaming header mess / GUIDs
by reactos-development＠silverblade.co.uk 30 Sep '07

30 Sep '07

Hi, Alex nudged me in IRC about this, but sadly I've not quite figured this out yet. It appears my definitions for Kernel Streaming GUIDs are not quite right. This results in ugly code like so: -- const GUID foo_audio_category = STATIC_KSCATEGORY_AUDIO; DoSomethingWithTheGuid(&foo_audio_category); -- Which consequently results in a barrage of compiler complaints about brace initialization. It should be possible to just do: DoSomethingWithTheGuid(KSCATEGORY_AUDIO); I'm clearly going wrong somewhere in KS.H or KSMEDIA.H but to be honest am blind to whatever is causing the problem. If anyone can figure out what I'm doing wrong here, I'd appreciate it. Thanks. -Andrew

5 4

Re: [ros-dev] [ros-diffs] [fireball] 28351: Dmitry Chapyshev <lentind@yandex.ru>: - Fix so that letters like "p" or "y" are correctly displayed in messageboxes.
by Ged 29 Sep '07

29 Sep '07

IMO, this change is wrong, it's a hack to a problem we have with text placement. Text is cut short on other controls too, not just messageboxes. Check out labels for example. Ged. fireball(a)svn.reactos.org wrote: > Author: fireball > Date: Wed Aug 15 18:49:44 2007 > New Revision: 28351 > > URL: http://svn.reactos.org/svn/reactos?rev=28351&view=rev > Log: > Dmitry Chapyshev <lentind(a)yandex.ru>: > - Fix so that letters like "p" or "y" are correctly displayed in messageboxes. > > Modified: > trunk/reactos/dll/win32/user32/windows/messagebox.c > > Modified: trunk/reactos/dll/win32/user32/windows/messagebox.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/user32/windows/m… > ============================================================================== > --- trunk/reactos/dll/win32/user32/windows/messagebox.c (original) > +++ trunk/reactos/dll/win32/user32/windows/messagebox.c Wed Aug 15 18:49:44 2007 > @@ -491,7 +491,7 @@ > txtrect.right = GetSystemMetrics(SM_CXSCREEN) / 5 * 4; > if(Icon) > txtrect.right -= GetSystemMetrics(SM_CXICON) + MSGBOXEX_SPACING; > - txtrect.top = txtrect.left = txtrect.bottom = 0; > + txtrect.top = txtrect.left = txtrect.bottom = 5; > SelectObject(hDC, hFont); > if (textlen != 0) > { > > > >

7 6

Note for devs about translations
by Heis Spiter 29 Sep '07

29 Sep '07

Hello, I'd just like to do a remark about ReactOS apps, dlls, which be translated. When a dev change something to the interface, or the core app, it could be great to update EVERY language file (*.rc) and not only some of them (or even worse : only english one). It does not take many times to do (I know because I've already done that), and for a translator that's quite easier to see what has changed without having to compare his language file and the english one. And most of all, it avoids uncomplete, or outdated language files. Finally, for end-user, that's better : that's even better to have English string instead of nothing (I mean blank string). Thanks, Pierre Schweitzer, French Language Maintainer

1 0

Re: [ros-dev] Audit
by Aleksey Bragin 24 Sep '07

24 Sep '07

On Sep 22, 2007, at 10:19 PM, João Jerónimo wrote: > The point of a possible 3rd party audit is raising the legal > credibility of > the ReactOS project by ensuring that no tainted code is left in the > source > tree, right? The word "tainted" is actually quite wrong, and is being misused everywhere. A tea was tainted by polonium in a not-so-recent accident in the UK. ReactOS is not a tea, and we have no "polonium" commiters. There will be a WineConf event in 1 or 2 weeks, and they say they are going to clear up the legal situation around Wine, around SFLC audit and around requirements to the developers, whose code may be commited to the tree. When they do it, I would be very glad to know those requirements, and enforce them on ReactOS developers, so that we are on the common ground. > > Well, if the project is going to wait until more modules stabilize, > won't > this stabilization process obfuscate most of the tainted source > code, and > make them hard to find? Your mind is ahead of you. "Taint obfuscated code", "Obfuscate tainted code", ... Your question is obfuscated and may be tainted, I won't answer it. WBR, Aleksey Bragin.

9 19

Re: [ros-dev] Audit
by Aleksey Bragin 24 Sep '07

24 Sep '07

Please stop rumouring this topic. I clearly said "if there are strong circumstances, in future, only then we will think about doing 3rd party audit, and only from agreement of all devs". That's 3 or 4 years away from now, if such legal problems ever happen. Also noone ever said SFLC is taking up copyrights to themselves. At least it's first time I hear this. I just grepped Wine source code base for word "SFLC" - doesn't appear anywhere. Also, open up any of Wine's source code file, you'll see "Copyright 200x Person's Name". And again, I didn't suggest SFLC or FSF or whoever. Time will show who and if we need, and who and if agrees to. WBR, Aleksey Bragin. On Sep 24, 2007, at 2:58 PM, Magnus Olsen wrote: > It seam u fall into he SFLC traps they are trying push doing the > audlt of > ros from a 3 part project > of ros, and we shall obay theirs rules it mean all api that is not > document > in msdn shall be remove > and so on. That mean 80% of ntoskrnl will go away, for around 80% of > ntoskrnl are not in msdn > 80% of win32k will go aways, for thuse api are not in msdn, then > shall we > not talk about audio > no audio system and so on. > > that mean no ros, if we play after SLFC and we need also write > papper give > up our copyright to > them. no thanks

1 0

Re: [ros-dev] Audit
by Aleksey Bragin 23 Sep '07

23 Sep '07

Well-well, please calm down, we had enough flamewars, a new one is not necessary. No decisions are made, and no decisions are going to be made without agreement with all our developers. WBR, Aleksey Bragin. On Sep 23, 2007, at 3:40 PM, Ged wrote: > James Tabor wrote: >> >> Wine is the Pot calling the kettle BLACK! Bunch of RE coders using >> smoke and >> mirrors when it comes to case testing! It's a easy out! >> > > I agree with Aleksey, we must adopt their way of working in the > hope of > rebuilding the bridges and additionally improving our credability > within > the open source world. If this means offering ourselves to an external > audit, then so be it. We can't be a hobbiest project forever if we aim > to bring ReactOS to the public sector as a viable alternative to > Windows. > > > Ged.

1 0

Re: [ros-dev] Open Sound System porting
by reactos-development＠silverblade.co.uk 23 Sep '07

23 Sep '07

Thanks for all the replies so far. I find it quite insane that MSDN compares ioctl to DeviceIoControl. Whilst they achieve the same results, the actual parameters used etc. are entirely different. I'm not sure if Steven's suggestion would work (ie, use ws2_32) since, to my knowledge, that particular implementation is specific to sockets. Probably the best way around this then, would be to make an ioctl wrapper that takes the OSS-specific IOCTL codes, and translates them into custom NT IOCTL codes. The wrapper would take things like structures being passed via the ioctl and send them via DeviceIoControl instead. It does seem like a fair amount of work but if an appropriate "wrapper" is created, it could work... Original Message: ----------------- From: King InuYasha ngompa13(a)gmail.com Date: Sat, 22 Sep 2007 10:28:50 -0500 To: ros-dev(a)reactos.org Subject: Re: [ros-dev] Open Sound System porting Couldn't the source be patched to use DeviceIOControl instead of ioctl? According to MSDN about porting from UNIX to Win32, ioctl maps directly to DeviceIOControl, so it could be possible to simply change all the instances of ioctl to DeviceIOControl... On 9/22/07, Aleksey Bragin <aleksey(a)reactos.org> wrote: > > I didn't thoroughly look through the OSS source code, but if it has > some kind of platform-independent design in mind, then I would really > recommend porting, and porting with as minimal changes to the > original source code required (you probably are going to need a > wrapper-library, for ioctls at least, plus NT-specific parts). > > I may help too, because of the usb stack wrapping I did a while ago. > > > WBR, > Aleksey Bragin. > > > > > I've been in touch with the guy that ported OSS to Haiku (open- > > source BeOS) > > after some > > discussion with the folks over at #winehackers to get some help > > with audio > > development. > > > > Anyway, basically the idea so far is to use OSS as a "fall-back" audio > > driver > > implementation. So unless there is a "better" driver installed (ie an > > official one for > > an audio device), ReactOS can use an Open Sound System driver instead. > > > > The result? There will at least be sound functionality. > > > > OSS is designed to be mostly platform-independent. By rewriting a > > few of > > the core > > modules, the entire set of drivers will be able to work with whatever > > platform you > > desire. > > > > This can be implemented on top of the existing MME API architecture > > for the > > moment, and > > can later be translated to use the WDM audio framework. > > > > Anyway, having stuck the OSS code into my local ReactOS source > > tree, I'm > > trying to > > figure out how to get it to compile using rbuild. The first hurdle > > I have > > come across is > > that there is extensive use of ioctl. Indeed it seems that most > > ports of > > OSS work on > > platforms based on Posix (Unix?) > > > > So my main question at this time is how to handle this? The calls in > > question appear to > > be documented inside a file called "soundcard.h" in the OSS sources > > however > > this just > > seems to be definitions for the ioctl codes. So I suspect a > > majority of the > > drivers are > > calling ioctl. > > > > Therefore, I figure the best way around this is probably to provide > > a fake > > ioctl that > > provides the expected functionality, and make this wrap > > DeviceIoControl > > with something > > that can translate the ioctl parameters into whatever... > > > > The only other way I see around this is to rewrite all calls to > > ioctl, and > > rewrite the > > IOCTL codes with NT-style ones. > > > > Thoughts/ideas? > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > -------------------------------------------------------------------- mail2web.com What can On Demand Business Solutions do for you? http://link.mail2web.com/Business/SharePoint

3 2

Re: [ros-dev] Open Sound System porting
by reactos-development＠silverblade.co.uk 22 Sep '07

22 Sep '07

4Front. Apparently it's "better". Original Message: ----------------- From: King InuYasha ngompa13(a)gmail.com Date: Sat, 22 Sep 2007 16:32:11 -0500 To: reactos-development(a)silverblade.co.uk, ros-dev(a)reactos.org Subject: Re: [ros-dev] Open Sound System porting Which OSS implementation are you looking at? The OSS/Free one, or the OSS one from 4Front? On 9/22/07, reactos-development(a)silverblade.co.uk < reactos-development(a)silverblade.co.uk> wrote: > > Thanks for all the replies so far. > > I find it quite insane that MSDN compares ioctl to DeviceIoControl. Whilst > they achieve > the same results, the actual parameters used etc. are entirely different. > > I'm not sure if Steven's suggestion would work (ie, use ws2_32) since, to > my knowledge, > that particular implementation is specific to sockets. > > Probably the best way around this then, would be to make an ioctl wrapper > that takes the > OSS-specific IOCTL codes, and translates them into custom NT IOCTL codes. > The wrapper > would take things like structures being passed via the ioctl and send them > via > DeviceIoControl instead. > > It does seem like a fair amount of work but if an appropriate "wrapper" is > created, it > could work... > > > Original Message: > ----------------- > From: King InuYasha ngompa13(a)gmail.com > Date: Sat, 22 Sep 2007 10:28:50 -0500 > To: ros-dev(a)reactos.org > Subject: Re: [ros-dev] Open Sound System porting > > > Couldn't the source be patched to use DeviceIOControl instead of ioctl? > According to MSDN about porting from UNIX to Win32, ioctl maps directly to > DeviceIOControl, so it could be possible to simply change all the > instances > of ioctl to DeviceIOControl... > > On 9/22/07, Aleksey Bragin <aleksey(a)reactos.org> wrote: > > > > I didn't thoroughly look through the OSS source code, but if it has > > some kind of platform-independent design in mind, then I would really > > recommend porting, and porting with as minimal changes to the > > original source code required (you probably are going to need a > > wrapper-library, for ioctls at least, plus NT-specific parts). > > > > I may help too, because of the usb stack wrapping I did a while ago. > > > > > > WBR, > > Aleksey Bragin. > > > > > > > > I've been in touch with the guy that ported OSS to Haiku (open- > > > source BeOS) > > > after some > > > discussion with the folks over at #winehackers to get some help > > > with audio > > > development. > > > > > > Anyway, basically the idea so far is to use OSS as a "fall-back" audio > > > driver > > > implementation. So unless there is a "better" driver installed (ie an > > > official one for > > > an audio device), ReactOS can use an Open Sound System driver instead. > > > > > > The result? There will at least be sound functionality. > > > > > > OSS is designed to be mostly platform-independent. By rewriting a > > > few of > > > the core > > > modules, the entire set of drivers will be able to work with whatever > > > platform you > > > desire. > > > > > > This can be implemented on top of the existing MME API architecture > > > for the > > > moment, and > > > can later be translated to use the WDM audio framework. > > > > > > Anyway, having stuck the OSS code into my local ReactOS source > > > tree, I'm > > > trying to > > > figure out how to get it to compile using rbuild. The first hurdle > > > I have > > > come across is > > > that there is extensive use of ioctl. Indeed it seems that most > > > ports of > > > OSS work on > > > platforms based on Posix (Unix?) > > > > > > So my main question at this time is how to handle this? The calls in > > > question appear to > > > be documented inside a file called "soundcard.h" in the OSS sources > > > however > > > this just > > > seems to be definitions for the ioctl codes. So I suspect a > > > majority of the > > > drivers are > > > calling ioctl. > > > > > > Therefore, I figure the best way around this is probably to provide > > > a fake > > > ioctl that > > > provides the expected functionality, and make this wrap > > > DeviceIoControl > > > with something > > > that can translate the ioctl parameters into whatever... > > > > > > The only other way I see around this is to rewrite all calls to > > > ioctl, and > > > rewrite the > > > IOCTL codes with NT-style ones. > > > > > > Thoughts/ideas? > > _______________________________________________ > > Ros-dev mailing list > > Ros-dev(a)reactos.org > > http://www.reactos.org/mailman/listinfo/ros-dev > > > > > -------------------------------------------------------------------- > mail2web.com What can On Demand Business Solutions do for you? > http://link.mail2web.com/Business/SharePoint > > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > -------------------------------------------------------------------- mail2web - Check your email from the web at http://link.mail2web.com/mail2web

2 1

Audit
by Aleksey Bragin 22 Sep '07

22 Sep '07

Hello, I recently asked Klemens to remove audit progress bar from the frontpage. Some wonder: why? The simple answer is obvious: Audit doesn't have anything to do with end-users, testers, or patch- submitters of the project. Audit is an effort run by ReactOS Development Team, and has only one goal: Reduce possible legal problems in future, when, and if, ReactOS starts to have commercial appliances. The process with file locking-unlocking is only the top of the iceberg, there is a huge amount of work to be done in order to maintain solid legal base for all our code. It can't be measured with a single progressbar, nor it needs to. It can't be done only with the help of ReactOS Development Team, a third party code reviewer is a must. We plan that too, but for later time, when there are more stable modules in ReactOS. Legal base consists of a number of factors: authorship and sources of the code and their legality, availability of documentation for certain interfaces and algorithms, development of test cases showing internal behaviour of certain API functions, licensing issues, 3rd party code reviewing process results, etc, etc, etc. I think it's rather clear to see that measuring all the above factors in a single percentage number can't sound serious for a project, nor can it be a real value of cleannes of the project. The respective Audit wikipage needs to be updated too WRT this email. Also please note, our audit process results are fully seen via SVN commits, so there is no hiding involved. With the best regards, Aleksey Bragin.

2 1

Re: [ros-dev] Open Sound System porting
by Aleksey Bragin 22 Sep '07

22 Sep '07

I didn't thoroughly look through the OSS source code, but if it has some kind of platform-independent design in mind, then I would really recommend porting, and porting with as minimal changes to the original source code required (you probably are going to need a wrapper-library, for ioctls at least, plus NT-specific parts). I may help too, because of the usb stack wrapping I did a while ago. WBR, Aleksey Bragin. > > I've been in touch with the guy that ported OSS to Haiku (open- > source BeOS) > after some > discussion with the folks over at #winehackers to get some help > with audio > development. > > Anyway, basically the idea so far is to use OSS as a "fall-back" audio > driver > implementation. So unless there is a "better" driver installed (ie an > official one for > an audio device), ReactOS can use an Open Sound System driver instead. > > The result? There will at least be sound functionality. > > OSS is designed to be mostly platform-independent. By rewriting a > few of > the core > modules, the entire set of drivers will be able to work with whatever > platform you > desire. > > This can be implemented on top of the existing MME API architecture > for the > moment, and > can later be translated to use the WDM audio framework. > > Anyway, having stuck the OSS code into my local ReactOS source > tree, I'm > trying to > figure out how to get it to compile using rbuild. The first hurdle > I have > come across is > that there is extensive use of ioctl. Indeed it seems that most > ports of > OSS work on > platforms based on Posix (Unix?) > > So my main question at this time is how to handle this? The calls in > question appear to > be documented inside a file called "soundcard.h" in the OSS sources > however > this just > seems to be definitions for the ioctl codes. So I suspect a > majority of the > drivers are > calling ioctl. > > Therefore, I figure the best way around this is probably to provide > a fake > ioctl that > provides the expected functionality, and make this wrap > DeviceIoControl > with something > that can translate the ioctl parameters into whatever... > > The only other way I see around this is to rewrite all calls to > ioctl, and > rewrite the > IOCTL codes with NT-style ones. > > Thoughts/ideas?

2 1

Re: [ros-dev] rbuild and HALs module optimization
by Aleksey Bragin 22 Sep '07

22 Sep '07

David, what does a kernel-dev have to do with rbuild? Also, recent massive commits to the rbuild itself, and to various .rbuild files hardly prove your "rbuild is an umaintained piece of ... stuff" theory. It's, by the least measure, offensive to Herve's (and there were a few different patches submitted by various authors submitted) work he's been doing with rbuild. Or what is a "maintained rbuild", by your definition? How more should it be maintained? Note: not improved (we have a number of improvements pending to be implemented in it), but *maintained*. Another thing is completely wrong and counter-productive: irc is a wrong place for such question, since not all devs are there all the time. Now, back to the actual question. The biggest difference between ntoskrnl and HAL is that the first is as machine-independent as possible (still including some dependent code, but it's conditionally included), while the latter is actually very hardware dependent, so it does not make sense to unite x86 and PowerPC HALs, because they are going to contain just simply different source code. With the best regards, Aleksey Bragin. On Sep 21, 2007, at 8:11 PM, David Hinz wrote: > > Marc Piulachs schrieb: >> Does anyone agree with me on this? Maybe I’m missing something >> here but >> I would like to improve it. > > I don't think you will have much luck getting an answer, as afaik > rbuild > is currently more or less unmaintained and our kernel-dev left the > project. > > Maybe arty or hpoussin do have an oppinion regarding your question, > but > they seem to be rather busy most of the time... > > Have you tried asking on irc? Most devs hang out there... > > Greets, > > David Hinz

3 2

Open Sound System porting
by reactos-development＠silverblade.co.uk 22 Sep '07

22 Sep '07

Hi guys, I've been in touch with the guy that ported OSS to Haiku (open-source BeOS) after some discussion with the folks over at #winehackers to get some help with audio development. Anyway, basically the idea so far is to use OSS as a "fall-back" audio driver implementation. So unless there is a "better" driver installed (ie an official one for an audio device), ReactOS can use an Open Sound System driver instead. The result? There will at least be sound functionality. OSS is designed to be mostly platform-independent. By rewriting a few of the core modules, the entire set of drivers will be able to work with whatever platform you desire. This can be implemented on top of the existing MME API architecture for the moment, and can later be translated to use the WDM audio framework. Anyway, having stuck the OSS code into my local ReactOS source tree, I'm trying to figure out how to get it to compile using rbuild. The first hurdle I have come across is that there is extensive use of ioctl. Indeed it seems that most ports of OSS work on platforms based on Posix (Unix?) So my main question at this time is how to handle this? The calls in question appear to be documented inside a file called "soundcard.h" in the OSS sources however this just seems to be definitions for the ioctl codes. So I suspect a majority of the drivers are calling ioctl. Therefore, I figure the best way around this is probably to provide a fake ioctl that provides the expected functionality, and make this wrap DeviceIoControl with something that can translate the ioctl parameters into whatever... The only other way I see around this is to rewrite all calls to ioctl, and rewrite the IOCTL codes with NT-style ones. Thoughts/ideas? -------------------------------------------------------------------- mail2web.com - Microsoft® Exchange solutions from a leading provider - http://link.mail2web.com/Business/Exchange

5 5

Documentation
by Colin Finck 21 Sep '07

21 Sep '07

Hello, Recently, some developers wrote documentation about certain stuff related to ReactOS. But this documentation was only placed on their own web servers. In my opinion, it would be better if such stuff would (also) be committed to the "documentation" directory in SVN. Having documentation there makes sure that it does not get lost. Additionally, if the source file is committed (not a PDF or something like that), another person could extend the documentation further. I agree that not all documentary stuff needs to be on SVN. An example might be Magnus' Win32k syscall tables. But for example Andrew Greenwood's documentation about the Windows Multimedia Subsystems looks like something, which should be committed in my opinion. If you don't agree on committing this stuff, it would be nice if we could at least agree on an official document format, which should be used in the SVN tree. >From what I see, most documentations were created by using OpenOffice, so I think the OpenDocument Text format (ODT) would be a great choice. It is also supported by most word processors, thus most people should be able to open an ODT file. Up to now, I used RTF for formatted text documentations in SVN, but this format does not support things like shapes. Regards, Colin

7 16

Re: [ros-dev] Bugzilla's bug assigning process
by Aleksey Bragin 21 Sep '07

21 Sep '07

There is a list linked from that wikipage, which has a simple 1:1 relationship between developer and some development area. If it's wrong, please edit it. WBR, Aleksey Bragin. On Sep 21, 2007, at 3:04 AM, Ged wrote: > Aleksey Bragin wrote: >> If there are any questions, please post them right away here. >> > > How are these bugs being assigned? > I've been watching and most of the bugs which have been assigned have > been assigned to the wrong developer. > > Ged.

2 2

rbuild and HALs module optimization
by Marc Piulachs 21 Sep '07

21 Sep '07

If we don't have a ntoskrnl rbuild module for every supported architecture I don't understand why we do have a separate HAL rbuild module for every architecture (X86 , PowePC) and sub architecture (x86-Generic , x86-xbox , PowerPC-Generic) Currently we have a very complicated logic to compile the appropriate HAL with conditions (IF) and alias that point to the correct module for the target architecture. At the end always two dlls are going to be generated for every architecture hal_up and hal_mp so what's the reason to have a specific module for every architecture and not two generic modules that represent the two possible HAL modes (uniprocessor and multiprocessor) that dynamically include the appropriate source code for the platform (Architecture + Sub Architecture) being build? For example : <module name="hal_generic" > (common code to all architectures, sub architectures , UP and MP HALs) </module> <module name="hal_up" installname="halup.dll"> <library>hal_generic</library> <library>.. (common files to all UP HALs) <if property="ARCH" value="i386"> (X86 common files to all X86 UP HALs) <if property="OARCH" value="xbox"> (xbox specific files) </if> </if> </if propery="ARCH" value="powerpc"> (PPC common files) </if> </module> And the same for multiprocessor <module name="hal_mp" installname="halmp.dll" /> both files can be simply copied to the install cd and usetup will install the correct HAL renamed as hal.dll depending on the user selection. IMHO it greatly simplifies the process and is a more elegant solution than the current one.

2 2

Bugzilla's bug assigning process
by Aleksey Bragin 20 Sep '07

20 Sep '07

Hello, as you may already noticed Amine started his work as a bugzilla maintainer today, and some people were surprised by bugs being assigned to them. Amine does a preliminary bugs assignment, according to developers' work history in ReactOS. You are free to reassign to another dev, or reasign back to Ros-bugs(a)reactos.org if you don't want to fix that bug. Also, it's very important that you put your valid email address to the bugzilla account, so that it works correctly and emails you when needed. If there are any questions, please post them right away here. With the best regards, Aleksey Bragin.

2 1

Re: [ros-dev] Documentation
by Aleksey Bragin 20 Sep '07

20 Sep '07

Not a problem, but this should be done on a standalone machine, preferably the server at Christoph's place, or I can utilize my own machine for this too. WBR, Aleksey Bragin. On Sep 20, 2007, at 6:00 PM, Ged wrote: > Timo Kreuzer wrote: >> So we should think about updating our >> doxygen and probably keeping it at a quite up to date state (only >> a few >> days old if possible). > > I fully agree. > Aleksey, is there any reason this can't be stuck in a cron job and run > weekly? > Doxygen is a great tool which we can't really make much use of at the > moment. > > Ged.

1 0

29102 - Fix an old rbuild bug: .gch file now depends of intermediate module directory, and can create it if needed
by Timo Kreuzer 20 Sep '07

20 Sep '07

Revision: 29102 Autor: hpoussin Datum: 11:34:05, Mittwoch, 19. September 2007 Meldung: Fix an old rbuild bug: .gch file now depends of intermediate module directory, and can create it if needed ---- Verändert : /trunk/reactos/tools/rbuild/backend/mingw/modulehandler.cpp Does this fix bug 2369? http://www.reactos.org/bugzilla/show_bug.cgi?id=2369

1 0

Re: [ros-dev] Problems with resources or something else
by carlo.bramix 19 Sep '07

19 Sep '07

Hello, I saw the bug #2225. In my opinion the bug isn't into the CopyImage() but into DrawIconEx() instead. I checked the copyico test app and after debugging a little I discovered that CopyImage() received an already corrupted pixel map. But probably, this fact is known to you too. Sincerely, Carlo Bramini. ---------- Initial Header ----------- >From : ros-dev-bounces(a)reactos.org To : "ReactOS Development List" ros-dev(a)reactos.org Cc : Date : Fri, 14 Sep 2007 21:14:55 +0200 Subject : Re: [ros-dev] Problems with resources or something else > Hi, > > This problem has nothing to do with resource compilation. > It's a bug in our CopyImage function, which exists since some time. If you > try the current builds from our BuildBot, you will have the same problem. > > Regards, > > Colin > > > > -----Original Message----- > > From: ros-dev-bounces(a)reactos.org > > [mailto:ros-dev-bounces@reactos.org] On Behalf Of carlo.bramix > > Sent: Thursday, September 13, 2007 10:22 AM > > To: ros-dev > > Subject: [ros-dev] Problems with resources or something else > > > > Hello, > > it's long time that I compile ReactOS and I have some errors > > into the start menu bar. > > My results are almost identical to this screenshot: > > > > http://www.reactos.org/media/screenshots/2007/ros_033_xara3d.jpg > > > > As you can see, the two icons after the start button and the > > '1','2','3','4' buttons are corrupted. > > Actually I'm using the windres.exe that I received from here: > > > > http://www.reactos.org/archives/public/ros-dev/2007-July/009548.html > > > > Do you have some idea? > > > > Sincerely, > > > > Carlo Bramini > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ------------------------------------------------------ Leggi GRATIS le tue mail con il telefonino i-mode di Wind http://i-mode.wind.it/

2 1

Bugzilla maintainer
by Aleksey Bragin 19 Sep '07

19 Sep '07

Hello, Amine Khaldi is going to be a bugzilla maintainer, starting tomorrow. This is the first step from the a number of efforts I'm going to announce soon, which aim significant improving of the development process, resulting in less breakages and more smooth development progress. You can see what the work of a bugzilla maintainer is at the following wikipage: http://www.reactos.org/wiki/index.php/ Bugzilla_Maintainer With the best regards, Aleksey Bragin.

1 0

ReactOS status
by Carlos Alexandre Pires 18 Sep '07

18 Sep '07

Hi, my name is Carlos Pires, and i've been tracking this project since 2006, and now I've managed to get some time for me to get involved in it. I've fetched the svn sources, and past this last 3 days looking at the code, trying to find how was going the implementention. I've also download tinykrnl for analsys, and realized that reactOS does not implement some hal fuctions like HaliQuerySystemInformation, trying to find more information one this i've also realize that reactOS does not have a Machine Check Handler. I noticed that a lot of effort is being made in User Mode code, to make software work in reactOS. I've also check svn activity and checked that the Kernel Mode code had minor changes (i've only looked at dates). Now, i've said that, i have a few questions: - How is the Kernel Mode implemention current status? - Looking at Windows architecture, the HAL part is one of the most important thing in making Windows device drivers work in reactOS, shouldn't this be ReactOS first goal? - Isn't more important to create a fully working Kernel (executive,hal,etc) before going into User Mode? Sorry if i've said something that is not correct, this are only thoughts i've had, while i was looking at the code. I'm a developer and want to help as much as i can this project, so if anyone can help in getting some lights about the current status, i appreciate. The best regards

1 0

Re: [ros-dev] [ros-diffs] [silverblade] 29089: Bare-bones foundations of the ReactOS Audio Service. At present it's nothing more than a "mutex service". Some info on the planned implementation is in the included audiosrv.txt file.
by Alex Ionescu 18 Sep '07

18 Sep '07

If the mutex is a named mutex and the object existed before this function call, the return value is a handle to the existing object, GetLastError returns ERROR_ALREADY_EXISTS -- Best regards, Alex Ionescu On 17-Sep-07, at 10:41 PM, silverblade(a)svn.reactos.org wrote: + device_list_mutex = CreateMutex(NULL, FALSE, DEVICE_LIST_MUTEX_NAME); + + if ( ! device_list_mutex) + {

1 0

Problems with resources or something else
by carlo.bramix 16 Sep '07

16 Sep '07

Hello, it's long time that I compile ReactOS and I have some errors into the start menu bar. My results are almost identical to this screenshot: http://www.reactos.org/media/screenshots/2007/ros_033_xara3d.jpg As you can see, the two icons after the start button and the '1','2','3','4' buttons are corrupted. Actually I'm using the windres.exe that I received from here: http://www.reactos.org/archives/public/ros-dev/2007-July/009548.html Do you have some idea? Sincerely, Carlo Bramini ------------------------------------------------------ Leggi GRATIS le tue mail con il telefonino i-mode di Wind http://i-mode.wind.it/

4 4

Linking problems
by Marc Piulachs 15 Sep '07

15 Sep '07

Does the order of .o files matter when linking against a static library? I ask this because I'm having problems linking ntoskrnl with rtl dependending on the order of object files when compiling rtl. For example on the rbuild generated makefile.auto the order of .o files is : rtl_OBJS := \ $(INTERMEDIATE)\lib\rtl\austin\avl.o \ $(INTERMEDIATE)\lib\rtl\austin\tree.o \ $(INTERMEDIATE)\lib\rtl\access.o \ $(INTERMEDIATE)\lib\rtl\acl.o \ $(INTERMEDIATE)\lib\rtl\atom.o \ $(INTERMEDIATE)\lib\rtl\bitmap.o \ $(INTERMEDIATE)\lib\rtl\bootdata.o \ $(INTERMEDIATE)\lib\rtl\compress.o \ $(INTERMEDIATE)\lib\rtl\condvar.o \ $(INTERMEDIATE)\lib\rtl\crc32.o \ $(INTERMEDIATE)\lib\rtl\critical.o \ $(INTERMEDIATE)\lib\rtl\dbgbuffer.o \ $(INTERMEDIATE)\lib\rtl\debug.o \ $(INTERMEDIATE)\lib\rtl\dos8dot3.o \ $(INTERMEDIATE)\lib\rtl\encode.o \ $(INTERMEDIATE)\lib\rtl\env.o \ $(INTERMEDIATE)\lib\rtl\error.o \ $(INTERMEDIATE)\lib\rtl\exception.o \ $(INTERMEDIATE)\lib\rtl\generictable.o \ $(INTERMEDIATE)\lib\rtl\handle.o \ $(INTERMEDIATE)\lib\rtl\heap.o \ $(INTERMEDIATE)\lib\rtl\image.o \ $(INTERMEDIATE)\lib\rtl\message.o \ $(INTERMEDIATE)\lib\rtl\largeint.o \ $(INTERMEDIATE)\lib\rtl\luid.o \ $(INTERMEDIATE)\lib\rtl\network.o \ $(INTERMEDIATE)\lib\rtl\nls.o \ $(INTERMEDIATE)\lib\rtl\path.o \ $(INTERMEDIATE)\lib\rtl\ppb.o \ $(INTERMEDIATE)\lib\rtl\process.o \ $(INTERMEDIATE)\lib\rtl\propvar.o \ $(INTERMEDIATE)\lib\rtl\qsort.o \ $(INTERMEDIATE)\lib\rtl\random.o \ $(INTERMEDIATE)\lib\rtl\rangelist.o \ $(INTERMEDIATE)\lib\rtl\registry.o \ $(INTERMEDIATE)\lib\rtl\res.o \ $(INTERMEDIATE)\lib\rtl\resource.o \ $(INTERMEDIATE)\lib\rtl\sd.o \ $(INTERMEDIATE)\lib\rtl\security.o \ $(INTERMEDIATE)\lib\rtl\sid.o \ $(INTERMEDIATE)\lib\rtl\sprintf.o \ $(INTERMEDIATE)\lib\rtl\srw.o \ $(INTERMEDIATE)\lib\rtl\swprintf.o \ $(INTERMEDIATE)\lib\rtl\splaytree.o \ $(INTERMEDIATE)\lib\rtl\thread.o \ $(INTERMEDIATE)\lib\rtl\time.o \ $(INTERMEDIATE)\lib\rtl\timezone.o \ $(INTERMEDIATE)\lib\rtl\timerqueue.o \ $(INTERMEDIATE)\lib\rtl\unicode.o \ $(INTERMEDIATE)\lib\rtl\unicodeprefix.o \ $(INTERMEDIATE)\lib\rtl\vectoreh.o \ $(INTERMEDIATE)\lib\rtl\version.o \ $(INTERMEDIATE)\lib\rtl\workitem.o \ $(INTERMEDIATE)\lib\rtl\i386\debug_asm.o \ $(INTERMEDIATE)\lib\rtl\i386\except_asm.o \ $(INTERMEDIATE)\lib\rtl\i386\except.o \ $(INTERMEDIATE)\lib\rtl\i386\random_asm.o \ $(INTERMEDIATE)\lib\rtl\i386\rtlswap.o \ $(INTERMEDIATE)\lib\rtl\i386\rtlmem.o \ $(INTERMEDIATE)\lib\rtl\i386\res_asm.o \ $(INTERMEDIATE)\lib\rtl\i386\thread.o \ Using this order rtl will compile and ntoskrnl can be linked without problems but If the order is changed to ASMs on top (the order present in rtl.rbuild): rtl_OBJS := \ $(INTERMEDIATE)\lib\rtl\i386\debug_asm.o \ $(INTERMEDIATE)\lib\rtl\i386\except_asm.o \ $(INTERMEDIATE)\lib\rtl\i386\except.o \ $(INTERMEDIATE)\lib\rtl\i386\random_asm.o \ $(INTERMEDIATE)\lib\rtl\i386\rtlswap.o \ $(INTERMEDIATE)\lib\rtl\i386\rtlmem.o \ $(INTERMEDIATE)\lib\rtl\i386\res_asm.o \ $(INTERMEDIATE)\lib\rtl\i386\thread.o \ $(INTERMEDIATE)\lib\rtl\austin\avl.o \ $(INTERMEDIATE)\lib\rtl\austin\tree.o \ $(INTERMEDIATE)\lib\rtl\access.o \ $(INTERMEDIATE)\lib\rtl\acl.o \ $(INTERMEDIATE)\lib\rtl\atom.o \ $(INTERMEDIATE)\lib\rtl\bitmap.o \ $(INTERMEDIATE)\lib\rtl\bootdata.o \ $(INTERMEDIATE)\lib\rtl\compress.o \ $(INTERMEDIATE)\lib\rtl\condvar.o \ $(INTERMEDIATE)\lib\rtl\crc32.o \ $(INTERMEDIATE)\lib\rtl\critical.o \ $(INTERMEDIATE)\lib\rtl\dbgbuffer.o \ $(INTERMEDIATE)\lib\rtl\debug.o \ $(INTERMEDIATE)\lib\rtl\dos8dot3.o \ $(INTERMEDIATE)\lib\rtl\encode.o \ $(INTERMEDIATE)\lib\rtl\env.o \ $(INTERMEDIATE)\lib\rtl\error.o \ $(INTERMEDIATE)\lib\rtl\exception.o \ $(INTERMEDIATE)\lib\rtl\generictable.o \ $(INTERMEDIATE)\lib\rtl\handle.o \ $(INTERMEDIATE)\lib\rtl\heap.o \ $(INTERMEDIATE)\lib\rtl\image.o \ $(INTERMEDIATE)\lib\rtl\message.o \ $(INTERMEDIATE)\lib\rtl\largeint.o \ $(INTERMEDIATE)\lib\rtl\luid.o \ $(INTERMEDIATE)\lib\rtl\network.o \ $(INTERMEDIATE)\lib\rtl\nls.o \ $(INTERMEDIATE)\lib\rtl\path.o \ $(INTERMEDIATE)\lib\rtl\ppb.o \ $(INTERMEDIATE)\lib\rtl\process.o \ $(INTERMEDIATE)\lib\rtl\propvar.o \ $(INTERMEDIATE)\lib\rtl\qsort.o \ $(INTERMEDIATE)\lib\rtl\random.o \ $(INTERMEDIATE)\lib\rtl\rangelist.o \ $(INTERMEDIATE)\lib\rtl\registry.o \ $(INTERMEDIATE)\lib\rtl\res.o \ $(INTERMEDIATE)\lib\rtl\resource.o \ $(INTERMEDIATE)\lib\rtl\sd.o \ $(INTERMEDIATE)\lib\rtl\security.o \ $(INTERMEDIATE)\lib\rtl\sid.o \ $(INTERMEDIATE)\lib\rtl\sprintf.o \ $(INTERMEDIATE)\lib\rtl\srw.o \ $(INTERMEDIATE)\lib\rtl\swprintf.o \ $(INTERMEDIATE)\lib\rtl\splaytree.o \ $(INTERMEDIATE)\lib\rtl\thread.o \ $(INTERMEDIATE)\lib\rtl\time.o \ $(INTERMEDIATE)\lib\rtl\timezone.o \ $(INTERMEDIATE)\lib\rtl\timerqueue.o \ $(INTERMEDIATE)\lib\rtl\unicode.o \ $(INTERMEDIATE)\lib\rtl\unicodeprefix.o \ $(INTERMEDIATE)\lib\rtl\vectoreh.o \ $(INTERMEDIATE)\lib\rtl\version.o \ $(INTERMEDIATE)\lib\rtl\workitem.o \ [LD] C:\Ros\clean\reactos\output-i386\ntoskrnl\ntoskrnl.exe C:\Ros\clean\reactos\obj-i386\lib\rtl\rtl.a(random.o): In function `RtlUniform@4': C:/Ros/clean/reactos/lib/rtl/random.c:137: multiple definition of `_RtlUniform@4' C:\Ros\clean\reactos\obj-i386\lib\rtl\rtl.a(random_asm.o):C:\Ros\clean\react os\lib\rtl\i386\random_asm.S:161: first defined here C:\Ros\clean\reactos\obj-i386\lib\rtl\rtl.a(random.o): In function `RtlRandom@4': C:/Ros/clean/reactos/lib/rtl/random.c:69: multiple definition of `_RtlRandom@4' C:\Ros\clean\reactos\obj-i386\lib\rtl\rtl.a(random_asm.o):C:\Ros\clean\react os\lib\rtl\i386\random_asm.S:23: first defined here collect2: ld returned 1 exit status mingw32-make: *** [C:\Ros\clean\reactos\output-i386\ntoskrnl\ntoskrnl.exe] Error 1 Total Build Time: 00:03:09 You will get linking errors , this error looks wired to me . In the rbuild generated file the .asm files generating this problem will be added to the end of the list because they are inside an If condition (ARCH=i386) so this ¿bug? does not appear even when exists Am I missing something here? How can It be solved, any clues?

1 0

Two Day International Conference
by Raghesh A 13 Sep '07

13 Sep '07

Friends, A two day international conference (ICIST2007) is planned at Thrissur(Kerala, India) during 14,15 December 2007 with Free Software as the principal theme. RMS has agreed to engage the participants in a virtual session and clarify online to any subsequent queries. Papers are solicited for ICIST2007. Details are at http://mesengg.ac.in/icist2007.htm Regards, Raghesh

1 0

Boot problems
by Aleksey Bragin 09 Sep '07

09 Sep '07

Hello, trunk is broken in vmware (2nd stage setup problems). Problems disappear when reverting 28918, 28932 and 28933. WBR, Aleksey Bragin.

2 1

[ros-diffs] [jimtabor] 28932: Wrong Meta Tag!
by James Tabor 08 Sep '07

08 Sep '07

- Starting the implementation of thread locking of GDI objects. - Ref: http://www.winehq.org/pipermail/wine-cvs/2007-August/035810.html

1 0

Bug #2640 fixed
by carlo.bramix 07 Sep '07

07 Sep '07

Hello. The attached patch fixes the italian translation of MSCONFIG. Sincerely, Carlo Bramini. ------------------------------------------------------ Leggi GRATIS le tue mail con il telefonino i-mode di Wind http://i-mode.wind.it/

1 0

gdi object code optimization
by Timo Kreuzer 07 Sep '07

07 Sep '07

Hi Here are some ideas for optimizing our gdi object code: 1.) When allocating, locking and deleting a gdi object, we pass the global variable GdiHandleTable to GDIOBJ_AllocObj(). Do we really need this? Is there a case where we pass something else? We would only save few cycles here, but if we don't need it... 2.) When allocating a gdi object, we first need to search the list of LookasideLists. My suggestion is to give each gdi object type a constant index in the list and pass that index instead of the object type value. That would require that the table for the object types/sizes/CleanupProc is in sync with the index definitions. This could be achieved by initializing that table on win32k load: InitGdiObjectType(UINT Index, LONG GdiType, ULONG_PTR ObjectSize, GDICLEANUPPROC CleanupProc); Then we only need to make sure, that every index is only there once and add one line for each object in GDIOBJ_iAllocHandleTable to initialize the object type. 3.) ROS makes massive use of gdi object handles. It uses a lot more handles than windows does. That is because every object we use is always inserted into the handle table. This is slow and wastes handle entries, wich are a limited resource. Whenever we need a (temporary) object, we allocate it (find lookaside list, allocate mem, find free entry, lock entry, do some stuff, unlock entry), then in a second call lock it (do some checks, lock entry, return pointer) and at the end unlock it and then delete it. I think we should rewrite the code a little, so that we only create handles, when the object reaches usermode and use pointers to mem objects instead if the objects are kernel mode / temporary only. XXXOBJ_AllocObj(UINT Index) -> allocate an entry from the LookasideList and initialize it. Don't create a handle. XXXOBJ_FreeObj(PVOID pObjBody) -> free the entry from the LookasideList GDIOBJ_CreateHandle(PVOID pObjBody, UINT Index, LONG GdiType) -> create a handle for a given mem object rewrite some XXXOBJ_Xxx apis to deal with pointers to the mem objects instead of handles (see REGION_Xxx apis) Imo this should result in a big speed increase for several ntgdi/ntuser apis Regards, Timo

3 3

Re: [ros-dev] Build with zlib
by carlo.bramix 07 Sep '07

07 Sep '07

Hello. No, I didn't see the creation of a DLL from the log file. Perhaps I had understood that zlib was compiled as a static library (eh eh), but in my opinion this isn't the best way for using a robust, thread safe library like this one. I also agree that I could explain my idea wrongly. Searching into the online english dictionary... and I found a better word, perhaps "redundant" sounds better than "unuseful". Sincerely, Carlo Bramini. ---------- Initial Header ----------- >From : ros-dev-bounces(a)reactos.org To : "ReactOS Development List" ros-dev(a)reactos.org Cc : Date : Wed, 05 Sep 2007 11:21:07 -0400 Subject : Re: [ros-dev] Build with zlib > Um, because it's a static library? Do you see it in the "dll" directory or > in the "lib" directory? > > -----Original Message----- > From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] On > Behalf Of carlo.bramix > Sent: September-04-07 5:19 AM > To: ros-dev > Subject: [ros-dev] Build with zlib > > Hello, > from the compilation log you can read: > > [CC] lib\3rdparty\zlib\adler32.c > [CC] lib\3rdparty\zlib\compress.c > [CC] lib\3rdparty\zlib\crc32.c > [CC] lib\3rdparty\zlib\gzio.c > [CC] lib\3rdparty\zlib\uncompr.c > [CC] lib\3rdparty\zlib\deflate.c > [CC] lib\3rdparty\zlib\trees.c > [CC] lib\3rdparty\zlib\zutil.c > [CC] lib\3rdparty\zlib\inflate.c > [CC] lib\3rdparty\zlib\infback.c > [CC] lib\3rdparty\zlib\inftrees.c > [CC] lib\3rdparty\zlib\inffast.c > [AR] obj-i386\lib\3rdparty\zlib\zlib.a > > why does it compile zlib.a (absolutely unuseful in my opinion) instead of > zlib1.dll with its libz.a? > This log has been taken from the compilation of ReactOS and *not* from the > "make bootcd" session. > > Sincerely, > > Carlo Bramini. > > > > ------------------------------------------------------ > Leggi GRATIS le tue mail con il telefonino i-modeT di Wind > http://i-mode.wind.it/ > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ------------------------------------------------------ Leggi GRATIS le tue mail con il telefonino i-mode di Wind http://i-mode.wind.it/

2 1

Build with zlib
by carlo.bramix 06 Sep '07

06 Sep '07

Hello, from the compilation log you can read: [CC] lib\3rdparty\zlib\adler32.c [CC] lib\3rdparty\zlib\compress.c [CC] lib\3rdparty\zlib\crc32.c [CC] lib\3rdparty\zlib\gzio.c [CC] lib\3rdparty\zlib\uncompr.c [CC] lib\3rdparty\zlib\deflate.c [CC] lib\3rdparty\zlib\trees.c [CC] lib\3rdparty\zlib\zutil.c [CC] lib\3rdparty\zlib\inflate.c [CC] lib\3rdparty\zlib\infback.c [CC] lib\3rdparty\zlib\inftrees.c [CC] lib\3rdparty\zlib\inffast.c [AR] obj-i386\lib\3rdparty\zlib\zlib.a why does it compile zlib.a (absolutely unuseful in my opinion) instead of zlib1.dll with its libz.a? This log has been taken from the compilation of ReactOS and *not* from the "make bootcd" session. Sincerely, Carlo Bramini. ------------------------------------------------------ Leggi GRATIS le tue mail con il telefonino i-mode di Wind http://i-mode.wind.it/

4 3

Boto regression in rev. 28899
by Jan Schiefer 06 Sep '07

06 Sep '07

Built with RosBE-Unix 0.3.6, running on qemu 0.9.0. At first boot after install with Boot-CD, or when running Live-CD. $ qemu -cdrom ReactOS-LiveCD.iso -boot d -serial stdio (ntoskrnl/kd/kdio.c:191) ----------------------------------------------------- (ntoskrnl/kd/kdio.c:192) ReactOS 0.4-SVN (Build 20070906-r28895) (ntoskrnl/kd/kdio.c:193) Command Line: MININT DEBUGPORT=COM1 NOGUIBOOT (ntoskrnl/kd/kdio.c:197) ARC Paths: multi(0)disk(0)cdrom(224) \ multi(0)disk(0)cdrom(224) \reactos\ (ntoskrnl/mm/mminit.c:264) Base Length Type (ntoskrnl/mm/mminit.c:270) 00000000 00000001 FirmwarePermanent (ntoskrnl/mm/mminit.c:270) 00000001 00000002 MemoryData (ntoskrnl/mm/mminit.c:270) 00000003 00000035 Free (ntoskrnl/mm/mminit.c:270) 00000038 00000008 MemoryData (ntoskrnl/mm/mminit.c:270) 00000040 0000005F Free (ntoskrnl/mm/mminit.c:270) 0000009F 00000001 SpecialMemory (ntoskrnl/mm/mminit.c:270) 000000A0 00000048 FirmwarePermanent (ntoskrnl/mm/mminit.c:270) 000000E8 00000018 SpecialMemory (ntoskrnl/mm/mminit.c:270) 00000100 00000700 Free (ntoskrnl/mm/mminit.c:270) 00000800 00000287 SystemCode (ntoskrnl/mm/mminit.c:270) 00000A87 0000000E BootDriver (ntoskrnl/mm/mminit.c:270) 00000A95 00000019 HalCode (ntoskrnl/mm/mminit.c:270) 00000AAE 00000009 BootDriver (ntoskrnl/mm/mminit.c:270) 00000AB7 0000000F RegistryData (ntoskrnl/mm/mminit.c:270) 00000AC6 00000003 RegistryData (ntoskrnl/mm/mminit.c:270) 00000AC9 00000011 NlsData (ntoskrnl/mm/mminit.c:270) 00000ADA 00000011 NlsData (ntoskrnl/mm/mminit.c:270) 00000AEB 00000002 NlsData (ntoskrnl/mm/mminit.c:270) 00000AED 00000017 BootDriver (ntoskrnl/mm/mminit.c:270) 00000B04 00000015 BootDriver (ntoskrnl/mm/mminit.c:270) 00000B19 0000000D BootDriver (ntoskrnl/mm/mminit.c:270) 00000B26 00000011 BootDriver (ntoskrnl/mm/mminit.c:270) 00000B37 00000019 BootDriver (ntoskrnl/mm/mminit.c:270) 00000B50 00000011 BootDriver (ntoskrnl/mm/mminit.c:270) 00000B61 00000029 BootDriver (ntoskrnl/mm/mminit.c:270) 00000B8A 00000012 BootDriver (ntoskrnl/mm/mminit.c:270) 00000B9C 0000002F BootDriver (ntoskrnl/mm/mminit.c:270) 00000BCB 000003F5 Free (ntoskrnl/mm/mminit.c:270) 00000FC0 0000003F FirmwareTemporary (ntoskrnl/mm/mminit.c:270) 00000FFF 00000001 SpecialMemory (ntoskrnl/mm/mminit.c:270) 00001000 00006FF0 LoaderReserve (ntoskrnl/mm/mminit.c:270) 00007FF0 00000010 SpecialMemory (ntoskrnl/mm/mminit.c:270) 000FFFC0 00000040 SpecialMemory (ntoskrnl/mm/mminit.c:274) Total: 00008040 (128 MB) Used memory 131008Kb (ntoskrnl/ke/i386/kiinit.c:47) Large Page support detected but not yet taken advantage of! WARNING: HaliQuerySystemInformation at hal/halx86/generic/sysinfo.c:31 is UNIMPLEMENTED! (ntoskrnl/ke/i386/patpge.c:62) Advanced Memory features detected but not yet taken advantage of. IoReportResourceUsage at ntoskrnl/io/iomgr/iorsrce.c:701 is unimplemented, have a nice day (ntoskrnl/io/iomgr/driver.c:1255) '\Driver\BUSLOGIC' initialization failed, status (0xc00000c0) (ntoskrnl/io/iomgr/driver.c:1255) '\Driver\DISK' initialization failed, status (0xc000000e) (ntoskrnl/io/iomgr/driver.c:1255) '\Driver\Floppy' initialization failed, status (0xc000000e) MmPageEntireDriver at ntoskrnl/mm/drvlck.c:87 is unimplemented, have a nice day MmPageEntireDriver at ntoskrnl/mm/drvlck.c:87 is unimplemented, have a nice day MmPageEntireDriver at ntoskrnl/mm/drvlck.c:87 is unimplemented, have a nice day (drivers/video/videoprt/videoprt.c:723) No PNP Videocard . (drivers/video/videoprt/videoprt.c:723) No PNP Videocard . (lib/rtl/registry.c:362) RTL: Expand variables for %SystemRoot%\system32\cmd.exe failed - Status == c0000023 Size a8 > 7e <e> (lib/rtl/registry.c:362) RTL: Expand variables for %SystemRoot%\bin;%SystemRoot%\system32;%SystemRoot% failed - Status == c0000023 Size f4 > ac <14> (lib/rtl/registry.c:362) RTL: Expand variables for %SystemRoot%\system32 failed - Status == c0000023 Size a0 > 7e <6> (drivers/filesystems/cdfs/fsctl.c:536) CDFS: IRP_MN_USER_FS_REQUEST (drivers/filesystems/cdfs/fsctl.c:536) CDFS: IRP_MN_USER_FS_REQUEST (drivers/filesystems/cdfs/fsctl.c:536) CDFS: IRP_MN_USER_FS_REQUEST (drivers/filesystems/cdfs/fsctl.c:536) CDFS: IRP_MN_USER_FS_REQUEST (ntoskrnl/io/iomgr/file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 1f01ff (ntoskrnl/io/iomgr/file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 1f01ff (ntoskrnl/ke/balmgr.c:79) Thread: 8120EA78 ntoskrnl/mm/rpoolmgr.h(913): double-free detected for paged pool address 0x8db3dde8 Tag PALE(454C4150), Size -1917592344, UserSize 88 First few Stack Frames: <80859719> <8085983D> <9E4156E2> <9E41D444> <9E3DC804> <8082D980> Contents of Block: 0000 00 03 14 00 00 00 00 00 80 00 00 00 00 80 00 00 ................ 0010 80 80 00 00 00 00 80 00 80 00 80 00 00 80 80 00 ................ 0020 C0 C0 C0 00 C0 DC C0 00 D4 D0 C7 00 FF FB F0 00 ................ 0030 3A 6E A5 00 80 80 80 00 FF 00 00 00 00 FF 00 00 :n.............. 0040 FF FF 00 00 00 00 FF 00 FF 00 FF 00 00 FF FF 00 ................ 0050 FF FF FF 00 CD CD CD CD ........ *** Fatal System Error: 0x00000000 (0x00000000,0x00000000,0x00000000,0x00000000) <\SystemRoot\System32\NTOSKRNL.EXE: 2989> <\SystemRoot\System32\NTOSKRNL.EXE: 59b36> <\SystemRoot\System32\NTOSKRNL.EXE: 59cff> <\SystemRoot\System32\NTOSKRNL.EXE: 5a3f2> <\SystemRoot\System32\NTOSKRNL.EXE: 596c2> <\??\C:\reactos\system32\win32k.sys: 8472d> <\??\C:\reactos\system32\win32k.sys: 8c444> <\??\C:\reactos\system32\win32k.sys: 4b804> <\SystemRoot\System32\NTOSKRNL.EXE: 2d980> <\SystemRoot\System32\NTOSKRNL.EXE: 2c939> <\SystemRoot\System32\NTOSKRNL.EXE: 87234> <\SystemRoot\System32\NTOSKRNL.EXE: 1f879> <\SystemRoot\System32\NTOSKRNL.EXE: 2c939> <\SystemRoot\System32\NTOSKRNL.EXE: 87234>

1 0

regarding access.cpl (For Eric)
by Daniel Reimer 03 Sep '07

03 Sep '07

Hi, This is for Eric. I couldnt find your Mail Address, so I send this to ROS ML instead. I uploaded a picture with the errors in German RC, which are left. Only one Window makes problems. http://img407.imageshack.us/img407/7514/errorsbf8.jpg Bye Daniel "EmuandCo" Reimer

1 0

idea to a test frame work and other changes to win32k
by Magnus Olsen 02 Sep '07

02 Sep '07

Hi I am thinking of doing this adding a header call ntuser.h and put it in include/reactos/../ that contain all ntuser* syscall prototypes next thing we need a good test frame work betwin gdi32.dll and win32k.sys so we can check all param from gdi32 comes down to win32k are correct or captuers ms gdi32.dll to achive this so easy as posible I am thinking of adding a new config value or define value for win32k that will always test the input data is correct. example INT STDCALL NtGdiExtEscape(HDC hDC, IN OPTIONAL PWCHAR pDriver, IN INT nDriver, INT Escape, INT InSize, OPTIONAL LPSTR UnsafeInData, INT OutSize, OPTIONAL LPSTR UnsafeOutData) { PDC pDC; LPVOID SafeInData = NULL; LPVOID SafeOutData = NULL; NTSTATUS Status = STATUS_SUCCESS; INT Result; #if gdi32_testing_on test_NtGdiExtEscape(...); #endif ... ... } test will testing see if the data should have been sent or not to win32k and vaildate everthing. and if any error detects it print out a DPRINT1 msg DPRINT1("Testing start"); DPRINT1("Status : fail"); DPRINT1("Status : why :"); DPRINT1("Testing end"); or DPRINT1("Testing start"); DPRINT1("Status : Sussess"); DPRINT1("Testing end"); it is like this I want adding to win32k and thuse build in test case. I hope you all have understanding of good testcase and testframe buildin that can be easy disable and activate. ofcures the testframe should not be in debug build. we maybe should create a complete new target for it as well so public can get hold of it easy.

1 0

Re: [ros-dev] [ros-diffs] [hpoussin] 28693: Implement IsUserAnAdmin(), by copying implementation of IsUserAdmin() in setupapi (was implemented by Eric Kohl) Redirect setupapi.IsUserAdmin to shell32.IsUserAnAdmin
by Jeremy Drake 31 Aug '07

31 Aug '07

Umm, this implementation of IsUserAnAdmin is not quite correct. I just had to deal with a function almost identical to this in real life, which gave the wrong answer on Vista due to the filtered token containing the Administrators group with the "for deny only" attribute. You need to either check the attribute portion of the SID_AND_ATTRIBUTE struct as well, or use something like CheckTokenMembership (assuming that is implemented properly), or construct a security descriptor and use AccessCheck (again, assuming that is implemented correctly (I would hope so...)). Of course, this is probably just overly anal on ReactOS, as you don't have the whole Vista filtered token/elevation mess (yet), but probably best to be technically correct... On Fri, 31 Aug 2007, hpoussin(a)svn.reactos.org wrote: > Author: hpoussin > Date: Fri Aug 31 13:49:48 2007 > New Revision: 28693 > > URL: http://svn.reactos.org/svn/reactos?rev=28693&view=rev > Log: > Implement IsUserAnAdmin(), by copying implementation of IsUserAdmin() in setupapi (was implemented by Eric Kohl) > Redirect setupapi.IsUserAdmin to shell32.IsUserAnAdmin > > Modified: > trunk/reactos/dll/win32/setupapi/cfgmgr.c > trunk/reactos/dll/win32/setupapi/misc.c > trunk/reactos/dll/win32/setupapi/setupapi.spec > trunk/reactos/dll/win32/shell32/shellord.c > > Modified: trunk/reactos/dll/win32/setupapi/cfgmgr.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/setupapi/cfgmgr.… > ============================================================================== > --- trunk/reactos/dll/win32/setupapi/cfgmgr.c (original) > +++ trunk/reactos/dll/win32/setupapi/cfgmgr.c Fri Aug 31 13:49:48 2007 > @@ -135,7 +135,7 @@ > if (!PnpGetLocalHandles(&BindingHandle, NULL)) > return CR_FAILURE; > > - bAdmin = IsUserAdmin(); > + bAdmin = IsUserAnAdmin(); > > for (i = 0; i < 30; i++) > { > @@ -182,7 +182,7 @@ > FIXME("%p %p %lu %lx %p\n", > plcLogConf, dnDevInst, Priority, ulFlags, hMachine); > > - if (!IsUserAdmin()) > + if (!IsUserAnAdmin()) > return CR_ACCESS_DENIED; > > if (plcLogConf == NULL) > @@ -298,7 +298,7 @@ > > TRACE("%p %s %lx %p\n", dnDevInst, debugstr_w(pszID), ulFlags, hMachine); > > - if (!IsUserAdmin()) > + if (!IsUserAnAdmin()) > return CR_ACCESS_DENIED; > > if (dnDevInst == 0) > @@ -490,7 +490,7 @@ > FIXME("%p %s %p %lx %p\n", > pdnDevInst, debugstr_w(pDeviceID), dnParent, ulFlags, hMachine); > > - if (!IsUserAdmin()) > + if (!IsUserAnAdmin()) > return CR_ACCESS_DENIED; > > if (pdnDevInst == NULL) > @@ -637,7 +637,7 @@ > > FIXME("%p %lx %p\n", dnDevInst, ulFlags, hMachine); > > - if (!IsUserAdmin()) > + if (!IsUserAnAdmin()) > return CR_ACCESS_DENIED; > > if (dnDevInst == 0) > @@ -725,7 +725,7 @@ > > FIXME("%p %lx %p\n", dnDevInst, ulFlags, hMachine); > > - if (!IsUserAdmin()) > + if (!IsUserAnAdmin()) > return CR_ACCESS_DENIED; > > if (dnDevInst == 0) > @@ -961,7 +961,7 @@ > > TRACE("%lx %lx %lx\n", lcLogConfToBeFreed, ulFlags, hMachine); > > - if (!IsUserAdmin()) > + if (!IsUserAnAdmin()) > return CR_ACCESS_DENIED; > > pLogConfInfo = (PLOG_CONF_INFO)lcLogConfToBeFreed; > @@ -2707,7 +2707,7 @@ > FIXME("%lx %lx %lx %lx\n", > dnFromDevInst, dnToDevInst, ulFlags, hMachine); > > - if (!IsUserAdmin()) > + if (!IsUserAnAdmin()) > return CR_ACCESS_DENIED; > > if (dnFromDevInst == 0 || dnToDevInst == 0) > @@ -3051,7 +3051,7 @@ > > TRACE("%lx %lx\n", ulFlags, hMachine); > > - if (!IsUserAdmin()) > + if (!IsUserAnAdmin()) > return CR_ACCESS_DENIED; > > if (ulFlags & ~CM_DETECT_BITS) > @@ -3525,7 +3525,7 @@ > > FIXME("%lx %lx %lx\n", dnDevInst, ulFlags, hMachine); > > - if (!IsUserAdmin()) > + if (!IsUserAnAdmin()) > return CR_ACCESS_DENIED; > > if (dnDevInst == 0) > > Modified: trunk/reactos/dll/win32/setupapi/misc.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/setupapi/misc.c?… > ============================================================================== > --- trunk/reactos/dll/win32/setupapi/misc.c (original) > +++ trunk/reactos/dll/win32/setupapi/misc.c Fri Aug 31 13:49:48 2007 > @@ -246,84 +246,6 @@ > MyFree(*lpData); > > return lError; > -} > - > - > -/************************************************************************** > - * IsUserAdmin [SETUPAPI.@] > - * > - * Checks whether the current user is a member of the Administrators group. > - * > - * PARAMS > - * None > - * > - * RETURNS > - * Success: TRUE > - * Failure: FALSE > - */ > -BOOL WINAPI IsUserAdmin(VOID) > -{ > - SID_IDENTIFIER_AUTHORITY Authority = {SECURITY_NT_AUTHORITY}; > - HANDLE hToken; > - DWORD dwSize; > - PTOKEN_GROUPS lpGroups; > - PSID lpSid; > - DWORD i; > - BOOL bResult = FALSE; > - > - TRACE("\n"); > - > - if (!OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY, &hToken)) > - { > - return FALSE; > - } > - > - if (!GetTokenInformation(hToken, TokenGroups, NULL, 0, &dwSize)) > - { > - if (GetLastError() != ERROR_INSUFFICIENT_BUFFER) > - { > - CloseHandle(hToken); > - return FALSE; > - } > - } > - > - lpGroups = MyMalloc(dwSize); > - if (lpGroups == NULL) > - { > - CloseHandle(hToken); > - return FALSE; > - } > - > - if (!GetTokenInformation(hToken, TokenGroups, lpGroups, dwSize, &dwSize)) > - { > - MyFree(lpGroups); > - CloseHandle(hToken); > - return FALSE; > - } > - > - CloseHandle(hToken); > - > - if (!AllocateAndInitializeSid(&Authority, 2, SECURITY_BUILTIN_DOMAIN_RID, > - DOMAIN_ALIAS_RID_ADMINS, 0, 0, 0, 0, 0, 0, > - &lpSid)) > - { > - MyFree(lpGroups); > - return FALSE; > - } > - > - for (i = 0; i < lpGroups->GroupCount; i++) > - { > - if (EqualSid(lpSid, lpGroups->Groups[i].Sid)) > - { > - bResult = TRUE; > - break; > - } > - } > - > - FreeSid(lpSid); > - MyFree(lpGroups); > - > - return bResult; > } > > > > Modified: trunk/reactos/dll/win32/setupapi/setupapi.spec > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/setupapi/setupap… > ============================================================================== > --- trunk/reactos/dll/win32/setupapi/setupapi.spec (original) > +++ trunk/reactos/dll/win32/setupapi/setupapi.spec Fri Aug 31 13:49:48 2007 > @@ -216,7 +216,7 @@ > @ stdcall InstallHinfSectionW(long long wstr long) > @ stub InstallStop > @ stub InstallStopEx > -@ stdcall IsUserAdmin() > +@ stdcall IsUserAdmin=shell32.IsUserAnAdmin() > @ stub LookUpStringInTable > @ stub MemoryInitialize > @ stdcall MultiByteToUnicode(str long) > > Modified: trunk/reactos/dll/win32/shell32/shellord.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/shell32/shellord… > ============================================================================== > --- trunk/reactos/dll/win32/shell32/shellord.c (original) > +++ trunk/reactos/dll/win32/shell32/shellord.c Fri Aug 31 13:49:48 2007 > @@ -1227,10 +1227,78 @@ > /************************************************************************* > * IsUserAnAdmin [SHELL32.680] NT 4.0 > * > + * Checks whether the current user is a member of the Administrators group. > + * > + * PARAMS > + * None > + * > + * RETURNS > + * Success: TRUE > + * Failure: FALSE > */ > BOOL WINAPI IsUserAnAdmin(VOID) > -{ FIXME("stub\n"); > - return TRUE; > +{ > + SID_IDENTIFIER_AUTHORITY Authority = {SECURITY_NT_AUTHORITY}; > + HANDLE hToken; > + DWORD dwSize; > + PTOKEN_GROUPS lpGroups; > + PSID lpSid; > + DWORD i; > + BOOL bResult = FALSE; > + > + TRACE("\n"); > + > + if (!OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY, &hToken)) > + { > + return FALSE; > + } > + > + if (!GetTokenInformation(hToken, TokenGroups, NULL, 0, &dwSize)) > + { > + if (GetLastError() != ERROR_INSUFFICIENT_BUFFER) > + { > + CloseHandle(hToken); > + return FALSE; > + } > + } > + > + lpGroups = HeapAlloc(GetProcessHeap(), 0, dwSize); > + if (lpGroups == NULL) > + { > + CloseHandle(hToken); > + return FALSE; > + } > + > + if (!GetTokenInformation(hToken, TokenGroups, lpGroups, dwSize, &dwSize)) > + { > + HeapFree(GetProcessHeap(), 0, lpGroups); > + CloseHandle(hToken); > + return FALSE; > + } > + > + CloseHandle(hToken); > + > + if (!AllocateAndInitializeSid(&Authority, 2, SECURITY_BUILTIN_DOMAIN_RID, > + DOMAIN_ALIAS_RID_ADMINS, 0, 0, 0, 0, 0, 0, > + &lpSid)) > + { > + HeapFree(GetProcessHeap(), 0, lpGroups); > + return FALSE; > + } > + > + for (i = 0; i < lpGroups->GroupCount; i++) > + { > + if (EqualSid(lpSid, lpGroups->Groups[i].Sid)) > + { > + bResult = TRUE; > + break; > + } > + } > + > + FreeSid(lpSid); > + HeapFree(GetProcessHeap(), 0, lpGroups); > + > + return bResult; > } > > /************************************************************************* > > > > -- Fortune's Real-Life Courtroom Quote #19: Q: Doctor, how many autopsies have you performed on dead people? A: All my autopsies have been performed on dead people.

1 0

GDI_TABLE_ENTRY structure
by Timo Kreuzer 31 Aug '07

31 Aug '07

Our current gdi handle and handle table entry code uses a bunch of macros, masks, bitshifts and even hardcoded values, iirc. This leads imo to errors, will make the code less portable and cannot make use of better compiler optimizations. So I have created a new GDI_TABLE_ENTRY struct and a new type GDIHANDLE. Both use unions and packed structs to directly access all fields. GDI_TABLE_ENTRY is completely compatible to our current one, so all the code would still be valid. + the compiler can optimize access of single elements better (movzx, byte ptr ...) + no more need for additional masks, shifts and macros + no more messed up code because of wrong hardcoded values + better readable code + probably easier porting to 64 bits - must be redefined for big-endian systems - direct access of stockbit is slightly slower, but could still be handled by a macro #pragma pack(push,1) typedef struct { PVOID KernelData; /* Points to the kernel mode structure */ union { DWORD ProcessId; /* process id that created the object, 0 for kernel objects */ struct { unsigned ProcessId16: 16; unsigned Unused: 16; }; }; union { ULONG Type; struct { union { unsigned TypeLower: 16; struct { union { unsigned HandleTypeStock: 8; struct { unsigned HandleType: 7; unsigned StockBit: 1; }; }; unsigned ReuseCount: 8; }; }; union { unsigned TypeUpper: 16; struct { unsigned StorageType: 8; /* PEN uses same value as BRUSH here, no stock bit */ unsigned Flags: 8; }; }; }; }; PVOID UserData; /* Points to the user mode structure, usually NULL though */ } GDI_TABLE_ENTRY, *PGDI_TABLE_ENTRY;; typedef union { HGDIOBJ Handle; struct { unsigned Index: 16; union { unsigned Upper: 16; struct { union { unsigned HandleTypeStock: 8; struct { unsigned HandleType: 7; unsigned StockBit: 1; }; }; unsigned ReuseCount: 8; }; }; }; } GDIHANDLE, *PGDIHANDLE; #pragma pack(pop)

6 16

Re: [ros-dev] [ros-diffs] [greatlrd] 28680: implement GdiConvertPalette, GdiConvertRegion
by Ged 30 Aug '07

30 Aug '07

Hi Magnus. Can you explain these please, they seem a bit weird? Cheers, Ged. greatlrd(a)svn.reactos.org wrote: > Author: greatlrd > Date: Thu Aug 30 23:05:43 2007 > New Revision: 28680 > > URL: http://svn.reactos.org/svn/reactos?rev=28680&view=rev > Log: > implement GdiConvertPalette, GdiConvertRegion > > Modified: > trunk/reactos/dll/win32/gdi32/misc/stubs.c > > Modified: trunk/reactos/dll/win32/gdi32/misc/stubs.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/gdi32/misc/stubs… > ============================================================================== > --- trunk/reactos/dll/win32/gdi32/misc/stubs.c (original) > +++ trunk/reactos/dll/win32/gdi32/misc/stubs.c Thu Aug 30 23:05:43 2007 > @@ -1431,15 +1431,13 @@ > } > > /* > - * @unimplemented > + * @implemented > */ > HPALETTE > STDCALL > GdiConvertPalette(HPALETTE hpal) > { > - UNIMPLEMENTED; > - SetLastError(ERROR_CALL_NOT_IMPLEMENTED); > - return 0; > + return hpal; > } > > /* > @@ -1449,9 +1447,7 @@ > STDCALL > GdiConvertRegion(HRGN hregion) > { > - UNIMPLEMENTED; > - SetLastError(ERROR_CALL_NOT_IMPLEMENTED); > - return 0; > + return hregion; > } > > /* > > > >

2 1

Re: [ros-dev] current status of xen support
by Aleksey Bragin 30 Aug '07

30 Aug '07

There is still a branch "xen", where some work has been done, however it's greatly outdated. If someone has a wish, he could make a new branch. But we don't have any volunteers at the moment. WBR, Aleksey Bragin. On Aug 30, 2007, at 6:32 PM, Brian wrote: > i was curious as to the status of reactos on xen. does it work(boot > at all)? i haven't seen anything new about it on the site, and i > interested. > > thanks in advance > -- > brian

2 1

current status of xen support
by Brian 30 Aug '07

30 Aug '07

i was curious as to the status of reactos on xen. does it work(boot at all)? i haven't seen anything new about it on the site, and i interested. thanks in advance -- brian

3 2

0.33rc2?
by Bernd Blaauw 30 Aug '07

30 Aug '07

Is there going to be a new release candidate of ReactOS version 0.3.3? I tested it very shortly and was very impressed with how it looked in comparison to version 0.3.0. Is there a list of known bugs as feedback from 0.3.3rc1 testers? Searching through Bugzilla might be a bit too much :). Anyway, the issues I experience in VMware 6.00 on WinXP Pro x64 host so far are: * diskette drive not visible (and/or working). Ever since 0.2.8 or so? * shutdown does not close the virtual machine (might be improper shutdown). Screen goes all black and need to enter VMware menu to shutdown the ReactOS virtual machine. Is the AUTORUN.INF by now the only file on the root of the CD? icons and readme files can go in subdirectories I guess, which makes adding ReactOS to multi-installation CDs a lot easier (a CD/DVD containing setup or LiveCD of various operating systems, mostly using the Isolinux bootloader for a frontend menu and chainloading bootsectors). I've not extensively tested the RC1 on for example if it still can complete installation and bootup with 32MB or less RAM installed (VMware allows anywhere from 4MB to 8GB in increments of 4MB, Bochs/Qemu allow 1MB increases). A resolved item I noticed in this new release was the ability to enter digits for the computername, wasnt possible previously in 0.3.0 or 0.3.1. ReactOS is getting interesting by now..a Win32 operating system with a size of about 50MB and capable of playing huge games sooner or later. Looks like a blessing to my limited size (16GB) DRAM based solid state disk.

4 4

[ros-diffs] [jimtabor] 22523: GetGlyphOutline, large wine port. Still testing.
by James Tabor 30 Aug '07

30 Aug '07

Hi, I have it half way done. Run the test program and you can see. Program works in W2k, XP and Wine. mingw32-gcc -mwindows -Os GetGlyphOutline.c -o ggo.exe I stopped messing with it two weeks ago, I needed to work on something else. When testing you can select the alphanumeric character with the keyboard. The original program had "a" but I changed it to "L" something simple to draw at first. You will see the problem. The test program from Dr. Dobb's Journal http://www.ddj.com/184409154?pgno=12 Thanks, James Runs and hides~

1 1

Re: [ros-dev] Will ROS and WINE still be steady be synchronized ?
by theUser BL 29 Aug '07

29 Aug '07

>Personal preference. >Wine are nearing to a 1.0 product and are very careful about what code >enters their repository. >ReactOS does not currently meet their strict policy. > >If you want to get code into Wine, you must submit your patches with test >cases and if required, relevant links to documentation. I have also ask the question on the WINE-mailinglist. The answer at http://www.winehq.org/pipermail/wine-devel/2007-August/058929.html looks like, that the test-suites are not the only reason. Greatings theuserbl _________________________________________________________________ Sie suchen E-Mails, Dokumente oder Fotos? Die neue MSN Suche Toolbar mit Windows-Desktopsuche liefert in sekundenschnelle Ergebnisse. Jetzt neu! http://desktop.msn.de/ Jetzt gratis downloaden!

3 2

Re: [ros-dev] Will ROS and WINE still be steady be synchronized ?
by Aleksey Bragin 29 Aug '07

29 Aug '07

As I already said, the difference between ReactOS and WINE, as it's written in that Wine mailing list, is that ReactOS "is known" [by some] for reversing MS binaries, and Wine is not known for reversing MS binaries (though it does not imply ReactOS is always doing it, and Wine did [does] not reverse engineer). Also, Wine is not "Open Source community", it is *part* of Open source community, as are thousands of other projects, which somehow form the general perception of projects. WBR, Aleksey Bragin. On Aug 29, 2007, at 7:01 PM, Marc Piulachs wrote: > > Does it mean ReactOS is not respected/trusted among the Open Source > community for disassembling Microsoft binaries? > > I don't know if this accusation is really true or not but if it's > not I > think it's even worse because that means that something is failing > (probably > communication) between the project and the OS community. Doing > nothing about > that is IMHO a very bad idea. > > I think it deserves some deep reflection and a *serious* strategy > to change > that general opinion. Earn respect is a KEY thing to do if the > project wants > to attract new developers. > > My two cents, > Marc

1 0

Re: [ros-dev] Will ROS and WINE still be steady be synchronized ?
by Aleksey Bragin 29 Aug '07

29 Aug '07

Wine, as every other project, is free to set their own rules for accepting patches. If members of our development team can do anything to help Wine - we are glad to. However, they seem to want to stick to only their own devs' contribution (mainly). With the best regards, Aleksey Bragin. On Aug 29, 2007, at 4:54 PM, theUser BL wrote: >> Personal preference. >> Wine are nearing to a 1.0 product and are very careful about what >> code >> enters their repository. >> ReactOS does not currently meet their strict policy. >> >> If you want to get code into Wine, you must submit your patches >> with test >> cases and if required, relevant links to documentation. > > I have also ask the question on the WINE-mailinglist. > The answer at > http://www.winehq.org/pipermail/wine-devel/2007-August/058929.html > looks like, that the test-suites are not the only reason. > > > Greatings > theuserbl

1 0

Re: [ros-dev] [ros-diffs] [hpoussin] 28603: qsort() prototype in stdlib.h doesn't specify that callback function must be __cdecl
by Alex Ionescu 29 Aug '07

29 Aug '07

O rly? _CRTIMP void __cdecl qsort(__inout_bcount(_NumOfElements * _SizeOfElements) void * _Base, On 8/27/07, hpoussin(a)svn.reactos.org <hpoussin(a)svn.reactos.org> wrote: > > Author: hpoussin > Date: Mon Aug 27 19:26:39 2007 > New Revision: 28603 > > URL: http://svn.reactos.org/svn/reactos?rev=28603&view=rev > Log: > qsort() prototype in stdlib.h doesn't specify that callback function must > be __cdecl > > Modified: > trunk/reactos/lib/rtl/bitmap.c > > Modified: trunk/reactos/lib/rtl/bitmap.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/lib/rtl/bitmap.c?rev=28603… > > ============================================================================== > --- trunk/reactos/lib/rtl/bitmap.c (original) > +++ trunk/reactos/lib/rtl/bitmap.c Mon Aug 27 19:26:39 2007 > @@ -36,7 +36,6 @@ > > static > int > -__cdecl > NTDLL_RunSortFn(const void *lhs, > const void *rhs) > { > > > -- Best regards, Alex Ionescu

2 1

Wine-WordPad instead of ROS-WordPad?
by theUser BL 28 Aug '07

28 Aug '07

Hi! Yesterday I have downloaded and tried out the lastest vrsion of Wine. Version 0.9.44. In the annoncement of that release there stand "Improvements to the builtin WordPad". So I have also tried ot its WordPad and it looks better then the ROS-Notepad. So wouldn't it a trhought to use WINEs WordPad instead of ROS one? And will the sources of WINE and ROS steady be synchronized ? Seems, that WINE uses an old version of cards.dll. The notepad from ROS and WINE is different and so on. _________________________________________________________________ Sie suchen E-Mails, Dokumente oder Fotos? Die neue MSN Suche Toolbar mit Windows-Desktopsuche liefert in sekundenschnelle Ergebnisse. Jetzt neu! http://desktop.msn.de/ Jetzt gratis downloaden!

3 3

Re: [ros-dev] State of 0.3.3
by carlo.bramix 28 Aug '07

28 Aug '07

Hello. If it's possible, I would ask to apply the patch posted at bug #2494 before releasing 0.3.3 (RC2 or Final), so I will be able to remove my backup copy of regedit... Sincerely, Carlo Bramini. Colin Finck wrote: > Hello, > > As you probably saw, I recently rebranched 0.3.3 and made some changes to > it. > Now I'm at the point, where *I* think that it's ready. > > I don't know if anyone else has any specific plans for 0.3.3, so I'm just > asking here now. > Otherwise, I think we could simply release the current branch as RC2 or even > REL. But also if we release it as RC2 now, what are the plans for the REL > version then? > > Please also think of our planned 2-month release cycle. > I know that these are just estimated dates, where users *can* expect a > release and I myself said this a couple of times as well, but we already > skipped 0.3.2, so we shouldn't miss the "deadline" for 0.3.3 now. > > Regards, > > Colin > > _______________________________________________ > Ros-dev mailing list > Ros-dev at reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

1 0

ENUMFONTDATAW structure
by Timo Kreuzer 27 Aug '07

27 Aug '07

I agree with the complete structure itself, but I have some issues with the way it is implemented atm. 1.) the member ulOffsetTM: If it is an offset one would guess it would be an offset from the beginning of the struct, but it isn't. It's relative to dwFontType. I would interpret it more as a cbSize member of an internal variable size struct., that comes before dwFlags (see below) / textmetric 2.) The current definition has a member enfdi, wich follows after a variable size struct. IMO this member should be removed, as it doesn't have a constant offset. It implies that you can simply access it, but you cannot, if the designvektor has any entries. It should be commented out to prevent misuse. 3.) The enfdi struct doesn't really make sense to me. The dwReserved members are not like axlReserved a constant. It looks more like some flags or it might be code page related. With this structure the OffsetTm member points to a substruct of a struct, that doesn't seem right to me. So here is my version: I also use INT versions of structs with a [0] array, so it matches the data, when no additional stuff is present But as we always have to consider our structs as variable length we do not really need them. In any case we have to parse through the struct. We can then typecast the pointers to the original structs and all's well. typedef struct _AXELISTINTW { DWORD axlReserved; DWORD axlNumAxes; AXISINFOW axlAxesInfo[0]; } AXELISTINTW, *PAXELISTINTW; typedef struct _ENUMTEXTMETRICINTW { NEWTEXTMETRICEXW etmNewTextMetricEx; AXELISTINTW etmAxesList; } ENUMTEXTMETRICINTW, *PENUMTEXTMETRICINTW; typedef struct { DWORD cbSize; DWORD dwFontType; ENUMLOGFONTEXW elfex; DESIGNVECTORINT dv; // variable position, might be dv.dvValues[0], if DESIGNVECTORINT was declared with dvValues[1] // I didn't yet manage to get info with dvNumAxes > 0 // DWORD dwReserved; } ENUMFONTDATAINTW, *PENUMFONTDATAINTW; typedef struct _ENUMFONTDATAW { DWORD cbSize; ENUMFONTDATAINTW efdi; // Those are not real members as they don't have a constant pos in the struct // DWORD dwFlags; // ENUMTEXTMETRICINTW etmi; } ENUMFONTDATAW, *PENUMFONTDATAW;

2 1

Re: [ros-dev] Open source drivers for (S)ATA and VESA
by Aleksey Bragin 27 Aug '07

27 Aug '07

Hi, Magnus already commented about the video driver (if his changes were good, he would send us patches). However, uniata is not that bad, I was going to review it some time after 0.3.3, and if the code is allright, it could be included. IIRC, scsiport needs some improvement in order to fully support the uniata driver. WBR, Aleksey Bragin. On Aug 27, 2007, at 8:42 PM, Timo Kreuzer wrote: > Hi, I just found some interesting stuff: > > Universal ATA driver (http://alter.org.ua/soft/win/uni_ata/) > - generic NT driver for DMA/UDMA ATA / SATA with source code > > Universal VESA driver > - based on ReactOS vbemp.sys > - works on all windows NT and ReactOS > the author has been working on this until very recently, so it > might be > better than our current driver > > Timo

1 0

Open source drivers for (S)ATA and VESA
by Timo Kreuzer 27 Aug '07

27 Aug '07

Hi, I just found some interesting stuff: Universal ATA driver (http://alter.org.ua/soft/win/uni_ata/) - generic NT driver for DMA/UDMA ATA / SATA with source code Universal VESA driver - based on ReactOS vbemp.sys - works on all windows NT and ReactOS the author has been working on this until very recently, so it might be better than our current driver Timo

2 1

State of 0.3.3
by Colin Finck 26 Aug '07

26 Aug '07

Hello, As you probably saw, I recently rebranched 0.3.3 and made some changes to it. Now I'm at the point, where *I* think that it's ready. I don't know if anyone else has any specific plans for 0.3.3, so I'm just asking here now. Otherwise, I think we could simply release the current branch as RC2 or even REL. But also if we release it as RC2 now, what are the plans for the REL version then? Please also think of our planned 2-month release cycle. I know that these are just estimated dates, where users *can* expect a release and I myself said this a couple of times as well, but we already skipped 0.3.2, so we shouldn't miss the "deadline" for 0.3.3 now. Regards, Colin

5 4

Megalithic subjects
by carlo.bramix 25 Aug '07

25 Aug '07

Hello, I don't want to make problems in any way but... is it possible to make the titles of the emails a bit shorter when it could be done? Some of them are really difficult to read and, in my opinion, the body of the email exists for writing more detailed explanations. Sincerely, Carlo Bramini

1 0

[ros-diffs] [cfinck] 28526: rbuild enhancements by Marc Piulachs
by James Tabor 25 Aug '07

25 Aug '07

Hi! r28526 broke bootcd Sorry, James

1 0

ReactOS and Sound cards.
by James Courtier-Dutton 24 Aug '07

24 Aug '07

Hi, How much work would it take to support a soundcard in ReactOS? I would like to use it to help me reverse engineer a sound card to get it working in Linux. Kind Regards James

2 1

Re: [ros-dev] IoCheckEaBufferValidity
by Aleksey Bragin 24 Aug '07

24 Aug '07

Reformatted, improved and committed (28506 & 28507). Thanks for contribution. WBR, Aleksey Bragin. On Aug 22, 2007, at 1:53 AM, netzimme(a)aim.com wrote: > > > Sorry the patch was wrong. I have forgot to change the function name. > > > Thanks > Daniel Zimmermann

1 0

[Fwd: [ros-kernel] ReactOS status report for 10/12/1998]
by James Tabor 23 Aug '07

23 Aug '07

Hi! More voices from the past. James -------- Original Message -------- Subject: [ros-kernel] ReactOS status report for 10/12/1998 Resent-Date: Tue, 13 Oct 1998 00:21:40 -0500 Resent-From: ros-kernel(a)sid-dis.com Date: Mon, 12 Oct 1998 22:24:40 -0700 From: rex <rex(a)lvcablemodem.com> Reply-To: <ros-kernel(a)sid-dis.com> To: ros-kernel(a)sid-dis.com <ros-kernel(a)sid-dis.com> ReactOS status report for Monday, October 12th 1998 Current Kernel Release is 0.0.12 Working drivers: Driver Version ------------ ------- FS/Minix 0.0.1 IDE 0.1.2 Keyboard 0.0.4 Null 0.0.1 Parallel 0.0.1 SDisk 0.0.1 Welcome to Brian and good luck to him as he settles in and learns of the vast intracacies and subtleties of the ReactOS kernel. Benoit Papillault has taken on the task of the PE program loader. Francois Asselin sent me a response indicating he doesnt currently have time to work on the schedular due to his studies. Perhaps he should move to the inactive list. An attempt to send mail to Iwan Fatahi's mail account bounced. Iwan, if you're there, perhaps you can let me know if you're working on anything, and let the webmaster know your current email address. I've been sending messages to various people on the kernel members listing asking for status on their piece of the system. If I do not get a responce after three tries I'll assume that person is busy for the time being, send the info to the appropriate lead and remove their name from the status report. If anyone thinks that's not an appropriate thing to do let me know. Development Status: Boot Loader No Status. DOS Loader No Status. Kernel: Brain Palmer I/O Manager: No Status. Memory Management No Status. Process Management: No Status. Security Manager No Status. Filesystem Interface No Status. Miniport Drivers No Status. Local Procedure Calls: Giovanni Tapang No Status. System Calls: Networking support: Arindam Das and Jason Eager No Status. Plug and Play support No Status. PCI No Status. Registry No Status. ACPI power managment No Status. Loader for PE executables: Benoit Papillault No status. Ports to other platforms No Status. Drivers: Floppy: Rex Jolliff No status. IDE: Rex Jolliff Worked on bug reports: Driver crashes on detection of Secondary/Slave with ATAPI CDROM connected. (I believe I found the problem, but need an updated test system to be sure) Driver creates incorrect symbolic link for 2nd drive. (I'm not sure this bug exists, as I can't reproduce it.) Sound: Robert Bergkvist (FragDance Galore) No status. VFAT: Jason Filby First release currently in testing. Other Filesystems: Dennis Varouxis and Etienne Cochard No status. Console No status. Mouse: Jason Filby No status. Network No status. Serial No status. Video: Conor Stokes, Iwan Fatahi and Jerome Davadilla Mail sent to Iwan Fatahi requesting status bounced. System Libraries: Stub Generator No Status. KERNEL32 No Status. Identification of remaining libraries No Status. Milestones: Working: Kernel R13 Brain Palmer Est: 01/01/1999 Boot loader improvements NASM new release compatability Buffered I/O bugfix VFAT R1 Jason Filby Est: 01/01/1999 IDE R2 Rex Jolliff Est: 10/31/1998 Second release will fix the 255 sector read limitation and add timeout detection code. Complete: IDE R1 Rex Jolliff Est: 10/15/1998 Act: 09/20/1998 First release will locate up to 8 drives, make available devices for the raw device and all dos compatable partitions and read and write using non DMA I/O. Kernel R12 David Welch Est: 09/31/1998 Act: 10/04/1998 New: Multiple processes System calls (this is already working) Improved multithreading support Support for additional filesystem operations Some support for disk caching On Hold: Killed:

1 0

Re: [ros-dev] [ros-diffs] [cfinck] 28423: - Always include"wine/unicode.h" before all other headers, when we need the wchar_t type. unicode.h includes windef.h, which includes winnt.h, which has the handling for the wchar_t type. As it's the firstinc
by Steven Edwards 22 Aug '07

22 Aug '07

On 8/19/07, Colin Finck <mail(a)colinfinck.de> wrote: > These changes were made to properly compile ReactOS under a Mac OS X host. > They have nothing to do with MSVC or the Microsoft SDK headers. Sorry I was not clear about what I meant in my rant and sounded bitchy > Mac OS X defines its own wchar_t type in "ctype.h". But it uses _WCHAR_T for > reporting that the type has been defined and not _WCHAR_T_DEFINED like > Windows does. > This is why I needed to add a handling for _WCHAR_T in "winnt.h". > But if "ctype.h" is now included before "winnt.h", these changes don't have > any effect. This is why I changed the header order. > > Of course, there might be other "solutions" to this problem (like adding all > possible definitions that wchar_t has been defined into the Makefile), but > this is the simplest one. > And I see no reason not to do this for fixing this problem. It makes anyone doing a diff have more stuff to have to workaround. There are constantly minor updates and fixes to the unicode tables in Wine because Microsoft did not just generate them from the uncode.org spec but added a bunch of stuff. Wine currently builds on OS X with the header order as it stands and figures out someway around it. I guess its using a define in the makefile for _WCHAR_T generated by configure or something. I have not looked so don't quote me on that. I don't really care if you want to change it to make it less of a hassle to build on OS X for ReactOS but its just going to break again next time someone syncs the unicode lib so its better if you can work around it in the makefile. -- 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

6 15

Re: [ros-dev] [ros-diffs] [fireball] 28448: - Allow pci read/writes during proving BAR's size operation
by Aleksey Bragin 22 Aug '07

22 Aug '07

Hi, sorry - no, this is an olpc-specific code in olpc branch, I have to emulate some PCI hardware (the code is taken from Linux), however ReactOS's PCI access is more complicated, and thus I slightly improved the code. As for that crash - hmm. I will try the real hardware today maybe. WBR, Aleksey Bragin. On Aug 22, 2007, at 7:31 AM, James Tabor wrote: > Hi! > Could this be related to 28448? I mean could it fix this? The > buffer address > goes down from 8XXXXX to 3fffff (yes backwards, I watch it) and > faults. > This fault was before 28448 and on real hardware. Display is normal > and mouse > moves. > Thanks, > James > > Unhandled exception > ExceptionCode: c0000005 > Faulting Address: 3fffff > Address: 78010e04 C:\ReactOS\system32\msvcrt.dll > CS:EIP 1b:78010e04 > DS 23 ES 23 FS 3b GS 0 > EAX: 0010ad41 EBX: 003fffff ECX: 00001000 > EDX: 009a2068 EBP: 0087f5b4 ESI: 00000002 ESP: 0087f5a0 > EDI: 009a2068 EFLAGS: 00010217 > Frames: > 78000000+122c6 C:\ReactOS\system32\msvcrt.dll > 400000+742eb C:\ReactOS\explorer.exe > 400000+609f4 C:\ReactOS\explorer.exe > > _write lib/sdk/crt/io/write.c Line 55 > . > . > . > while (_nbyte--) { > ----> if (*in == 0x0a) { > . > . > . > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev

1 0

[ros-diffs] [fireball] 28448: - Allow pci read/writes during proving BAR's size operation
by James Tabor 22 Aug '07

22 Aug '07

Hi! Could this be related to 28448? I mean could it fix this? The buffer address goes down from 8XXXXX to 3fffff (yes backwards, I watch it) and faults. This fault was before 28448 and on real hardware. Display is normal and mouse moves. Thanks, James Unhandled exception ExceptionCode: c0000005 Faulting Address: 3fffff Address: 78010e04 C:\ReactOS\system32\msvcrt.dll CS:EIP 1b:78010e04 DS 23 ES 23 FS 3b GS 0 EAX: 0010ad41 EBX: 003fffff ECX: 00001000 EDX: 009a2068 EBP: 0087f5b4 ESI: 00000002 ESP: 0087f5a0 EDI: 009a2068 EFLAGS: 00010217 Frames: 78000000+122c6 C:\ReactOS\system32\msvcrt.dll 400000+742eb C:\ReactOS\explorer.exe 400000+609f4 C:\ReactOS\explorer.exe _write lib/sdk/crt/io/write.c Line 55 . . . while (_nbyte--) { ----> if (*in == 0x0a) { . . .

1 0

Re: [ros-dev] IoCheckEaBufferValidity
by Aleksey Bragin 21 Aug '07

21 Aug '07

Hello, please provide your real name (this is a must for every commit), and also how to test it under Windows (maybe you wrote some test app for this - it would be useful too). WBR, Aleksey Bragin. On Aug 21, 2007, at 3:39 AM, netzimme(a)aim.com wrote: > Hallo > > Have a patch that implemented the function IoCheckEaBufferValidity > in ntoskrnl\io\iomgr\util.c. > Tested with Windows 2000 and Vista Ultimate 64 Bit. > Perhaps some one can comit it for me. > > Thanks > dz >

2 2

IoCheckEaBufferValidity
by netzimme＠aim.com 21 Aug '07

21 Aug '07

Hallo Have a patch that implemented the function IoCheckEaBufferValidity in ntoskrnl\io\iomgr\util.c. Tested with Windows 2000 and Vista Ultimate 64 Bit. Perhaps some one can comit it for me. Thanks dz ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. =================================================================== --- file.c (revision 28441) +++ file.c (working copy) @@ -1632,6 +1632,7 @@ IN ULONG Options) { KPROCESSOR_MODE AccessMode; + ULONG EaErrorOffset; HANDLE LocalHandle = 0; LARGE_INTEGER SafeAllocationSize; PVOID SystemEaBuffer = NULL; @@ -1732,10 +1733,10 @@ /* Validate the buffer */ Status = IoCheckEaBufferValidity(SystemEaBuffer, EaLength, - NULL); + &EaErrorOffset); if (!NT_SUCCESS(Status)) { - /* FIXME: Fail once function is implemented */ + DPRINT1("FIXME: IoCheckEaBufferValidity failed with Status: %lx\n",Status); } } } Index: util.c =================================================================== --- util.c (revision 28441) +++ util.c (working copy) @@ -129,8 +129,9 @@ return STATUS_SUCCESS; } + /* - * @unimplemented + * @implemented */ NTSTATUS NTAPI @@ -138,10 +139,58 @@ IN ULONG EaLength, OUT PULONG ErrorOffset) { - UNIMPLEMENTED; - return STATUS_NOT_IMPLEMENTED; + PFILE_FULL_EA_INFORMATION EaBufferEnd; + ULONG LenOfEaBuffer; + UINT IntEaLength; + + IntEaLength = EaLength; + EaBufferEnd = EaBuffer; + + while (IntEaLength >= 8) + { + LenOfEaBuffer = EaBufferEnd->EaNameLength+EaBufferEnd->EaValueLength + 9; + if (IntEaLength >= LenOfEaBuffer) + { + if (EaBufferEnd->EaName[EaBufferEnd->EaNameLength]==0) + { + if (EaBufferEnd->NextEntryOffset == 0) + { + IntEaLength = IntEaLength - LenOfEaBuffer; + if (IntEaLength>=0) + { + return STATUS_SUCCESS; + } + } + else + { + LenOfEaBuffer = ((LenOfEaBuffer + 3) & 0xFFFFFFFC); + if (EaBufferEnd->NextEntryOffset == LenOfEaBuffer) + { + if (EaBufferEnd->NextEntryOffset>0) + { + IntEaLength = IntEaLength - EaBufferEnd->NextEntryOffset; + if (IntEaLength>=0) + { + LenOfEaBuffer = EaBufferEnd->NextEntryOffset; + EaBufferEnd = (PFILE_FULL_EA_INFORMATION)((PBYTE)EaBufferEnd + LenOfEaBuffer); + continue; + } + } + } + } + } + } + break; + } + if (ErrorOffset != NULL) + { + *ErrorOffset = (ULONG)((PBYTE)EaBufferEnd - (PBYTE)EaBuffer); + } + + return STATUS_EA_LIST_INCONSISTENT; } + /* * @unimplemented */

2 2

Re: [ros-dev] [ros-diffs] [cfinck] 28423: - Always include "wine/unicode.h" before all other headers, when we need the wchar_t type. unicode.h includes windef.h, which includes winnt.h, which has the handling for the wchar_t type. As it's the first included he
by Steven Edwards 19 Aug '07

19 Aug '07

On 8/19/07, cfinck(a)svn.reactos.org <cfinck(a)svn.reactos.org> wrote: > - Always include "wine/unicode.h" before all other headers, when we need the wchar_t type. Please stop changing the header order. If you need to do this then something is wrong. The Wine headers are mostly correct as far as the PSDK/WDK goes and if you build Wine on MSVC you DO NOT have to make these invasive changes to the source even when using the SDK headers. Fix the ROS headers or work around system limitations some other way. -- 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

2 1

Freedom
by James Tabor 19 Aug '07

19 Aug '07

Hi, I want ReactOS to become free again. From gnu.org, Free software is a matter of the users' freedom to run, copy, distribute, study, change and improve the software. More precisely, it refers to four kinds of freedom, for the users of the software: * The freedom to run the program, for any purpose (freedom 0). * The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this. * The freedom to redistribute copies so you can help your neighbor (freedom 2). * The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this. We forget what this is all about. We need to be liberated from the shackles and chains. Replace "Tainted Developers" with this: Referring to Proprietary Programs: Don't in any circumstances refer to any closed source proprietary code for or during your work on ReactOS! (Or to any other proprietary programs, Unix, Novel, Solaris, Microsoft,.) If you have a vague recollection of the internals of a closed source program, this does not absolutely mean you can't write an imitation of it, but do try to organize the imitation internally along different lines, because this is likely to make the details of the software version irrelevant and dissimilar to your results. It's from: http://www.gnu.org/prep/standards/html_node/Reading-Non_002dFree-Code.html#… If is good for FSF/GNU it's good enough for us. I don't think we need to vote on this, just change it! Remember this is GNU/ReactOS! Not SFLC/Wine! Thanks, James

3 2

Remote desktop on ROS
by Gabriel ilardi 15 Aug '07

15 Aug '07

Dear Devs, I've tested a win32 port of rdesktop for linux, and it works in current trunk (http://img440.imageshack.us/my.php?image=rdesktop3hi1.jpg), since our rdp client doesn't work, I was wondering if this one could be included instead, it's released under gpl, perhaps adding a gui, I don't think it's a lot of work, correct me if I'm wrong, you can find the sources here: http://os.american-data.com/rdesktop/win32/ Best regards, gabriel_it Have a nice day! _________________________________________________________________ Scarica GRATIS Internet Explorer 7 personalizzato MSN http://optimizedie7.msn.com/default.aspx?mkt=it-it

1 0

Re: [ros-dev] [ros-diffs] [gedmurphy] 28324: - fix the code, untested *note, shouldn't this be in rosapps?
by Aleksey Bragin 14 Aug '07

14 Aug '07

This should go into rosapps, unless it's being used during the setup process for example (which it is not). WBR, Aleksey Bragin. On Aug 14, 2007, at 12:52 AM, gedmurphy(a)svn.reactos.org wrote: > Author: gedmurphy > Date: Tue Aug 14 00:52:47 2007 > New Revision: 28324 > > URL: http://svn.reactos.org/svn/reactos?rev=28324&view=rev > Log: > - fix the code, untested > *note, shouldn't this be in rosapps? > > Modified: > trunk/reactos/base/applications/network/dwnl/dwnl.c > trunk/reactos/base/applications/network/dwnl/dwnl.rbuild >

1 0

disussion from forum
by 3th.voice＠googlemail.com 13 Aug '07

13 Aug '07

Hi ReactOS guy's, are you not able to discuss a topic in your forum or why did you delete my post in http://www.reactos.org/forum/viewtopic.php?t=4307 ? Here is it again: [quote="jimtabor"] The irc meetings, there are two I think. It was voting on how to do the audit. Later if I remember right, we started movie review and joking around with unrelated issues. [/quote] I'm missing something about the meetings. [url= http://www.reactos.org/archives/public/ros-dev/2006-January/007478.html]Ste…'s mail[/url] starts with: [quote="Steven Edwards"] There has been a lot of talk about possible tainted code in ReactOS and or developers that had access to leaked Microsoft source code. [/quote] and later [quote="Steven Edwards"] We know of four developers who have had access to leaked sources prior to working on ReactOS.. [/quote] Depend on the [url=http://www.reactos.org/en/dev_legalreview.html]ReactOSproject development policy[/url] [quote="ReactOS project development policy"] Developers who have had access to proprietary source code that would have originally fallen under trade secret protection (including, for example, the leaked Microsoft Windows source code) are a special case. The copyright issues are unchanged, as are the patent issues, but any developer who has the code is clearly either under an NDA or else does not have a license to possess the code. In the latter case, there is a clear violation of the relevant trade secrets by the developer. As such, this kind of code is unsuitable even for research and understanding. It is the policy of the Project to not take submissions from developers who have or use any such proprietary code in their development efforts for ReactOS. [/quote] this developers have to be banned from the project. Steven's mail or the developer's voting wasn't so restrictive: [quote="Steven Edwards"] 4) any developer that had access to leaked sources is baned from contributing code to the project for any of the modules that are the same as leaked sources they examined. [/quote] The question is, why are the tainted developers not banned? If only a few of the developers had access to the leaked windows source code, it is not a problem to ban them. I think more than four developers had access to the leaked windows source code. In this case it will never get a vote for banning the tainted developers, because they must ban itself. It exists the 'Open letter to all' from Alex. I've got the original mail with all the names from one of the developers. [quote="Alex's 'Open letter to all'"] /*Steven, Aleksey, Mike and myself had leaked windows code and looked at it. KJK, Eric, Filip, Magnus and Marteen had IDA and used it for reverse engineering. 9 developers, and these are only some cases.*/ Herve too, sometimes used IDA to verify some flags (I once helped him understand a weird DEVICE_EXTENSION structure), and Thomas, although against reverse-engineering, also used IDA to verify some implementations, although he said he never used it to actually reverse-engineer, and I believe him, although, once you have seen the taint, it's hard to really psycologically prove how much you were, or were not influenced by it. /*With more then 2/3rds of the entire developer team having broken the law and/or our IP policy, I continued my work in the same way.*/ [/quote] Now the story make sense. The implementation of ReactOS is based on the leaked windows source code and possible more than the four named developers had or have access to this code. [quote="jimtabor"] As you all can see, things have gone on to this project. Money was the key word here. Wine, Casper, GvG, hbirr etc,,, mass manipulation to gain from other peoples work. [/quote] And now it makes sense why you accuse some of the developers, which had left the project, that they have done something for money... The only developer, which has something to do with money, is Alex. In May he was bought by Microsoft.

1 0

When will ROS 0.3.3 comming out ?
by theUser BL 13 Aug '07

13 Aug '07

Hi! When will ROS 0.3.3 comming out? On July, 21th you anounced 0.3.3 RC1 at http://www.reactos.org/archives/public/ros-dev/2007-July/009571.html You have also changed the front-page, that the actual version is 0.3.3 RC1 and on the downloadside there is now also only 0.3.3 RC1. Will 0.3.3 any time really comming or existing now 0.3.3 RC1 for it instead and the next one will be 0.3.4 ? Btw: On the download-side the links to the CD-Booklets don't exists. It showns now to 0.3.3-RC booklets, but the only one which exists are 0.3.1 booklets. Greatings theuserbl _________________________________________________________________ Sie suchen E-Mails, Dokumente oder Fotos? Die neue MSN Suche Toolbar mit Windows-Desktopsuche liefert in sekundenschnelle Ergebnisse. Jetzt neu! http://desktop.msn.de/ Jetzt gratis downloaden!

2 1

RosBE and autogenerated files
by Sylvain Petreolle 13 Aug '07

13 Aug '07

Hi all, I wonder if the RosBE-Windows must be the one which removes autogenerated files. In this case , we have to : - merge the list into RosBE-Unix - publish updated versions when the list changes. - last but not least, the user must have the svn versions of RosBE to get a completely clean tree. Colin suggested we can put it into the Makefile, which would be simpler and more efficient. Kind regards, Sylvain Petreolle (aka Usurp) --- --- --- --- --- --- --- --- --- --- --- --- --- Run your favorite Windows apps with free ReactOS : http://www.reactos.org Listen to non-DRMised Music: http://www.jamendo.com

1 0

Betov is move againts nasm32
by Magnus Olsen 10 Aug '07

10 Aug '07

Hi is betov are moreon or idot or brian dead person I can not longer keep my feeling in shape thanks to him It seam that betov is out damges every good open source project on the market. Let see now which project he is trying damges 1.ReactOS It is well known he dislike us, and my advice we ignore him it seam he does not known what his is talking about, and it seam in my eyes his claim is not vaild 2. Sano ReactOS borro some code from this project and that code betov trying convice it is illage 3. SDL Almost same code can be found in SDL for same part we talking about, the code are almost same as Sano code. That mean Betov trying destor this project as well 4. Nasm32 what he have gone after NASM 32, now and claim it is illage for they do not ship the source code in the binary. or the licen agreemtn, and some other stuff more we can read about his stupied http://groups.google.com/group/alt.lang.asm/browse_thread/thread/35cd7e11ff… it is not wonder people do not take him serius he is like a big moron and trying sabtages opensource project world wide for people do not support his rosasm project. And I have follow now his writting for few month and more I read, more it seam it is something wrong with his brain. he calling people with bad names and attact people when they ask him simple question, it mean he socal skill is bad or is is brain dead, that is my cludtions after reading his vaurs stuff he writitning on the net. Or even better bethov is getting pay leading sabtages agaist opensource project that is well known, He maybe getting pay from MS/DMCA/NOVELL how knowns, but it seam not in this case it seam he is complete brian dead.

1 0

crash in rbuild creating vcproj
by ich 09 Aug '07

09 Aug '07

Hello list, I'm new here, so at first I'd like to greet everyone ;) second: I had some problems running rbuild on WinXP SP2 self compiled with msvc 8.0 (Express) to produce .vcproj files. I've found the problem in vcprojmaker.cpp and another thing, which prevents me from building rbuild in genguid.cpp and I would like to contribute a patch. Kind regards, Michael Sprauer

1 0

Re: [ros-dev] RosBuild Release Build Problem
by Aleksey Bragin 09 Aug '07

09 Aug '07

Fixed in 28257. WBR, Aleksey Bragin. On Aug 9, 2007, at 9:37 AM, James Tabor wrote: > ./include/internal/kd.h:212:KdpKdbgInit( > > obj-i386/ntoskrnl/kd/kdinit.o: In function `KdInitSystem@8': > /mnt/reactos/fullrel/build/ntoskrnl/kd/kdinit.c:(.data+0x24): > undefined reference to `_KdpKdbgInit@8'

1 0

XP, System Call List, Wrong size?
by James Tabor 09 Aug '07

09 Aug '07

From the SDK! Come on! get upto date! W32KAPI BOOL APIENTRY NtGdiAlphaBlend( __in HDC hdcDst, __in LONG DstX, __in LONG DstY, __in LONG DstCx, __in LONG DstCy, __in HDC hdcSrc, __in LONG SrcX, __in LONG SrcY, __in LONG SrcCx, __in LONG SrcCy, __in BLENDFUNCTION BlendFunction, __in HANDLE hcmXform // I saw a zero here. ); We have this in psdk/ntgdi.h W32KAPI BOOL APIENTRY NtGdiSetIcmMode( IN HDC hdc, IN ULONG nCommand, // see below,,,, I saw 1 -> 4 here. IN ULONG ulMode ); /* NtGdiSetIcmMode */ #define ICM_SET_MODE 1 #define ICM_SET_CALIBRATE_MODE 2 #define ICM_SET_COLOR_MODE 3 #define ICM_CHECK_COLOR_MODE 4 Using a good hook and compare eax to the list will set you free. James

1 0

RosBuild Release Build Problem
by James Tabor 09 Aug '07

09 Aug '07

./include/internal/kd.h:212:KdpKdbgInit( obj-i386/ntoskrnl/kd/kdinit.o: In function `KdInitSystem@8': /mnt/reactos/fullrel/build/ntoskrnl/kd/kdinit.c:(.data+0x24): undefined reference to `_KdpKdbgInit@8' ntoskrnl/include/internal/ntoskrnl.h: #include "ldr.h" #ifndef _WINKD_ #include "kd.h" #else #include "kd64.h" #endif #include "fsrtl.h" ntoskrnl.rbuild : snip.... <define name="_IN_KERNEL_" /> <if property="_WINKD_" value="1"> <define name="_WINKD_" /> snip.... <file>pnproot.c</file> </directory> </directory> <if property="_WINKD_" value="0"> <directory name="kdbg"> <if property="ARCH" value="i386"> snip.... <file>kdmain.c</file> </directory> </if> <if property="_WINKD_" value ="1"> <directory name="kd64"> <file>kdapi.c</file> snip.... Does this help in finding the problem? James

1 0

rev 28153 (obhandle.c)
by Timo Kreuzer 08 Aug '07

08 Aug '07

rev 28153 (obhandle.c) breaks bootcd with KDBG = 1 "Assertion 'HandleTable->HandleCount == 0' failed at ntoskrnl\ob\obhandle.c line 2034"

1 0

r28205 : Empty ntoskrnl/ke/i386/init.S in trunk
by Sylvain Petreolle 07 Aug '07

07 Aug '07

After r28205, ntoskrnl/ke/i386/init.S has no more contents and is removed from build. Remove it from trunk too. Kind regards, Sylvain Petreolle (aka Usurp) --- --- --- --- --- --- --- --- --- --- --- --- --- Run your favorite Windows apps with free ReactOS : http://www.reactos.org Listen to non-DRMised Music: http://www.jamendo.com

1 0

Re: [ros-dev] CRT source code issue
by Aleksey Bragin 06 Aug '07

06 Aug '07

Yes, the whole issue is at pushing operands to stack, performing well- documented assembly instructions to perform the asked action (div, mul, shl, shr, etc), and handling some special, though obvious, cases (like if you do a shl of some longlong number by more than 64 bits, you always end up with 0, there is no need to call math instructions in order to compute this). I will let you know results when I speak with SDL. WBR, Aleksey Bragin. On Aug 4, 2007, at 8:52 PM, Daniel Hazelton wrote: > On Saturday 04 August 2007 12:28:09 Aleksey Bragin wrote: > > I can't see where that file has anything to do with the functions > (e.g: > sqrt()/alldiv()) that Betov claims are duplicated. (I've gone > through that > file and can't find any single place where it does any more math than > controlled bit-shifts. No advanced math or anything.) > > While there might be similar code, for, say, memory barriers, that > codes > construction would be dictated by the specification of the target > machine > (and, to some extent, the OS). If the code for sqrt/alldiv is the same > between SDL/ROS I don't see a problem - they are both GNU projects > and "cross > pollination" like that is legal. > > Whats more is that, while assembly is abstract enough to let some > things be > done in more than one way, most of the more complex functionality - > like math > algorithms - are so limited in the possibilities of variation that > I can > easily see two unconnected people arriving at the exact same > solution. QED: > Even if the code appears identical (except for things like variable > names, > et. al) there is a compelling reason for it and it does not mean > the code has > been copied in any way, shape or form. (And if you look at the ROS > commit > history I'm sure the code in question existed before MS released > the SSCLI2.0 > source. Which means that the code can't be an "illegal use of MS > property" - > it was around before said property was available). > > ...Okay, enough of this outsider sticking his neck out. I've said > enough and > it's time to disappear and wait for a really usable version of ROS > to hit. > (though I have compared it to XP under Qemu and ROS rocks!) > > DRH

1 0

Re: [ros-dev] CRT source code issue
by Aleksey Bragin 04 Aug '07

04 Aug '07

Just so people don't build up rumours, this code is located in SSCLI 2.0, in the file clr/src/vm/i386/jithelp.asm . Function names are different, however assembly code is similar. License issues are not fully cleared up, so opinions from people having knowledge in this area are welcome. WBR, Aleksey Bragin. On Aug 4, 2007, at 7:52 PM, Daniel Hazelton wrote: > On Saturday 04 August 2007 04:32:32 Mike Swanson wrote: >> On Friday 03 August 2007 16:28:21 Daniel Hazelton wrote: >>> unless you hold full copyright to the software (ie: you are the >>> one who >>> has released it under the GPL) then there is no way you can >>> distribute it >>> for commercial purposes. (You can make money to cover >>> distribution costs >>> and/or make money from support but not off the software itself.) >>

2 1

CRT source code issue
by Aleksey Bragin 04 Aug '07

04 Aug '07

Hi, Recently Betov made some accusations regarding possible usage of MS's copyrighted code in ReactOS's CRT library (example lib/sdk/libcntpr/ math/i386/sqrt_asm.s, alldiv_asm.s, and other files). Here is my official statement in regarding to this false accusation: This source code originally was imported into ReactOS from SanOS project, where it was said as having GPL license (all original copyrights are kept). After a lot of complains from Betov (aimed at getting attention to his own project, not at improving ReactOS), developers thought it worths looking into the issue deeper. I performed some investigation, and found that SDL project (www.libsdl.org) has the same code in trunk and in v1.2 branch (http://www.libsdl.org/cgi/viewvc.cgi/trunk/SDL/src/stdlib/ SDL_stdlib.c?view=markup). Everyone can compare asm source code with respective functions found in MSVC's CRT source code. It matches up to label names, however numbers have been converted from dec to hex representation. The code in SDL project is marked as "GPL" and author is stated as "Sam Lantinga". It may look like a serious problem, but in reality, the source code of these functions is released by Microsoft in SSCLI 2.0, with a license which allows GPLing of the source code, with one restriction: "You may not use or distribute this Software and any derivative works in any form for commercial purposes.". SSCLI 2.0 can be freely downloaded by everyone, license is also certainly available to read. I'm going to communicate with SDL about this issue, but since ReactOS is not used commercially, it's not a problem for ReactOS now. We are ready to collaborate with SDL on removing this issue, if it's considered a real problem. With the best regards, Aleksey Bragin.

4 4

Re: [ros-dev] ERROR when compiling ROS
by carlo.bramix 03 Aug '07

03 Aug '07

I was finally able to compile and build the boot cd, but setup hangs when doing "Importing hivesys.inf..." But this is another trouble, different from previous one. And I did a complete clean before compiling. Sincerely, Carlo Bramini ---------- Initial Header ----------- >From : ros-dev-bounces(a)reactos.org To : "ros-dev" ros-dev(a)reactos.org Cc : Date : Fri, 3 Aug 2007 18:21:36 +0200 Subject : Re: [ros-dev] ERROR when compiling ROS > It seems that the very last change fixed my problem. > > C:\RosBE>svn up > U tools\rbuild\wineresource.cpp > Aggiornato alla revisione 28138. > > Sincerely, > > Carlo Bramini > > ---------- Initial Header ----------- > > >From : ros-dev-bounces(a)reactos.org > To : "ReactOS Development List" ros-dev(a)reactos.org > Cc : > Date : Fri, 3 Aug 2007 17:55:10 +0200 > Subject : Re: [ros-dev] ERROR when compiling ROS > > > Hi, > > > > There were some changes in the build system today. > > Please first try to update to *latest* trunk and then do a complete clean > > build. > > > > If this doesn't help, you can either try to delete all autogenerated files > > yourself, which were not deleted by the "clean" script or get a complete new > > checkout. > > > > I can build recent trunk (r28138) and our BuildBot has no problems as well > > now. > > > > Regards, > > > > Colin > > > > > > > -----Original Message----- > > > From: ros-dev-bounces(a)reactos.org > > > [mailto:ros-dev-bounces@reactos.org] On Behalf Of carlo.bramix > > > Sent: Friday, August 03, 2007 5:32 PM > > > To: ros-dev > > > Subject: [ros-dev] ERROR when compiling ROS > > > > > > Hello, > > > Today I wasn't able to compile ROS. > > > I got this error: > > > > > > [RBUILD] makefile.auto > > > Processing failed: No such file or directory > > > > > > Sincerely, > > > > > > Carlo Bramini > > > > > > > > > > > > ------------------------------------------------------ > > > Scegli infostrada: ADSL gratis per tutta l'estate e telefoni > > > senza canone Telecom > > > http://click.libero.it/infostrada > > > > > > > > > _______________________________________________ > > > Ros-dev mailing list > > > Ros-dev(a)reactos.org > > > http://www.reactos.org/mailman/listinfo/ros-dev > > > > _______________________________________________ > > Ros-dev mailing list > > Ros-dev(a)reactos.org > > http://www.reactos.org/mailman/listinfo/ros-dev > > > > > ------------------------------------------------------ > Scegli infostrada: ADSL gratis per tutta lestate e telefoni senza canone Telecom > http://click.libero.it/infostrada > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ------------------------------------------------------ Scegli infostrada: ADSL gratis per tutta lestate e telefoni senza canone Telecom http://click.libero.it/infostrada

2 1

Re: [ros-dev] ERROR when compiling ROS
by carlo.bramix 03 Aug '07

03 Aug '07

It seems that the very last change fixed my problem. C:\RosBE>svn up U tools\rbuild\wineresource.cpp Aggiornato alla revisione 28138. Sincerely, Carlo Bramini ---------- Initial Header ----------- >From : ros-dev-bounces(a)reactos.org To : "ReactOS Development List" ros-dev(a)reactos.org Cc : Date : Fri, 3 Aug 2007 17:55:10 +0200 Subject : Re: [ros-dev] ERROR when compiling ROS > Hi, > > There were some changes in the build system today. > Please first try to update to *latest* trunk and then do a complete clean > build. > > If this doesn't help, you can either try to delete all autogenerated files > yourself, which were not deleted by the "clean" script or get a complete new > checkout. > > I can build recent trunk (r28138) and our BuildBot has no problems as well > now. > > Regards, > > Colin > > > > -----Original Message----- > > From: ros-dev-bounces(a)reactos.org > > [mailto:ros-dev-bounces@reactos.org] On Behalf Of carlo.bramix > > Sent: Friday, August 03, 2007 5:32 PM > > To: ros-dev > > Subject: [ros-dev] ERROR when compiling ROS > > > > Hello, > > Today I wasn't able to compile ROS. > > I got this error: > > > > [RBUILD] makefile.auto > > Processing failed: No such file or directory > > > > Sincerely, > > > > Carlo Bramini > > > > > > > > ------------------------------------------------------ > > Scegli infostrada: ADSL gratis per tutta l'estate e telefoni > > senza canone Telecom > > http://click.libero.it/infostrada > > > > > > _______________________________________________ > > Ros-dev mailing list > > Ros-dev(a)reactos.org > > http://www.reactos.org/mailman/listinfo/ros-dev > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ------------------------------------------------------ Scegli infostrada: ADSL gratis per tutta lestate e telefoni senza canone Telecom http://click.libero.it/infostrada

1 0

ERROR when compiling ROS
by carlo.bramix 03 Aug '07

03 Aug '07

Hello, Today I wasn't able to compile ROS. I got this error: [RBUILD] makefile.auto Processing failed: No such file or directory Sincerely, Carlo Bramini ------------------------------------------------------ Scegli infostrada: ADSL gratis per tutta lestate e telefoni senza canone Telecom http://click.libero.it/infostrada

2 1

Bug #2217 fixed
by carlo.bramix 03 Aug '07

03 Aug '07

The patch (attached into that bug) fixes the signaled defect. Sincerely, Carlo Bramini. ------------------------------------------------------ Scegli infostrada: ADSL gratis per tutta lestate e telefoni senza canone Telecom http://click.libero.it/infostrada

1 0

Fwd: Re: setup's fat32 format
by Paul Dufresne 02 Aug '07

02 Aug '07

On Tue, 31 Jul 2007 05:47:22 +0100 (BST), "CK Raju" <ckraju68(a)yahoo.co.in> said: > But is the process of recognising other partitions > stable ? Can ReactOS be installed in extended > partitions ? Does it recognise extended partitions now > ? These are the questions that will be eliminated with > adoption of a cross-installer. It did break the partition table I had the 2 times I have tried on real hardware. The two times, I had Ubuntu installed in logical partitions. Each times, it see my 10Gb as 4Gb, and give a warning it does not understand correctly my partition table. First time, it did seems to see some unused space (there was probably none in reality) and I let it installed there, stopping just before installing the boot loader (I wanted to use grub to start it). But when I tried to reboot, computer was unable to boot, not even go to the BIOS. Reinitializing CMOS or reflashing BIOS did not help. Finally discover that unplugging the HD fixed the BIOS. Probably a BIOS bug, expecting a correct MBR and partition table. Next time (about 1 week ago), I had made a primary partition for it, and still have Linux on logical one. But it seems to have break the partition table once again (not sure how I convinced myself of that however, I think because I was not able to search for /boot/grub/menu.lst from grub on hd0). I was given on a link in IRC about an unfinished patch on hyperheterodyne, or superheterodyne... that was about the partition manager. Was 1 or 2 years old however. I read it a bit, patch and code for usetup?, but not good enough yet to really understand. So I consider the installer very dangerous right now. -- http://www.fastmail.fm - Send your email first class

3 3

Re: [ros-dev] [ros-diffs] [greatlrd] 28055: user32 cleanup lite redirect the InvalidateRect@12 to NtUserInvalidateRect@12 in the def file nci tools changes (done of timo and me) frist part moving the w32ksvc.db and sysfuncs.lst where they belong
by Aleksey Bragin 01 Aug '07

01 Aug '07

Let's try to calm down the emotions, otherwise people may be offended :-) I know Jim is the one who, I think, *never* commited a patch that breaks something (testing a patch before commiting for one week - easy), but we have to tolerate that other people (including myself) tend to do mistakes from time to time. WBR, Aleksey Bragin. On Aug 1, 2007, at 11:38 PM, Ged wrote: > James Tabor wrote: >> Man! You are right! The newbies are creating more work for me at >> every >> turn! I wish they would stop committing on crack! >> >> Thank you for the extra work! >> > > That's rather harsh and partonising! > These so called 'newbies' have done a great deal of good work > recently. > > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev

3 2

Re: [ros-dev] Vacation
by Aleksey Bragin 01 Aug '07

01 Aug '07

Thanks for all wishes, I really had a nice vacation in Montenegro (I'll maybe post some photos soon). Great work on the reactos tree, ros-diffs sounds very promising. I'm fully back into ReactOS by tomorrow. WBR, Aleksey Bragin. On Jul 24, 2007, at 10:08 PM, Aleksey Bragin wrote: > Hello, > I'll be on vacation, starting from tomorrow (25th of July) and > lasting till 1st of August. > > > > Have fun with development while I'm away! > > WBR, > Aleksey Bragin. > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev

1 0

Re: [ros-dev] [ros-diffs] [greatlrd] 28055: user32 cleanup lite redirect the InvalidateRect@12 to NtUserInvalidateRect@12 in the def file nci tools changes (done of timo and me) frist part moving the w32ksvc.db and sysfuncs.lst where they belong
by Aleksey Bragin 01 Aug '07

01 Aug '07

So, is it reverted? iirc, I even marked those files as "shared with Wine" in the README.WINE file. I did the merging of Wine changes once or twice there, and it's not a big fun to go change-by-change, trace revision when it was changed, look up why and was it a necessary change or not. WBR, Aleksey Bragin. On Aug 1, 2007, at 11:05 AM, Thomas Weidenmueller wrote: > No it's not worth the hazzle because those changes result in *NO* > optimizations anyway. The code that was changed were calls to > InvalidateRect to NtUserInvalidateRect. Since InvalidateRect is > already > forwarded to NtUserInvalidateRect this doesn't really improve > anything, > it's the same overhead. These changes should be reverted, not just > because it makes no sense to optimize these function calls even more > because they're absolutely not time-critical. > > Please revert. > > - Thomas > > Steven Edwards wrote: >> On 7/31/07, greatlrd(a)svn.reactos.org <greatlrd(a)svn.reactos.org> >> wrote: >>> user32 cleanup lite >>> redirect the InvalidateRect@12 to NtUserInvalidateRect@12 in the >>> def file >> >>> Modified: >>> trunk/reactos/dll/win32/user32/controls/button.c >>> trunk/reactos/dll/win32/user32/controls/combo.c >>

1 0

Re: [ros-dev] [ros-diffs] [greatlrd] 28055: user32 cleanup lite redirect the InvalidateRect@12 to NtUserInvalidateRect@12 in the def file nci tools changes (done of timo and me) frist part moving the w32ksvc.db and sysfuncs.lst where they belong
by Steven Edwards 01 Aug '07

01 Aug '07

On 7/31/07, greatlrd(a)svn.reactos.org <greatlrd(a)svn.reactos.org> wrote: > user32 cleanup lite > redirect the InvalidateRect@12 to NtUserInvalidateRect@12 in the def file > Modified: > trunk/reactos/dll/win32/user32/controls/button.c > trunk/reactos/dll/win32/user32/controls/combo.c Is it really worth the merge hassle to change it in these two files? They are almost 100% shared with Wine and I doubt the overhead in calling InvalidateRect vs NtUserInvalidateRect is worth the hassle on whoever the maintainer is going to be.... -- 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

4 3

[ros-diffs] [tkreuzer] 28069: implement Arc, ArcTo, Chord, calling NtGdiArcInternal
by James Tabor 01 Aug '07

01 Aug '07

Hi, Why did you do it like this? Arc, etc,, has already been writing in painting.c. Thanks, James

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev