wine users - Feb 2009 - Can I use EXPORT in a def file to export Dll's functions?

As it looks from the title, I found that the wineHQ source code has another way
to export functions from DLL files and it calls the definition files like:

FileName.spec

I used to use the:

FileName.def

Of course under XP.

So is it something refers to the compiler and it must respect this order or I
can use the old school style I'm used to back in the days, because I find it
kinda annoying to specify each function's parameters types like:


Code:
@ stdcall AccessCheck(ptr long long ptr ptr ptr ptr ptr)



Instead of just using the Win form like:


Code:

EXPORTS

AccessCheck




Or can I modify how the compiler should work towards this issue if this is stuck
in its options & rules?

Plz forgive my lack of info and be patient with me, I'm getting used to get
in touch with the code.

I wish everybody here a nice day.

I have another question about APIs.

By looking at some source codes and navigating through MSDN and other sites, I
couldn't understand why should we use Aliases to other APIs, I mean why we
didn't use the original API without passing through an Alias especially when
we speak about the Heap's ones or the NTDLL's, there is no harm in that
at all, plus it will look & feel better & neat, Or may be it will
resolve some problems caused in other Apps installations? is it possible?

Right now I'm trying to re-write some code and I know it may look just a
waste of time but who knows I believe it worth to be tried even if it won't
change anything, it won't mess it up.

> No, this is called paying to code by the line.  The more lines of code,
> the greater your paycheck.  This has been a problem with several
> software manufacturers, most are not around anymore.
Wow, it's the first time to hear such a thing, it's kinda odd to measure
softs through how many line they have written in.

> 
> > Another bad fact that I have to deal with it and accept it as it is,
thanks Bill to make things harder to be understood.
> > 
> > I'm messing with the ADVAPI32.DLL and I think I make some
improvements.
> > 
> > 
> > 
> Please keep in mind that you cannot submit code if you looked at the
> Windows source or have reverse engineered any part of the Windows code
> that you are working on.  However, you may post a high level 'this is
> how it works' document so that others can build compliance tests and
> code to those tests.  This is for legal reasons to keep Wine out of the
> courthouse.
> 
> James McKenzie
Yeah, I'm aware of that, I took a good look at the site before, but before
being an Ubuntero I was a total M$ good boy, I spent 3 years in university
working with MFC and reading MSDN so this was a great help for me + we used
reverse engineering too for educational purposes not always for the OS but for
various Applications and I bet every body did, to monitor the different things
such as Buffer OverFlows detection, debugging reasons, system penetration to
ameliorate the security env and writing Payloads, studying the different
architectures and comparing Linux to Win, so OllyDbg was a good friend of us in
that time to track the applications behaviours and that's what we did in the
Lab, I couldn't help it otherwise I would get some descent zeroes.

It's been a while now but I still master the Win32 programing, while I can
say that I'm a newbie for the *nix programing platform, as for now I guess I
can track some mentioned bugs in the bugzilla and work on them since I've
worked on similar issues before and I know what the matter with them and how to
get them fixed, of course I don't need to reverse engineered anything but I
can emulate the API's function to retrieve the same results, that was what
was my research about, and I worked hard on it, but some times I would use the
NASM to get some problems straight (in place of C) if this acceptable alongside
with the C.

So if my university was a problem to my participation to this project I would
suit them for their ugly courses that limited my freedom  [Rolling Eyes]

Absolutely no body wanna see MS knocking the WineHQ doors anywhere and/or
anytime, so if this still make a problem I would keep it for my self or start a
new project then ask some old classmate to join, I'm pretty sure they can do
a lot of great things.

So what do you think James, should I stick to the documentation part or
participate in the code?

And how about parts that I had never got in touched with them before, can I
start over there?

Thanks for mentioning this point and I appreciate your guidance about where
should I participate?