You might try changing DGROUP to CS in two places and make sure
OldInt15Vector is in the same segment that your code is in. When the
interrupt occurs, DS will not be your data segment.
Change the RETF to RETF 2. You want to discard the flags the get pushed
when the INT occurs.
Jerry.
“kelvin lim”
Sent by: xxxxx@lists.osr.com
06/29/2007 03:36 AM
Please respond to
“Windows System Software Devs Interest List”
To
“Windows System Software Devs Interest List”
cc
Subject
Re: [ntdev] NTLDR and real mode memory
After the hook, it seems to hang there. Maybe someone can look at my code:
_Int15Hook proc far
jmp short Int15Hook_start
nop
Int15Hook_start:
cmp AX,0E820h
jnz originalInt15
call dword ptr DGROUP:[OldInt15Vector]
retf
originalInt15:
jmp dword ptr DGROUP:[OldInt15Vector]
_Int15Hook endp
currently I’m not doing anything in the hook, I just want to be able
to return from it. But the system seems to hang. The original Int 15
vector is stored in DGROUP:[OldInt15Vector]. Does this look right?
Thanks.
On 6/29/07, xxxxx@windows.microsoft.com
wrote:
As others have said, if your int 13h filter is reserving memory using
40:13 or any other allocation method, it will additionally need to hook
all interfaces that an OS or other software may use to obtain the system
memory map. In addition to int 15h, ax-0e820h other interfaces include
int 15h, ax=e801 and ax=88h. Hooking the later two is not required for
Windows, but may be required for compatibility with other realmode
software.
At a minimum, you need to hook int 15 ax=0e820h which Windows uses to
obtain the system memory map. You will need to hook this interface to
describe the memory you have allocated in your int 13h filter. You should
either remove your memory region from the memory map or describe it as
“firmware reserved” (type 2). If you are allocating memory under 640K,
please recognize that this is a shared resource used by BIOS, option ROMs,
OS boot loaders and various realmode software. 40K will likely be OK, but
if you need much more memory you should consider reserving memory over
1MB.
-jamie
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
An IRET would destroy the flags that the old INT 15 would have returned.
He needs RETF 2.
Bob Kjelgaard
Sent by: xxxxx@lists.osr.com
06/29/2007 09:52 AM
Please respond to
“Windows System Software Devs Interest List”
To
“Windows System Software Devs Interest List”
cc
Subject
RE: [ntdev] NTLDR and real mode memory
Since it’s an interrupt, I believe you need an iret, not a retf…
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Ok will try that. I read the I need to do a pushf before after calling
the the original interrupt?
On 6/29/07, xxxxx@attotech.com wrote:
>
>
> You might try changing DGROUP to CS in two places and make sure
> OldInt15Vector is in the same segment that your code is in. When the
> interrupt occurs, DS will not be your data segment.
>
> Change the RETF to RETF 2. You want to discard the flags the get pushed
> when the INT occurs.
>
> Jerry.
>
>
>
> “kelvin lim”
> Sent by: xxxxx@lists.osr.com
>
> 06/29/2007 03:36 AM Please respond to
> “Windows System Software Devs Interest List”
>
> To
> “Windows System Software Devs Interest List” cc
> Subject
> Re: [ntdev] NTLDR and real mode memory
>
>
>
>
> After the hook, it seems to hang there. Maybe someone can look at my code:
>
> _Int15Hook proc far
> jmp short Int15Hook_start
> nop
> Int15Hook_start:
> cmp AX,0E820h
> jnz originalInt15
> call dword ptr DGROUP:[OldInt15Vector]
> retf
> originalInt15:
> jmp dword ptr DGROUP:[OldInt15Vector]
> _Int15Hook endp
>
> currently I’m not doing anything in the hook, I just want to be able
> to return from it. But the system seems to hang. The original Int 15 vector
> is stored in DGROUP:[OldInt15Vector]. Does this look right?
>
> Thanks.
>
> On 6/29/07, xxxxx@windows.microsoft.com<
> *xxxxx@windows.microsoft.com * > wrote:
> As others have said, if your int 13h filter is reserving memory using
> 40:13 or any other allocation method, it will additionally need to hook all
> interfaces that an OS or other software may use to obtain the system memory
> map. In addition to int 15h, ax-0e820h other interfaces include int 15h,
> ax=e801 and ax=88h. Hooking the later two is not required for Windows, but
> may be required for compatibility with other realmode software.
>
> At a minimum, you need to hook int 15 ax=0e820h which Windows uses to
> obtain the system memory map. You will need to hook this interface to
> describe the memory you have allocated in your int 13h filter. You should
> either remove your memory region from the memory map or describe it as
> “firmware reserved” (type 2). If you are allocating memory under 640K,
> please recognize that this is a shared resource used by BIOS, option ROMs,
> OS boot loaders and various realmode software. 40K will likely be OK, but
> if you need much more memory you should consider reserving memory over 1MB.
>
> -jamie
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256http:
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServerhttp:
>
> — Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
> Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
> — Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
> Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer</http:></http:>
CALL to old interrupt vector is a bad idea, since it will return by IRET
and not RETF, so, CALL will introduce stack imbalance.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
“kelvin lim” wrote in message news:xxxxx@ntdev…
> After the hook, it seems to hang there. Maybe someone can look at my code:
>
> _Int15Hook proc far
> jmp short Int15Hook_start
> nop
> Int15Hook_start:
> cmp AX,0E820h
> jnz originalInt15
> call dword ptr DGROUP:[OldInt15Vector]
> retf
> originalInt15:
> jmp dword ptr DGROUP:[OldInt15Vector]
> _Int15Hook endp
>
> currently I’m not doing anything in the hook, I just want to be able to
> return from it. But the system seems to hang. The original Int 15 vector is
> stored in DGROUP:[OldInt15Vector]. Does this look right?
>
> Thanks.
>
> On 6/29/07, xxxxx@windows.microsoft.com
> wrote:
> >
> > As others have said, if your int 13h filter is reserving memory using
> > 40:13 or any other allocation method, it will additionally need to hook all
> > interfaces that an OS or other software may use to obtain the system memory
> > map. In addition to int 15h, ax-0e820h other interfaces include int 15h,
> > ax=e801 and ax=88h. Hooking the later two is not required for Windows, but
> > may be required for compatibility with other realmode software.
> >
> > At a minimum, you need to hook int 15 ax=0e820h which Windows uses to
> > obtain the system memory map. You will need to hook this interface to
> > describe the memory you have allocated in your int 13h filter. You should
> > either remove your memory region from the memory map or describe it as
> > “firmware reserved” (type 2). If you are allocating memory under 640K,
> > please recognize that this is a shared resource used by BIOS, option ROMs,
> > OS boot loaders and various realmode software. 40K will likely be OK, but
> > if you need much more memory you should consider reserving memory over 1MB.
> >
> > -jamie
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >
>
In addition, before calling OldInt15, add a pushf to push the flags - the
old int 15 handler will expect this and it will also do a RETF 2.
xxxxx@attotech.com
Sent by: xxxxx@lists.osr.com
06/29/2007 10:03 AM
Please respond to
“Windows System Software Devs Interest List”
To
“Windows System Software Devs Interest List”
cc
Subject
Re: [ntdev] NTLDR and real mode memory
You might try changing DGROUP to CS in two places and make sure
OldInt15Vector is in the same segment that your code is in. When the
interrupt occurs, DS will not be your data segment.
Change the RETF to RETF 2. You want to discard the flags the get pushed
when the INT occurs.
Jerry.
“kelvin lim”
Sent by: xxxxx@lists.osr.com
06/29/2007 03:36 AM
Please respond to
“Windows System Software Devs Interest List”
To
“Windows System Software Devs Interest List”
cc
Subject
Re: [ntdev] NTLDR and real mode memory
After the hook, it seems to hang there. Maybe someone can look at my code:
_Int15Hook proc far
jmp short Int15Hook_start
nop
Int15Hook_start:
cmp AX,0E820h
jnz originalInt15
call dword ptr DGROUP:[OldInt15Vector]
retf
originalInt15:
jmp dword ptr DGROUP:[OldInt15Vector]
_Int15Hook endp
currently I’m not doing anything in the hook, I just want to be able
to return from it. But the system seems to hang. The original Int 15
vector is stored in DGROUP:[OldInt15Vector]. Does this look right?
Thanks.
On 6/29/07, xxxxx@windows.microsoft.com
wrote:
As others have said, if your int 13h filter is reserving memory using
40:13 or any other allocation method, it will additionally need to hook
all interfaces that an OS or other software may use to obtain the system
memory map. In addition to int 15h, ax-0e820h other interfaces include
int 15h, ax=e801 and ax=88h. Hooking the later two is not required for
Windows, but may be required for compatibility with other realmode
software.
At a minimum, you need to hook int 15 ax=0e820h which Windows uses to
obtain the system memory map. You will need to hook this interface to
describe the memory you have allocated in your int 13h filter. You should
either remove your memory region from the memory map or describe it as
“firmware reserved” (type 2). If you are allocating memory under 640K,
please recognize that this is a shared resource used by BIOS, option ROMs,
OS boot loaders and various realmode software. 40K will likely be OK, but
if you need much more memory you should consider reserving memory over
1MB.
-jamie
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
I did a retf 2. But it still does not return properly. Do I need to do a
pushf and popf ?
On 6/29/07, xxxxx@attotech.com wrote:
>
>
> An IRET would destroy the flags that the old INT 15 would have returned.
> He needs RETF 2.
>
>
>
> Bob Kjelgaard
> Sent by: xxxxx@lists.osr.com
>
> 06/29/2007 09:52 AM Please respond to
> “Windows System Software Devs Interest List”
>
> To
> “Windows System Software Devs Interest List” cc
> Subject
> RE: [ntdev] NTLDR and real mode memory
>
>
>
>
> Since it’s an interrupt, I believe you need an iret, not a retf…
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> — Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
> Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
That would really depend upon the underlying INT15 implementation, wouldn’t it? If it modifies the flags on the stack and uses IRET, then OP should do the same. If it sets them and uses RETF2 to skip them, then he needs to do that.
Back in the days when I wrote code at that level, I would probably have done the former. But that was nearly 20 years ago, and if the latter is the prevailing standard, so be it. It was free advice, and worth every penny of it.
So what would be the best approach then ?
On 6/29/07, Maxim S. Shatskih wrote:
>
> CALL to old interrupt vector is a bad idea, since it will return by
> IRET
> and not RETF, so, CALL will introduce stack imbalance.
>
> –
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> “kelvin lim” wrote in message news:xxxxx@ntdev…
> > After the hook, it seems to hang there. Maybe someone can look at my
> code:
> >
> > _Int15Hook proc far
> > jmp short Int15Hook_start
> > nop
> > Int15Hook_start:
> > cmp AX,0E820h
> > jnz originalInt15
> > call dword ptr DGROUP:[OldInt15Vector]
> > retf
> > originalInt15:
> > jmp dword ptr DGROUP:[OldInt15Vector]
> > _Int15Hook endp
> >
> > currently I’m not doing anything in the hook, I just want to be able
> to
> > return from it. But the system seems to hang. The original Int 15 vector
> is
> > stored in DGROUP:[OldInt15Vector]. Does this look right?
> >
> > Thanks.
> >
> > On 6/29/07, xxxxx@windows.microsoft.com > >
> > wrote:
> > >
> > > As others have said, if your int 13h filter is reserving memory using
> > > 40:13 or any other allocation method, it will additionally need to
> hook all
> > > interfaces that an OS or other software may use to obtain the system
> memory
> > > map. In addition to int 15h, ax-0e820h other interfaces include int
> 15h,
> > > ax=e801 and ax=88h. Hooking the later two is not required for
> Windows, but
> > > may be required for compatibility with other realmode software.
> > >
> > > At a minimum, you need to hook int 15 ax=0e820h which Windows uses to
> > > obtain the system memory map. You will need to hook this interface to
> > > describe the memory you have allocated in your int 13h filter. You
> should
> > > either remove your memory region from the memory map or describe it as
> > > “firmware reserved” (type 2). If you are allocating memory under
> 640K,
> > > please recognize that this is a shared resource used by BIOS, option
> ROMs,
> > > OS boot loaders and various realmode software. 40K will likely be OK,
> but
> > > if you need much more memory you should consider reserving memory over
> 1MB.
> > >
> > > -jamie
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > To unsubscribe, visit the List Server section of OSR Online at
> > > http://www.osronline.com/page.cfm?name=ListServer
> > >
> >
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Tasty foot I just put in my mouth…
Doesn’t he ALSO need to push flags before he calls (as opposed to "jumps to) the old routine? Otherwise, his return address is already off the bottom of the stack when the call returns, and if the underlying routine has enabled interrupts, the first one after the return will blow it forever even if he adjusts SP to account for it.
At any rate, it’s pretty clear the stack is getting blown and that’s why it’s hung. Forgetting about flags being pushed in an interrupt is what got him here in the first place, and he can probably fix it from there.
From: Bob Kjelgaard
Sent: Friday, June 29, 2007 7:37 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NTLDR and real mode memory
That would really depend upon the underlying INT15 implementation, wouldn’t it? If it modifies the flags on the stack and uses IRET, then OP should do the same. If it sets them and uses RETF2 to skip them, then he needs to do that.
Back in the days when I wrote code at that level, I would probably have done the former. But that was nearly 20 years ago, and if the latter is the prevailing standard, so be it. It was free advice, and worth every penny of it.
I think 20 years ago the RETF 2 option wasn’t available. Not sure when it
came along - 286 maybe?
Shouldn’t matter what the original implementation did - he needs to get
the flags from the old INT 15 sent back to the caller and either approach
should do it.
J.
Bob Kjelgaard
Sent by: xxxxx@lists.osr.com
06/29/2007 11:07 AM
Please respond to
“Windows System Software Devs Interest List”
To
“Windows System Software Devs Interest List”
cc
Subject
RE: [ntdev] NTLDR and real mode memory
That would really depend upon the underlying INT15 implementation,
wouldn?t it? If it modifies the flags on the stack and uses IRET, then OP
should do the same. If it sets them and uses RETF2 to skip them, then he
needs to do that.
Back in the days when I wrote code at that level, I would probably have
done the former. But that was nearly 20 years ago, and if the latter is
the prevailing standard, so be it. It was free advice, and worth every
penny of it.
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Yes, he needs a pushf before the call.
Yes, the stack is getting screwed up OR he doesn’t yet have the segment
overrides correct for the jmp and/or the call.
First suggestion I would give to the OP is to remove everything and just
chain to the old interrupt like so:
_Int15Hook proc far
jmp dword ptr CS:[OldInt15Vector]
_Int15Hook endp
If he gets that working then he can move from there. If that doesn’t work
then there’s something wrong with the OldInt15Vector - what segment it’s
in, how he’s storing it, or whatever.
Maxim - he wants to CALL the old INT 15 because after it returns he wants
to add code to modify what it is returning.
J.
Bob Kjelgaard
Sent by: xxxxx@lists.osr.com
06/29/2007 11:26 AM
Please respond to
“Windows System Software Devs Interest List”
To
“Windows System Software Devs Interest List”
cc
Subject
RE: [ntdev] NTLDR and real mode memory
Tasty foot I just put in my mouth?.
Doesn?t he ALSO need to push flags before he calls (as opposed to ?jumps
to) the old routine? Otherwise, his return address is already off the
bottom of the stack when the call returns, and if the underlying routine
has enabled interrupts, the first one after the return will blow it
forever even if he adjusts SP to account for it.
At any rate, it?s pretty clear the stack is getting blown and that?s why
it?s hung. Forgetting about flags being pushed in an interrupt is what
got him here in the first place, and he can probably fix it from there.
From: Bob Kjelgaard
Sent: Friday, June 29, 2007 7:37 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NTLDR and real mode memory
That would really depend upon the underlying INT15 implementation,
wouldn?t it? If it modifies the flags on the stack and uses IRET, then OP
should do the same. If it sets them and uses RETF2 to skip them, then he
needs to do that.
Back in the days when I wrote code at that level, I would probably have
done the former. But that was nearly 20 years ago, and if the latter is
the prevailing standard, so be it. It was free advice, and worth every
penny of it.
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Yep. Thanks alot for the help guys ! I’ll take it from here.
Regards,
Kelvin
On 6/29/07, xxxxx@attotech.com wrote:
>
>
> Yes, he needs a pushf before the call.
> Yes, the stack is getting screwed up OR he doesn’t yet have the segment
> overrides correct for the jmp and/or the call.
> First suggestion I would give to the OP is to remove everything and just
> chain to the old interrupt like so:
>
> _Int15Hook proc far
> jmp dword ptr CS:[OldInt15Vector]
> _Int15Hook endp
>
> If he gets that working then he can move from there. If that doesn’t work
> then there’s something wrong with the OldInt15Vector - what segment it’s in,
> how he’s storing it, or whatever.
>
> Maxim - he wants to CALL the old INT 15 because after it returns he wants
> to add code to modify what it is returning.
>
> J.
>
>
>
>
> Bob Kjelgaard
> Sent by: xxxxx@lists.osr.com
>
> 06/29/2007 11:26 AM Please respond to
> “Windows System Software Devs Interest List”
>
> To
> “Windows System Software Devs Interest List” cc
> Subject
> RE: [ntdev] NTLDR and real mode memory
>
>
>
>
> Tasty foot I just put in my mouth?.
>
> Doesn’t he ALSO need to push flags before he calls (as opposed to "jumps
> to) the old routine? Otherwise, his return address is already off the
> bottom of the stack when the call returns, and if the underlying routine has
> enabled interrupts, the first one after the return will blow it forever even
> if he adjusts SP to account for it.
>
> At any rate, it’s pretty clear the stack is getting blown and that’s why
> it’s hung. Forgetting about flags being pushed in an interrupt is what got
> him here in the first place, and he can probably fix it from there.
>
> From: Bob Kjelgaard
> Sent: Friday, June 29, 2007 7:37 AM*
> To:* Windows System Software Devs Interest List*
> Subject:* RE: [ntdev] NTLDR and real mode memory
>
> That would really depend upon the underlying INT15 implementation,
> wouldn’t it? If it modifies the flags on the stack and uses IRET, then OP
> should do the same. If it sets them and uses RETF2 to skip them, then he
> needs to do that.
>
> Back in the days when I wrote code at that level, I would probably have
> done the former. But that was nearly 20 years ago, and if the latter is the
> prevailing standard, so be it. It was free advice, and worth every penny of
> it.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> — Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
> Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
Yes, actually the initial problem is probably not establishing addressability to the underlying code- the stack issues would then surface later.
I tend to assume stuff has been at least partially debugged and details omitted from code snippets these days, so I assumed addressability was already working, but not included to keep the post small. In which case the glaring error was the difference in interrupt versus call stacks…
My apologies if I confused the issue.
Brian McFadden wrote:
First, bochs (with bochsdbg) was a HUGE help debugging, so I can recommend it
for exploration and test code
I always wondered about BOCHS for debugging purposes, can you share your experiences? Anybody tried it for kernel debugging?
How slow it is (I know that for early boot debugging is not an issue)? How easy/difficult is to implement a pipe interface for Windbg? How “modern” is the chipset/bios it emulates (ACPI, power management)?
(sorry for the OT)
xxxxx@attotech.com wrote:
I think 20 years ago the RETF 2 option wasn’t available. Not sure
when it came along - 286 maybe?
Wrong. It was in the original 8086. It is required to implement the
so-called “Pascal calling convention”.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
It’s fairly brutual. That being said, it is a lot cheaper than the JTAG
hardware that would be required in its abscence. If you’re looking at
x64, the AMD64 simulator is a little faster, and, I believe, aleady has
a WinDbg interface.
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@rahul.net
Sent: Friday, June 29, 2007 14:14
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] NTLDR and real mode memory
Brian McFadden wrote:
First, bochs (with bochsdbg) was a HUGE help debugging, so I can
recommend it
for exploration and test code
I always wondered about BOCHS for debugging purposes, can you share your
experiences? Anybody tried it for kernel debugging?
How slow it is (I know that for early boot debugging is not an issue)?
How easy/difficult is to implement a pipe interface for Windbg? How
“modern” is the chipset/bios it emulates (ACPI, power management)?
(sorry for the OT)
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Ah yes, my mistake.
Tim Roberts
Sent by: xxxxx@lists.osr.com
06/29/2007 02:53 PM
Please respond to
“Windows System Software Devs Interest List”
To
“Windows System Software Devs Interest List”
cc
Subject
Re: [ntdev] NTLDR and real mode memory
xxxxx@attotech.com wrote:
>
> I think 20 years ago the RETF 2 option wasn’t available. Not sure
> when it came along - 286 maybe?
Wrong. It was in the original 8086. It is required to implement the
so-called “Pascal calling convention”.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Hi All,
I got my Int 15 hook working. Thanks guys : )
Unfortunately, that still didn’t solve my problems, I’m still unable to load
windows after doing a full drive encryption (or rather partially).
I’ve tested my encryption driver on quite a few PCs (dells, lenovos, HPs),
it works on some PCs, but not others (especially Dells). It works on VMware
also.
This leads me to believe that some PC BIOSes have their own Int 13
functions. Is this possible? In my Int 13 hook, I filter for AH=02,03,42 and
43 only. Could there be others? Thanks.
Best wishes,
Kelvin
On 6/30/07, xxxxx@attotech.com wrote:
>
>
> Ah yes, my mistake.
>
>
>
> Tim Roberts
> Sent by: xxxxx@lists.osr.com
>
> 06/29/2007 02:53 PM Please respond to
> “Windows System Software Devs Interest List”
>
> To
> “Windows System Software Devs Interest List” cc
> Subject
> Re: [ntdev] NTLDR and real mode memory
>
>
>
>
> xxxxx@attotech.com wrote:
> >
> > I think 20 years ago the RETF 2 option wasn’t available. Not sure
> > when it came along - 286 maybe?
>
> Wrong. It was in the original 8086. It is required to implement the
> so-called “Pascal calling convention”.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> — Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
> Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
Are these EFI/UEFI systems?
No.
On 7/3/07, xxxxx@hotmail.com wrote:
>
> Are these EFI/UEFI systems?
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>