Re: LogParser.exe

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

 



On Wed, Apr 13, 2011 at 6:38 AM, StrangeWill <wineforum-user@xxxxxxxxxx> wrote:
> Ok, so an update in case anyone stumbles across this.
>
> I've decided to start removing stubs and putting placeholders in my branched code, seeing what other methods I need... if I needed just
> RtlCreateTagHeap I'd just write it... right?

If only it were that easy, there would be much more of the WindowsAPI
implemented.  That has been said by many in the Wine Development list
(where this is much more on topic.)
>
> Oops wrong.
>
> First, RtlCreateTagHeap isn't documented like RtlCreateHeap is, so to implement it is going to be a pain, even other libraries that have
> RtlCreateTagHeap in them have them as stubs...

Welcome to the Microsoft method of documentation.  I've run into this
with several simple to implement processes.

[snip]
>
> So I'm pretty much looking at having to implement a good chunk of NtQuerySystemInformation for WINE, and I can't even begin to guess how deep
> this rabbit hole goes. Worse yet this has a stub, but is commented out, I wonder why.

Don't know about the comment out of the stub, but to find out how deep
the rabbit hole is when you 'chase the rabbit'.  It could be very deep
or you could find that all you have to implement is this function.

>
> And again, RtlGetNativeSystemInformation seems to be another piece of API that doesn't have documentation the public can access, and because
> of this I'm having massive problems implementing a placeholder to see how much of ntdll.dll would have to be written for this one program...

Some of these functions are documented, just not by Microsoft.
>
> So barring anyone having suggestions on this, the command line utility LogParser.exe on WINE is a no go unless a lot of undocumented library
> calls are basically reverse engineered?

Reverse engineered == bad, bad, bad.  Black Boxed is much better.  If
you can figure out what are the inputs then you can test away.  Maybe
those are documented somewhere and you will have to observe what is
inputted to the process and what is outputted.  There is a whole Wiki
worth of development information on what is and is not allowed for
Wine development.  Looking at any Microsoft code or derivative is an
absolute no-no.

James McKenzie



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

  Powered by Linux