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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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






[Index of Archives]     [Gimp for Windows]     [Red Hat]     [Samba]     [Yosemite Camping]     [Graphics Cards]     [Wine Home]

  Powered by Linux