Can I use EXPORT in a def file to export Dll's functions?

[OuahabiX]

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

@ stdcall AccessCheck(ptr long long ptr ptr ptr ptr ptr)

Instead of just using the Win form like:

Code: Select all

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.

[OuahabiX]

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.

[vitamin]

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

In short - Wine uses gcc to create it's dlls. And gcc has no concepts of .def file. So it's compiler dependent.

I couldn't understand why should we use Aliases to other APIs

That's what native (windows) does. You should ask MS why they export the same function from several dlls.

[OuahabiX]

Code: Select all

In short - Wine uses gcc to create it's dlls. And gcc has no concepts of .def file. So it's compiler dependent.

Ok, I can live with it, it's not that big deal, just pain in the head.

That's what native (windows) does. You should ask MS why they export the same function from several dlls.

I would say they're insane but I'm discovering now they have done a great work although they're greedy and selfish but they still have brains that really work!

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.

[James McKenzie]

OuahabiX wrote:

That's what native (windows) does. You should ask MS why they export the same function from several dlls.

I would say they're insane but I'm discovering now they have done a great work although they're greedy and selfish but they still have brains that really work!

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.

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

[OuahabiX]

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

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?

[James McKenzie]

OuahabiX wrote:

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.

It was a common practice in the 1980's and 1990's. I hope that it is
not practiced any longer. Some really horrorable code came from it.

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?

I would join the wine-devel mailing list and post there or if you have
access to IRC, go to freenode.net, channel #winehackers. Observe and
then post your question and wait on a reply from Alexandre Julliard. He
is the 'keeper of the code' and would be the best person to ask.

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

See my comment above.

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

You are welcome. It would be very sad to see you write a brilliant bit
of code only to have it rejected because of you prior works. I like to
see new people join in the effort to make Wine a better representation
of the Win32 API.


James McKenzie