Re: [ros-dev] [ros-diffs] [sserapion] 44807: Add definitions for the x86bios emulator. http://www.geoffchappell.com/viewer.htm?doc=studies/windows/km/hal/api/x86bios/index.htm

[Colin Finck]

[e-mail] wrote:
> Add definitions for the x86bios emulator.

http://www.geoffchappell.com/viewer.htm?doc=studies/windows/km/hal/api/x86bi
os/index.htm
> From the link: "The HAL in x86 builds of Windows Vista introduces a set of

functions for accessing the 16-bit firmware that Windows started from."

So you're adding functions from the x86 HAL in NT6 to our NT5.2-targeted
AMD64 HAL? Is it just me who gets confused here?
If it's alright, I'd like to hear some explanations.

Best regards,

Colin

[Timo Kreuzer]

Colin Finck schrieb:
> [e-mail] wrote:
> > Add definitions for the x86bios emulator.
>
> http://www.geoffchappell.com/viewer.htm?doc=studies/windows/km/hal/api/x86bi
> os/index.htm
> > From the link: "The HAL in x86 builds of Windows Vista introduces a set of
>
> functions for accessing the 16-bit firmware that Windows started from."
>
> So you're adding functions from the x86 HAL in NT6 to our NT5.2-targeted
> AMD64 HAL? Is it just me who gets confused here?
> If it's alright, I'd like to hear some explanations.

Yes those are NT6+, but they are for x86 and amd64. There is an older
amd64 only interface in NT5.2, but I don't see any use in supporting
this older interface as it's private and undocumented anyway. I don't
expect any 3rd party drivers to use it. Also there is documentation for
the newer interface available and it's usable for x86 later, too.

[Alex Ionescu]

Prove it.

On 2009-12-30, at 7:48 AM, Timo Kreuzer wrote:
> Also there is documentation for
> the newer interface available and it's usable for x86 later, too.

Best regards,
Alex Ionescu

[Timo Kreuzer]

Prove what? That there's documentation or that it's usable for x86, too?
Or is that a coding challenge?

Alex Ionescu wrote:
> Prove it.
>
> On 2009-12-30, at 7:48 AM, Timo Kreuzer wrote:
> > Also there is documentation for
> > the newer interface available and it's usable for x86 later, too.
>
> Best regards,
> Alex Ionescu
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Alex Ionescu]

The services are undocumented and reserved for EFI.

They are not "Documented" and there's no reason to use the Vista implementation.

On 2009-12-30, at 11:42 AM, Timo Kreuzer wrote:
> Prove what? That there's documentation or that it's usable for x86, too?
> Or is that a coding challenge?
>
> Alex Ionescu wrote:
> > Prove it.
> >
> > On 2009-12-30, at 7:48 AM, Timo Kreuzer wrote:
> > > Also there is documentation for
> > > the newer interface available and it's usable for x86 later, too.
> >
> > Best regards,
> > Alex Ionescu
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

Best regards,
Alex Ionescu

[Timo Kreuzer]

Prove it.

Alex Ionescu wrote:
> The services are undocumented and reserved for EFI.
>
> They are not "Documented" and there's no reason to use the Vista implementation.

[Alex Ionescu]

http://www.google.com/search?hl=en&client=safari&rls=en&q=%22x86...

Your search - "x86BiosCall" site:microsoft.com - did not match any documents.

bash-3.2$ grep -ir 'x86BiosCall' /ntdev/headers/ --include *.h --include *.c
bash-3.2$

Your turn.

On 2009-12-30, at 12:23 PM, Timo Kreuzer wrote:
> Prove it.
>
> Alex Ionescu wrote:
> > The services are undocumented and reserved for EFI.
> >
> > They are not "Documented" and there's no reason to use the Vista implementation.
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

Best regards,
Alex Ionescu

[Timo Kreuzer]

LOL, I love that "I couldn't find any documentation on MSDN and in some
arbitrary collection of headers, so it must not exist".

I also never talked about MS provided documentation. 3rd party
documentation still qualifies as documentation and it's better than
nothing, if not even better than a lot of MS documentation.

Here, for you to read:
http://www.geoffchappell.com/viewer.htm?doc=studies/windows/km/hal/api/x86bi...

Maybe it helps you to understand that x86Bios functions have absolutely
nothing to do with EFI.

Done.
Timo

Alex Ionescu wrote:
> http://www.google.com/search?hl=en&client=safari&rls=en&q=%22x86...
>
> Your search - "x86BiosCall" site:microsoft.com - did not match any documents.
>
> bash-3.2$ grep -ir 'x86BiosCall' /ntdev/headers/ --include *.h --include *.c
> bash-3.2$
>
> Your turn.
>
> On 2009-12-30, at 12:23 PM, Timo Kreuzer wrote:
> > Prove it.
> >
> > Alex Ionescu wrote:
> > > The services are undocumented and reserved for EFI.
> > >
> > > They are not "Documented" and there's no reason to use the Vista implementation.
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Best regards,
> Alex Ionescu
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Alex Ionescu]

I've read Geoff's stuff and even know him -- that doesn't make him MSDN.

His pages are not "documentation", they're the same thing you can get yourself from IDA.

The point remains there should NOT be post NT 5.2+ code in kernel-mode. If you don't understand this, I can ask Aleksey to clarify.

Also, these routines were purposely implemented to replace Ke ABIOS interface for EM64T (because you can't do Virtual 8086 easily from Long mode) and EFI (because there is no Video BIOS) systems, so I do know what I'm talking about.

On 2009-12-30, at 3:15 PM, Timo Kreuzer wrote:
> LOL, I love that "I couldn't find any documentation on MSDN and in some
> arbitrary collection of headers, so it must not exist".
>
> I also never talked about MS provided documentation. 3rd party
> documentation still qualifies as documentation and it's better than
> nothing, if not even better than a lot of MS documentation.
>
> Here, for you to read:
> http://www.geoffchappell.com/viewer.htm?doc=studies/windows/km/hal/api/x86bi...
>
> Maybe it helps you to understand that x86Bios functions have absolutely
> nothing to do with EFI.
>
> Done.
> Timo
>
> Alex Ionescu wrote:
> > http://www.google.com/search?hl=en&client=safari&rls=en&q=%22x86...
> >
> > Your search - "x86BiosCall" site:microsoft.com - did not match any documents.
> >
> > bash-3.2$ grep -ir 'x86BiosCall' /ntdev/headers/ --include *.h --include *.c
> > bash-3.2$
> >
> > Your turn.
> >
> > On 2009-12-30, at 12:23 PM, Timo Kreuzer wrote:
> > > Prove it.
> > >
> > > Alex Ionescu wrote:
> > > > The services are undocumented and reserved for EFI.
> > > >
> > > > They are not "Documented" and there's no reason to use the Vista implementation.
> > >
> > > Ros-dev mailing list
> > > [e-mail]
> > > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > Best regards,
> > Alex Ionescu
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

Best regards,
Alex Ionescu

[Timo Kreuzer]

Alex Ionescu wrote:
> I've read Geoff's stuff and even know him -- that doesn't make him MSDN.
>
> His pages are not "documentation", they're the same thing you can get yourself from IDA.

Years later and still the same ignorance. Copying code with IDA is not
what we are supposed to do! It's documented, so I don't need to use IDA
or copy MS assembly code. Guess what: this is called "clean room reverse
engineering". Never heard of?

At some point the amd64 port will need one or the other interface. I
could implement the old, amd64 only and *completely* undocumented
interface or I can just give a shit about that interface and directly go
for the newer, shared with x86 and documented interface. And the fact
that the old interface it's not documented makes it actually easier for
me to decide. No driver is going to use it, so we don't need it. If you
ever find a driver that uses that interface, I promise I will instantly
fix it.

Yes, you would probably do the former and reverse it completely, but
that's not what I'm going to do.
> The point remains there should NOT be post NT 5.2+ code in kernel-mode. If you don't understand this, I can ask Aleksey to clarify.

What is post 5.2 code? Everything that is not 1:1 reversed MS code? Or
everything that uses techniqes or implements features that weren't
present in NT5.2?
It would mean we would be stuck with a 5.2 kernel forever, because
there's no chance to "instantly" substitute the whole kernel with a 6.0
kernel or 6.1 kernel. That will never work. So we only have one chance
and that is introducing post 5.2 features in our kernel bit by bit.

And btw, Aleksey is currently developing a wine based win32 subsystem. I
don't really expect him to be a "purity fundamentalist" in that aspect.

If you don't want the code, great. I will not add it to x86 hal. It will
be amd64 only.
> Also, these routines were purposely implemented to replace Ke ABIOS interface for EM64T (because you can't do Virtual 8086 easily from Long mode) and EFI (because there is no Video BIOS) systems, so I do know what I'm talking about.

It still has nothing to do with EFI. A x86 real mode emulator doesn't
help you with EFI. "Reserved for EFI" is bs. Period.

Thanks,
Timo

[Aleksey Bragin]

> And btw, Aleksey is currently developing a wine based win32  
> subsystem. I
> don't really expect him to be a "purity fundamentalist" in that  
> aspect.

I'm also developing a new parallel functional-logical language  
implementation for supercomputers. Does this make me even less purity  
fundamentalist? ;)

Happy New Year!

WBR,
Aleksey Bragin.