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