With memory you must have in mind two things: CONTEXT and ACCESS MODE.
A chunk of physical memory can be mapped in many thread contexts as virtual
memory. This does not necessarily mean that all threads can get the same
amount of access to the memory. If you have the
“Windows NT Device Driver Development” book from OSR, turn to page 57,
bottom:
"
-a page can always be read from kernel mode
-it can only be written from kernel mode, if write access has been granted
-it can only be read from user mode if “UserMode” access has been granted
-it can only be written from user mode if both User Mode access and write
access have been granted
-if a page can be read it can be executed
"
So what are the key words here ? UserMode/KernelMode, different access
modes, and ofcourse where is this taking place ? In a process context, so
the VMM will have valid PTE for translation.
I guess you were wondering because you were thinking of the memory chunk as
absolute memory, or physical memory. Well if the physical memory described
by different PTE’s is marked as READ-ONLY or temporary readonly by the OS
you will not get write access to that even in kernel mode.
Hope it’s clearer now.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, September 25, 2008 5:36 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Windows memory management and protection discuss
HI, Peter, Thanks, your answer is somewhat i looking for(I am talking about
the Main physical memory access),but not specificly.
The read-only or read-write attribute is an attribute of how the memory is MAPPED, the VIEW onto the physical pages of memory, gained by a particular thread of processing. Given that the OS is what CONTROLS memory access (it’s the guy who’s responsible for deciding what parts of main memory are mapped read-write or read-only and for whom), it is entirely reasonable for the OS to be able to have write access to any main memory on the system.
Yes, the OS conctrols the memory mapped, then if the driver can remap the memory to another virtual address in system space and can change the access rights(how can it do this!but the above code do tell me the driver really can do this), that means the functions above can change the memory access right, cann’t it? If the driver can change(it does can), then the change memory will be write back to the disk image? I am worried if a miss action driver really change the system structure that has been loaded to physical memory,will it be writen back to the disk, thus may even cause the system will not boot up next time?
On 9/25/08, Matt wrote: > xxxxx@resplendence.com wrote: > > THANKS DANIEL… > > That package set off my AV… People, heads up when downloading… > > lol > >
well iirc that was part of hxdef the hackerdefender rootkit peoples effort to write thier drivers
Only as long as it is mapped in the address space of the currently running process. For example, if page is mapped to the UM portion of the process X’s address space, kernel code will be able to access it only if it runs in context of a process X…
-it can only be written from kernel mode, if write access has been granted
Well, If WP flag in CR0 is clear, kernel code can can write to any page in the address space, regardless of protection that is specified in PTE. In practical terms, it does not matter, because the system sets this flag, so that you have to modify it in order to write to the page that is marked RO in its PTE…
-if a page can be read it can be executed
It used to be the case before introduction of Execution Prevention feature to x86. However, if your CPU supports this feature (all CPUs that got produced in the last 2 years do support it), a page may be readable but not executable…
HI,Gabriel, i search the online book shop in our country, i cann’t find the
book “Windows NT Device Driver Development”, i know it from osronline a few
days ago.
-a page can always be read from kernel mode -it can only be written from kernel mode, if write access has been granted -it can only be read from user mode if “UserMode” access has been granted -it can only be written from user mode if both User Mode access and write access have been granted -if a page can be read it can be executed
then who grants the driver to do? Nobody,in my opinion, the driver can take an initiatively action to write(just use the Mmxxx function mententioned above let the memory mapped to a virtual address in Kernel space) the read only memory, without been granted. Specificly, does the MmProbeAndLockPages and MmMapLockedPages functions(they belong to VMM, so you can say VMM grant) grant the driver to change read only memory to be writable? I am really confuse. The PFN of the system PTE should not change although the PFN in the process private PTEs will be changed if the process context switches. Then the MmProbeAndLockPages and MmMapLockedPages can change the protection properties in the correspongin system PTE, without been granted(just need to be called in kernel mode), am i right?
2008/9/25 Bercea Gabriel
>
> Focus ! > Remember what Peter said. >
> > With memory you must have in mind two things: CONTEXT and ACCESS MODE. > A chunk of physical memory can be mapped in many thread contexts as virtual > memory. This does not necessarily mean that all threads can get the same > amount of access to the memory. If you have the > “Windows NT Device Driver Development” book from OSR, turn to page 57, > bottom: > " > -a page can always be read from kernel mode > -it can only be written from kernel mode, if write access has been granted > -it can only be read from user mode if “UserMode” access has been granted > -it can only be written from user mode if both User Mode access and write > access have been granted > -if a page can be read it can be executed > " > So what are the key words here ? UserMode/KernelMode, different access > modes, and ofcourse where is this taking place ? In a process context, so > the VMM will have valid PTE for translation. > I guess you were wondering because you were thinking of the memory chunk as > absolute memory, or physical memory. Well if the physical memory described > by different PTE’s is marked as READ-ONLY or temporary readonly by the OS > you will not get write access to that even in kernel mode. > Hope it’s clearer now. > > -----Original Message----- > From: xxxxx@lists.osr.com > [mailto:xxxxx@lists.osr.com] On Behalf Of > xxxxx@gmail.com > Sent: Thursday, September 25, 2008 5:36 PM > To: Windows System Software Devs Interest List > Subject: RE:[ntdev] Windows memory management and protection discuss > > HI, Peter, Thanks, your answer is somewhat i looking for(I am talking about > the Main physical memory access),but not specificly. > > The read-only or read-write attribute is an attribute of how the memory is > MAPPED, the VIEW onto the physical pages of memory, gained by a particular > thread of processing. Given that the OS is what CONTROLS memory access > (it’s > the guy who’s responsible for deciding what parts of main memory are mapped > read-write or read-only and for whom), it is entirely reasonable for the OS > to be able to have write access to any main memory on the system. > > > Yes, the OS conctrols the memory mapped, then if the driver can remap the > memory to another virtual address in system space and can change the access > rights(how can it do this!but the above code do tell me the driver really > can do this), that means the functions above can change the memory access > right, cann’t it? > If the driver can change(it does can), then the change memory will be write > back to the disk image? I am worried if a miss action driver really change > the system structure that has been loaded to physical memory,will it be > writen back to the disk, thus may even cause the system will not boot up > next time? > > thanks > Ma > > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer > > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
On 9/25/08, Matt wrote: > >> xxxxx@resplendence.com wrote: >> >> THANKS DANIEL… >> >> That package set off my AV… People, heads up when downloading… >> >> lol >> > > well iirc that was part of hxdef the hackerdefender rootkit peoples > effort to write thier drivers > > so the package probably set of av alarms > > regards > raj_r > Honestly, I don’t know what was in it, I’ll look later in a vm.
Last week I installed my first AV in 2-3 years. With my speakers up, some damn siren scared the hell out of me on the alert…
Well, If WP flag in CR0 is clear, kernel code can can write to any page in the address space, regardless of protection that is specified in PTE. In practical terms, it does not matter, because the system sets this flag, so that you have to modify it in order to write to the page that is marked RO in its PTE…
you have missunderstood what i am talking.I am just talking the “fairly way”: the OS supplied, all are under the OS. I am talking is that does the OS really tell the driver: i supply u with the validly way that u can use it to do anything including the destruct of myself permanently(make me even never boot again)?
Thanks
2008/9/25
> > -a page can always be read from kernel mode > > Only as long as it is mapped in the address space of the currently running > process. For example, if page is mapped to the UM portion of the process > X’s address space, kernel code will be able to access it only if it runs in > context of a process X… > > > > -it can only be written from kernel mode, if write access has been > granted > > Well, If WP flag in CR0 is clear, kernel code can can write to any page in > the address space, regardless of protection that is specified in PTE. In > practical terms, it does not matter, because the system sets this flag, so > that you have to modify it in order to write to the page that is marked RO > in its PTE… > > > -if a page can be read it can be executed > > It used to be the case before introduction of Execution Prevention feature > to x86. However, if your CPU supports this feature (all CPUs that got > produced in the last 2 years do support it), a page may be readable but > not executable… > > > Anton Bassov > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
…1 How these functions could change the read only memory to be
writable memory.
They create a new set of page table entries pointing to the same
physical memory. There will be two virtual addresses that refer to the
same piece of RAM Even if the original pages were marked read-only, the
new pages will not be.
It is quite common to have a single physical page mapped at multiple
virtual addresses.
2 When the read only memory(assum it contains system structures) has
been changed to writble memory and if the WFP(windows file protection)
is disable, whether the changed system structure will be flush back to
disk image of the system file or the page files on the disk, and why?
The new memory comes from non-paged pool. It will never be written to
disk. The original pages will never be touched, so their page table
entries will never be marked as “dirty”, and because of that there will
never be a need to flush them to disk.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
HI,Gabriel, i search the online book shop in our country, i cann’t
find the book “Windows NT Device Driver Development”, i know it from
osronline a few days ago.
> -a page can always be read from kernel mode > -it can only be written from kernel mode, if write access has been granted > -it can only be read from user mode if “UserMode” access has been granted > -it can only be written from user mode if both User Mode access and write > access have been granted > -if a page can be read it can be executed > > then who grants the driver to do? Nobody,in my opinion, the driver can > take an initiatively action to write(just use the Mmxxx function > mententioned above let the memory mapped to a virtual address in > Kernel space) the read only memory, without been granted.
Kernel code in Windows can do anything. ANYTHING. Kernel code is trusted absolutely. That’s why root kits are so dangerous. If there is any permission checking going on, it is voluntary, done so that the driver can be a good citizen.
> Specificly, does the MmProbeAndLockPages and MmMapLockedPages > functions(they belong to VMM, so you can say VMM grant) grant the > driver to change read only memory to be writable? I am really confuse. > The PFN of the system PTE should not change although the PFN in the > process private PTEs will be changed if the process context > switches. Then the MmProbeAndLockPages and MmMapLockedPages can change > the protection properties in the correspongin system PTE, without been > granted(just need to be called in kernel mode), am i right?
Those functions allocate a NEW set of PTEs, meaning they have a different virtual address, but with the same physical page numbers. The old set of PTEs have the read-only bit set. The new set do not.
Remember that the read/write/execute status is part of the page table entry. That means it is associated with a VIRTUAL address, not a PHYSICAL address. If I can find another way to get to the same PHYSICAL address, I can do whatever I want.
– Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
Tim, good reply. thanks. yeh, the same RAM be refered by two PTE(remember
the virtual address i mentioned is the system address like IDT address or
SSDT address), and the two PTE has different protection properties: one has
read only property and one has writable property, then if the driver write
the RAM, e.g. a driver write the SSDT(assume), let the service routine
address be itself’s, in this case, what should the system do? It continue
think that the SSDT is real only, just call the service routine that has
been replaced?
thanks
Ma
2008/9/26 Tim Roberts
> Carleton Ma wrote: > > > > …1 How these functions could change the read only memory to be > > writable memory. > > They create a new set of page table entries pointing to the same > physical memory. There will be two virtual addresses that refer to the > same piece of RAM Even if the original pages were marked read-only, the > new pages will not be. > > It is quite common to have a single physical page mapped at multiple > virtual addresses. > > > > 2 When the read only memory(assum it contains system structures) has > > been changed to writble memory and if the WFP(windows file protection) > > is disable, whether the changed system structure will be flush back to > > disk image of the system file or the page files on the disk, and why? > > The new memory comes from non-paged pool. It will never be written to > disk. The original pages will never be touched, so their page table > entries will never be marked as “dirty”, and because of that there will > never be a need to flush them to disk. > > – > Tim Roberts, xxxxx@probo.com > Providenza & Boekelheide, Inc. > > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
If it gets us away from pointers, manually-managed allocations, and buffer overflows, I’m all for it!
Sadly, Delphi doesn’t do that. You probably saw the ^ operators
throughout his code: that’s the Delphi/Pascal “pointer dereference”
operator.
For the most part, Delphi code is just C++ code with different syntax.
There’s almost a one-to-one, line-for-line, concept-for-concept
correspondence. I used to be a huge Delphi fan; I even beta-tested
Delphi 2 and 3. The beauty of Delphi, in my opinion, was its component
library. VCL was like a reasonable and understandable version of MFC.
I don’t see any particular benefit to Delphi for drivers.
These days, I’ve moved on to Python…
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim, good reply. thanks. yeh, the same RAM be refered by two
PTE(remember the virtual address i mentioned is the system address
like IDT address or SSDT address), and the two PTE has different
protection properties: one has read only property and one has writable
property, then if the driver write the RAM, e.g. a driver write the
SSDT(assume), let the service routine address be itself’s, in this
case, what should the system do? It continue think that the SSDT is
real only, just call the service routine that has been replaced?
What can it possibly do? As I said, this is why rootkits and hooking
are so dangerous. If you have a solution, believe me, Microsoft is
interested in hearing about it.
Their approach to this in the x64 case is to periodically scan the SSDT
to see if it has been changed. I don’t know whether they compare
individual addresses or take a checksum.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
What do you mean by this. The Memory Manager, built in as part of the OS
grants access/validates addresses, etc . . .
You really should first be taking into consideration reading the proper
documentation . This has now diverted from asking how to map and probe a mdl
to basic memory management issues.
From you post below I guess you need to look over the kernel mode memory
layout, and then the user mode memory layout. Think of the initial memory
pointer as a given INPUT in a certain context. This memory can either be
valid in the context you received it, you can probe that, or it cannot. It
can also come to you as a MDL, and now you are kinda “free of context” (if
it is probed and locked" ) because now the virtual pages are translated (and
locked) and that MDL gives you all the versatility you can ask in kernel
mode. It is not about how that pointer comes to you (read only or not). You
should first validate it probe it for an access that you need, lock it, and
eventually map it to a kernel mode virtual address, which you should know if
thread context free, this means you can access it no matter the thread
context.
This is the las post I am giving to you, after reading all this consider
visiting the online MS WDK Help and take it step by step
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Carleton Ma
Sent: Thursday, September 25, 2008 7:28 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Windows memory management and protection discuss
HI,Gabriel, i search the online book shop in our country, i cann’t find the
book “Windows NT Device Driver Development”, i know it from osronline a few
days ago.
-a page can always be read from kernel mode -it can only be written from kernel mode, if write access has been granted -it can only be read from user mode if “UserMode” access has been granted -it can only be written from user mode if both User Mode access and write access have been granted -if a page can be read it can be executed
then who grants the driver to do? Nobody,in my opinion, the driver can take an initiatively action to write(just use the Mmxxx function mententioned above let the memory mapped to a virtual address in Kernel space) the read only memory, without been granted. Specificly, does the MmProbeAndLockPages and MmMapLockedPages functions(they belong to VMM, so you can say VMM grant) grant the driver to change read only memory to be writable? I am really confuse. The PFN of the system PTE should not change although the PFN in the process private PTEs will be changed if the process context switches. Then the MmProbeAndLockPages and MmMapLockedPages can change the protection properties in the correspongin system PTE, without been granted(just need to be called in kernel mode), am i right?
2008/9/25 Bercea Gabriel
Focus ! Remember what Peter said.
With memory you must have in mind two things: CONTEXT and ACCESS MODE. A chunk of physical memory can be mapped in many thread contexts as virtual memory. This does not necessarily mean that all threads can get the same amount of access to the memory. If you have the “Windows NT Device Driver Development” book from OSR, turn to page 57, bottom: “ -a page can always be read from kernel mode -it can only be written from kernel mode, if write access has been granted -it can only be read from user mode if “UserMode” access has been granted -it can only be written from user mode if both User Mode access and write access have been granted -if a page can be read it can be executed ” So what are the key words here ? UserMode/KernelMode, different access modes, and ofcourse where is this taking place ? In a process context, so the VMM will have valid PTE for translation. I guess you were wondering because you were thinking of the memory chunk as absolute memory, or physical memory. Well if the physical memory described by different PTE’s is marked as READ-ONLY or temporary readonly by the OS you will not get write access to that even in kernel mode. Hope it’s clearer now.
Subject: RE:[ntdev] Windows memory management and protection discuss
HI, Peter, Thanks, your answer is somewhat i looking for(I am talking about the Main physical memory access),but not specificly.
The read-only or read-write attribute is an attribute of how the memory is MAPPED, the VIEW onto the physical pages of memory, gained by a particular thread of processing. Given that the OS is what CONTROLS memory access (it’s the guy who’s responsible for deciding what parts of main memory are mapped read-write or read-only and for whom), it is entirely reasonable for the OS to be able to have write access to any main memory on the system.
Yes, the OS conctrols the memory mapped, then if the driver can remap the memory to another virtual address in system space and can change the access rights(how can it do this!but the above code do tell me the driver really can do this), that means the functions above can change the memory access right, cann’t it? If the driver can change(it does can), then the change memory will be write back to the disk image? I am worried if a miss action driver really change the system structure that has been loaded to physical memory,will it be writen back to the disk, thus may even cause the system will not boot up next time?
Kernel code in Windows can do anything. ANYTHING. Kernel code is trusted absolutely. That’s why root kits are so dangerous. If there is any permission checking going on, it is voluntary, done so that the driver can be a good citizen.
I appreciate this very much.
Remember that the read/write/execute status is part of the page table entry. That means it is associated with a VIRTUAL address, not a PHYSICAL address. If I can find another way to get to the same PHYSICAL address, I can do whatever I want.
Just MmProbeAndLockPages and MmMapLockedPages(according to DDK,it is replaced by MmMapLockedPagesSpecifyCache), peaceful way,you can do anything you want, maybe i can say this, isn’t it? incredibly.
2008/9/26 Tim Roberts
> Carleton Ma wrote: > > HI,Gabriel, i search the online book shop in our country, i cann’t > > find the book “Windows NT Device Driver Development”, i know it from > > osronline a few days ago. > > > > -a page can always be read from kernel mode > > -it can only be written from kernel mode, if write access has been > granted > > -it can only be read from user mode if “UserMode” access has been granted > > -it can only be written from user mode if both User Mode access and write > > access have been granted > > -if a page can be read it can be executed > > > > then who grants the driver to do? Nobody,in my opinion, the driver can > > take an initiatively action to write(just use the Mmxxx function > > mententioned above let the memory mapped to a virtual address in > > Kernel space) the read only memory, without been granted. > > Kernel code in Windows can do anything. ANYTHING. Kernel code is > trusted absolutely. That’s why root kits are so dangerous. If there is > any permission checking going on, it is voluntary, done so that the > driver can be a good citizen. > > > > Specificly, does the MmProbeAndLockPages and MmMapLockedPages > > functions(they belong to VMM, so you can say VMM grant) grant the > > driver to change read only memory to be writable? I am really confuse. > > The PFN of the system PTE should not change although the PFN in the > > process private PTEs will be changed if the process context > > switches. Then the MmProbeAndLockPages and MmMapLockedPages can change > > the protection properties in the correspongin system PTE, without been > > granted(just need to be called in kernel mode), am i right? > > Those functions allocate a NEW set of PTEs, meaning they have a > different virtual address, but with the same physical page numbers. The > old set of PTEs have the read-only bit set. The new set do not. > > Remember that the read/write/execute status is part of the page table > entry. That means it is associated with a VIRTUAL address, not a > PHYSICAL address. If I can find another way to get to the same PHYSICAL > address, I can do whatever I want. > > – > Tim Roberts, xxxxx@probo.com > Providenza & Boekelheide, Inc. > > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
“Tim Roberts” wrote in message news:xxxxx@ntdev… The beauty of Delphi, in my opinion, was its component > library. VCL was like a reasonable and understandable version of MFC. > I don’t see any particular benefit to Delphi for drivers. >
The way I see it the merit of the VCL inherits its value from the features of the language, properties in particular. And what about case insensitivity ? Semantic blessings such as these of which Delphi has many I think are priceless and mark the value of an evolved high level language. Or the lack of multiple inheritance that is dreaded so much ? Then consider its unparalleled compilation speed (about 100,000 lines/second).
I figure that if you like C# you must also like Delphi as the language was designed by the same person (Hejlsberg). Unfortunately it’s dying a slow death and there is still no native support x64 code as of today (Delphi 2009).
I agree there are practical objections against writing drivers for Windows in Delphi but don’t you think the language in itself and the compiler could just be very suitable ?
Microsoft made an announcement about this. They said that they will try to
bugcheck the code that will try to modify the SSDT. This sounds like a very
good idea and approach to me.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, September 25, 2008 8:23 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Windows memory management and protection discuss
Carleton Ma wrote:
Tim, good reply. thanks. yeh, the same RAM be refered by two
PTE(remember the virtual address i mentioned is the system address
like IDT address or SSDT address), and the two PTE has different
protection properties: one has read only property and one has writable
property, then if the driver write the RAM, e.g. a driver write the
SSDT(assume), let the service routine address be itself’s, in this
case, what should the system do? It continue think that the SSDT is
real only, just call the service routine that has been replaced?
What can it possibly do? As I said, this is why rootkits and hooking
are so dangerous. If you have a solution, believe me, Microsoft is
interested in hearing about it.
Their approach to this in the x64 case is to periodically scan the SSDT
to see if it has been changed. I don’t know whether they compare
individual addresses or take a checksum.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I agree there are practical objections against writing drivers for
Windows in Delphi but don’t you think the language in itself and the
compiler could just be very suitable ?
Well, it would be suitable (evidence suggests it has already been done),
but I just don’t see it as compelling. For user-mode apps, what I found
compelling about Delphi was the IDE, the VCL, and the window designer.
None of those things really apply in kernel code.
If I had both available to me right now for writing drivers, I’m not
sure I would choose Delphi. Kernel code necessarily does a lot of
pointer manipulation and casting of data types for buffers and such.
The Delphi syntax for that is really ugly to read, in my unbiased opinion.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Manipulating the SSDT, IDT, IAT… using the method is just one of the basic tricks for rootkits.
How? goto http://www.rootkit.com
Why? in kernel mode, you’re part of the kernel, you can do ANYTHING.
>Tim, good reply. thanks. yeh, the same RAM be refered by two PTE(remember
the virtual address i mentioned is the system address like IDT address or
SSDT address), and the two PTE has different protection properties: one has
read only property and one has writable property, then if the driver write
the RAM, e.g. a driver write the SSDT(assume), let the service routine
address be itself’s, in this case, what should the system do? It continue
think that the SSDT is real only, just call the service routine that has
been replaced?
thanks
Ma
> I figure that if you like C# you must also like Delphi as the language
was designed by the same person (Hejlsberg). Unfortunately it’s dying a
slow death and there is still no native support x64 code as of today
(Delphi 2009).
Really? That makes so much sense to me now! I used Borland’s C++ Builder
for many, many years of user-mode code. It shipped with the VCL,
included language extensions such as properties, and had a visual editor
that was a dream compared to MFC’s offerings. Shortly before switching
to C#/.NET for most of my user-mode development, I had to work in MFC
for about 6 months - and it was like entering the stone age…
I’ve noticed a lot of similarities between the BCL and the VCL, though
of course the BCL is much farther reaching and has learned some “don’t
do this” lessons of the VCL. I’ve also been really pleased that VS’s
design time support (for .NET) finally surpasses Borland’s products.
I agree there are practical objections against writing drivers for
Windows in Delphi but don’t you think the language in itself and the
compiler could just be very suitable ?
I have a little side project that I pull out every once in a while. It’s
a design for an interpreted language (with the future possibility of
JIT-compiling) specifically for kernel-mode code. Has anyone else here
given this much thought?
It doesn’t take much to iron out the wrinkles in C and add some
higher-level constructs. Right now, I’m playing around with a pageable
qualifier concept, which would operate like a cv-qualifier, but indicate
that a certain memory block is in pageable memory.
I believe that a good language design would remove a lot of the need for
static analysis tools.
