Ros-dev

ros-dev@reactos.org

5788 discussions

Re: [ros-dev] Autogenerating compiler specific .def files

by Aleksey Bragin

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

16 years, 9 months

Build is broken as of Eric's change in r30958

by Colin Finck

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

16 years, 10 months

Re: [ros-dev] [ros-diffs] [tkreuzer] 30929: patch by jimtabor: add GdiBCSelObj to GdiFlushUserBatch

by Aleksey Bragin

> + 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; > } > > + > >

16 years, 10 months

ros-diffs] [cwittich] 30916: revert r28932

by James Tabor

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

16 years, 10 months

Re: [ros-dev] [ros-diffs] [cwittich] 30899: remove the const from the DrawShadowText function to be compatible to PSDK

by Steven Edwards

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

16 years, 10 months

Re: [ros-dev] [ros-diffs] [cwittich] 30829: translated some DPRINTs from GreatLordish into a human readable format

by Ged Murphy

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

16 years, 10 months

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

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; > >

16 years, 10 months

Paste service

by Sylvain Petreolle

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

16 years, 10 months

Re: [ros-dev] Autogenerating compiler specific .def files

by Aleksey Bragin

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

16 years, 10 months

Autogenerating compiler specific .def files

by Marc Piulachs

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

16 years, 10 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev