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

[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