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