It is a long time now that I am using "Dependency Walker for Win32" and
navigating through different Dlls in "System32" folder to find my target API
functions. The thing I have noticed is that, 'almost' all system .dll and
..exe
files are written in C and not C++. If C++ is a powerful OO language and
it's much greater than C for large application development, then why haven't
Microsoft used it in its operating system? Is there a compatibility issue
here that I am not aware of? Or something else?
---
Thanks for comments
12  1409 
Herr Lucifer wrote: It is a long time now that I am using "Dependency Walker for Win32" and
navigating through different Dlls in "System32" folder to find my target API
functions. The thing I have noticed is that, 'almost' all system .dll and
.exe
files are written in C and not C++. If C++ is a powerful OO language and
it's much greater than C for large application development, then why haven't
Microsoft used it in its operating system? Is there a compatibility issue
here that I am not aware of? Or something else?
How can you tell that they are written in C? Have you examined the
assembler to look for the presence of C++ startup code (such as the
running of global object constructors)? Remember that C++ code need not
dynamically link with the C++ runtime, and it need not present a C++
interface to the outside world.
Tom
The GDI system is written in C++, at least. Herr Lucifer wrote: It is a long time now that I am using "Dependency Walker for Win32" and
navigating through different Dlls in "System32" folder to find my target
API functions. The thing I have noticed is that, 'almost' all system .dll
and .exe
files are written in C and not C++. If C++ is a powerful OO language and
it's much greater than C for large application development, then why
haven't Microsoft used it in its operating system? Is there a compatibility
issue here that I am not aware of? Or something else?
How can you tell that they are written in C? Have you examined the
assembler to look for the presence of C++ startup code (such as the
running of global object constructors)? Remember that C++ code need not
dynamically link with the C++ runtime, and it need not present a C++
interface to the outside world.
Tom
I don't know what you think of C++, but in its earliest definition, C++ was
called "C with classes". So if there is no class in there, there is no C++
code; it is just pure C....
PS: dependency walker (version 2.1.36668) is able to show functions inside
their classes if their are C++. Take a look if you have VS.NET 2003
-----------------------
"Tom Widmer" <to********@hotmail.com> wrote in message How can you tell that they are written in C? Have you examined the
assembler to look for the presence of C++ startup code (such as the
running of global object constructors)? Remember that C++ code need not
dynamically link with the C++ runtime, and it need not present a C++
interface to the outside world.
Tom
"Herr Lucifer" <"\n"HerrLucifer\n@microsoft.com> wrote in message
news:el**************@TK2MSFTNGP10.phx.gbl... I don't know what you think of C++, but in its earliest definition,
C++ was called "C with classes". So if there is no class in there,
there is no C++ code; it is just pure C....
PS: dependency walker (version 2.1.36668) is able to show
functions inside their classes if their are C++. Take a look if
you have VS.NET 2003
If the fundamental Windows API exported classes then surely it would
only be accessible to programs written in C++.
There *is* a version which exports classes - it is called MFC most
of which is a very thin wrapper around the Windows API. [And it
isn't particularly object-oriented.]
Dave
--
David Webber
Author MOZART the music processor for Windows - http://www.mozart.co.uk
For discussion/support see http://www.mozart.co.uk/mzusers/mailinglist.htm
Herr Lucifer" <"\n wrote: It is a long time now that I am using "Dependency Walker for Win32"
and navigating through different Dlls in "System32" folder to find my
target API functions. The thing I have noticed is that, 'almost' all
system .dll and .exe
files are written in C and not C++. If C++ is a powerful OO language
and it's much greater than C for large application development, then
why haven't Microsoft used it in its operating system? Is there a
compatibility issue here that I am not aware of? Or something else?
A great deal of Windows, especially in the user-mode components, is written
in C++. It simply exposes a pure-C API since that's the only ABI
(Application Binary Interface) defined for Windows. A C++ API would not be
callable by any language other than C++.
The Kernel is written almost entirely in C, with a very few bits of
assembler here and there.
-cd
Herr Lucifer wrote: I don't know what you think of C++, but in its earliest definition, C++ was
called "C with classes". So if there is no class in there, there is no C++
code; it is just pure C....
PS: dependency walker (version 2.1.36668) is able to show functions inside
their classes if their are C++. Take a look if you have VS.NET 2003
Only if they are exported though! The *interface* is C (to allow
interoperability with as many other languages as possible, such as C,
C++, Delphi, VB, etc.), but that doesn't tell you anything about the
language with which the dll is implemented. The DLL code could include
thousands of C++ classes, but the interface still be exposed as pure C.
For example, I've got a C++ DLL that I've written containing lots of
classes but it only exposes a C API (since Java JNI only interacts with
specific exported C functions). Dependency Walker doesn't show the
classes at all, and it doesn't tell you what language was used.
IOW, Dependency Walker is a useless tool for determining what language a
module was implemented with.
Tom
On Wed, 9 Feb 2005 14:07:44 +0330, "Herr Lucifer"
<"\n"HerrLucifer\n@microsoft.com> wrote: It is a long time now that I am using "Dependency Walker for Win32" and
navigating through different Dlls in "System32" folder to find my target API
functions. The thing I have noticed is that, 'almost' all system .dll and
.exe
files are written in C and not C++. If C++ is a powerful OO language and
it's much greater than C for large application development, then why haven't
Microsoft used it in its operating system? Is there a compatibility issue
here that I am not aware of? Or something else?
---
IMHO:
For time-critical issues, smaller code size, better memory
consumption, improved control over efficiency, improved code
generation, simpler interface to assembler, and easier debugging
(especially the kernel and low-level code) the guts of Windows are
mostly written in C.
Additionally, much of the Windows (NT) kernel is based on VMS, which
was written in Bliss32 and VAX assembly, which were much easier to
implement as C.
Microsoft's C++ code (for the shell, directx, COM, etc.) are bizarre
and obfuscated anyway. Were Windows internals written in C++, I would
cry.
--
Sev
Severian wrote: On Wed, 9 Feb 2005 14:07:44 +0330, "Herr Lucifer"
<"\n"HerrLucifer\n@microsoft.com> wrote:
It is a long time now that I am using "Dependency Walker for Win32" and
navigating through different Dlls in "System32" folder to find my target API
functions. The thing I have noticed is that, 'almost' all system .dll and
.exe
files are written in C and not C++. If C++ is a powerful OO language and
it's much greater than C for large application development, then why haven't
Microsoft used it in its operating system? Is there a compatibility issue
here that I am not aware of? Or something else?
---
IMHO:
For time-critical issues,
Do you mean that C is faster executing? Or that its performance is more
consistent (for a realtime system)? I don't think either statement is
particularly true, though some C and C++ features should be avoided in
code that should run in a bounded amount of time (e.g. no dynamic
allocation, no disk IO, etc.).
smaller code size, better memory consumption,
C does generally produce slightly smaller code, due to the overhead EH
and RTTI in C++. However, both of those may be avoided if desired.
improved control over efficiency,
How so?
improved code generation,
The code generation is generally worse in C, since I believe that type
based alias analysis isn't as good in C. Is there any other respect in
which you think C can generate better code?
simpler interface to assembler,
What do you mean?
and easier debugging (especially the kernel and low-level code)
But macros are far harder to debug than inline functions!
the guts of Windows are mostly written in C.
That I know nothing about, but it certainly sounds true. But I believe
much of the Linux kernel is now written in C++ (as was BeOS). C++ is
primarily a systems programming language - it was specifically designed
for writing OSes (among other things), hence the priniciple of "You
don't pay for what you don't use."
I'd definitely prefer to write an OS in C++ rather than C, and the
resulting OS would probably be faster and better for it (though possibly
not smaller).
Tom
On Thu, 10 Feb 2005 18:07:35 +0000, Tom Widmer
<to********@hotmail.com> wrote: Severian wrote: On Wed, 9 Feb 2005 14:07:44 +0330, "Herr Lucifer"
<"\n"HerrLucifer\n@microsoft.com> wrote:
It is a long time now that I am using "Dependency Walker for Win32" and
navigating through different Dlls in "System32" folder to find my target API
functions. The thing I have noticed is that, 'almost' all system .dll and
.exe
files are written in C and not C++. If C++ is a powerful OO language and
it's much greater than C for large application development, then why haven't
Microsoft used it in its operating system? Is there a compatibility issue
here that I am not aware of? Or something else?
---
IMHO:
For time-critical issues,
Do you mean that C is faster executing? Or that its performance is more
consistent (for a realtime system)? I don't think either statement is
particularly true, though some C and C++ features should be avoided in
code that should run in a bounded amount of time (e.g. no dynamic
allocation, no disk IO, etc.).
Sorry, I wasn't trying to start a language war. I program in both C
and C++, and have seen plenty of good and bad examples of both. I was
comparing well-written C with well-written C++ (not simply C-like code
compiled by a C++ compiler).
But generally, when using the constructs that make C++ a great
language, it is very much simpler to estimate the overhead of C
statements vs. C++ statements. (I'm not talking about C code compiled
by a C++ compiler!)
smaller code size, better memory consumption,
C does generally produce slightly smaller code, due to the overhead EH
and RTTI in C++. However, both of those may be avoided if desired.
In my experience, you have to know a lot more about C++ (and how it is
implemented on a particular platform) to make it as efficient (memory
and speed-wise) as well-written C.
improved control over efficiency,
How so?
Because, as examples, overloaded operators and virtual functions
introduce non-obvious overhead that is more explicit in C.
improved code generation,
The code generation is generally worse in C, since I believe that type
based alias analysis isn't as good in C. Is there any other respect in
which you think C can generate better code?
You're probably right, in the general case of compiling simple C++
code; and in some cases (i.e., templates) even when generating complex
code. But once you start using the things that make C++ such a
wonderful language, the generated code tends, in my experience, to
become bloated and wasteful -- and much more difficult to debug.
simpler interface to assembler,
What do you mean?
I am speaking of calling assembly from C++ or vice versa, not inline
assembly, which is quite platform-specific.
One example: since assembly language has no concept of C++ objects,
you have to "deobjectify" any data you want to access from assembler
(or C for that matter!), or know a lot about how a particular C++
compiler represents objects in memory and write extra assembly
language to work with them.
and easier debugging (especially the kernel and low-level code)
But macros are far harder to debug than inline functions!
Most modern C compilers include inline functions, though by looking at
code generated by MS and GNU C++, macros are often much more
efficient, and thus often more appropriate for OS code.
The difficulty I was referring to was the semi-invisible things that
C++ does, that require you to know the implementation of classes you
use. Overloaded operators (-> and [] come immediately to mind) make
debugging a loathesome task unless you have access to the source code
for the original class. Even in those cases, it's often difficult to
figure out what exactly is going on behind the scenes.
I've seen well-written C++ code that is a joy to work with, but a lot
more of it is obfuscated (unintentionally?) to the point of
hair-pulling. Most of Microsoft's C++ falls into the latter category!
When writing C++, I love STL and wish that MS had not tried to make
their own horrid messes first.
the guts of Windows are mostly written in C.
That I know nothing about, but it certainly sounds true. But I believe
much of the Linux kernel is now written in C++ (as was BeOS). C++ is
primarily a systems programming language - it was specifically designed
for writing OSes (among other things), hence the priniciple of "You
don't pay for what you don't use."
I agree that well-written C++ code (in a _specific_ rather than
generic way) is very appropriate for operating systems, as long as
provisions are made for using the OS API from other languages.
I'd definitely prefer to write an OS in C++ rather than C, and the
resulting OS would probably be faster and better for it (though possibly
not smaller).
I think it boils down to whether the code is well-written or not; the
simpler basis of C makes it easier, in my opinion, to write efficient
and understandable code. That being said, I have worked with and
(hope) I have written efficient and easily maintainable C++ code as
well.
--
Sev
In article <#y*************@TK2MSFTNGP15.phx.gbl>, phil@private-
citizen.com says...
[ top posting fixed ] "benben" <be******@yahoo.com.au> wrote in message
news:uK**************@TK2MSFTNGP10.phx.gbl... The GDI system is written in C++, at least.
GDI+, not GDI.
GDI doesn't attempt to present an OO interface like GDI+ does, but
GDI is written (primarily) in C++ as well.
Going back to the original question, I think it's worth considering
the simple age of a great deal of the code -- much of the code in
Windows XP goes all the way back to Windows NT 3.1.
Microsoft had only been selling a C++ compiler for about a year when
Windows NT 3.1 started beta testing. Unless we assume that Windows NT
was written from the ground up in less than a year we have to admit
that they really only had a couple of choices: they could use
somebody else's compiler, or they could write in C. Given how much MS
was betting on Windows NT, I can't imagine them depending on anybody
else's technology to build it.
That pretty much ruled out using C++ except for a few of the last
parts to be written.
It's also been pointed out that the exported functions don't
necessarily reflect the language of origin. For a solid example of
this, I'd advise anybody to use dumpbin to look at the functions
exported from ATL.DLL and note that they all look distinctly C-like.
Looking at the source code (which is distributed as part of VC++ and
VS++) will leave little doubt that it really is written in C++.
--
Later,
Jerry.
The universe is a figment of its own imagination.
I think a point regarding operating systems is being missed. Any operating
system has 3 key compents process management, memory management and I/O.
Thats it. Everything else is application. The OS allocates memory, loads a
process into said memory and begins execution of said process. After that it
switches context between services interrupts, passing instructions to the CPU
and moving bits about memory.
All of this has to be small and preferrable fast. So its all assembly or C,
because C++ requires a fat runtime and excessive memory management. The guts
of windows primarily reside in nt.dll and kernel32.dll, both under 1MB. These
binary contain the Native API in 100% C wrapped around assembly. The
subsystems that sit on top of this, the most well known being the Win32
subsytem, basically wrap around these native api calls, translating the
low-level system objects like disks, partition, and file descriptors into
things we can visualize like drives, directories etc. Could the Win32
subsystem be implemented in C++, of course. But unless something genuinely
need to be implemented in OOP, why bother.
In my experience, and I use both C and C++ regularly, many developers lock
themselves into one contruct...either they hate OOP or they can't do without
it. The result, you get a lot of over-coding from both camps. There are
things you can do in 10 line of C++ that requires hunders of lines of C, and
the inverse is true as well.
Programming languages are tools and like any good mechanic, a programmer has
toolbox too heavy for amatuers to even lift.
"Severian" wrote: On Thu, 10 Feb 2005 18:07:35 +0000, Tom Widmer
<to********@hotmail.com> wrote:
Severian wrote: On Wed, 9 Feb 2005 14:07:44 +0330, "Herr Lucifer"
<"\n"HerrLucifer\n@microsoft.com> wrote:
It is a long time now that I am using "Dependency Walker for Win32" and
navigating through different Dlls in "System32" folder to find my target API
functions. The thing I have noticed is that, 'almost' all system .dll and
.exe
files are written in C and not C++. If C++ is a powerful OO language and
it's much greater than C for large application development, then why haven't
Microsoft used it in its operating system? Is there a compatibility issue
here that I am not aware of? Or something else?
---
IMHO:
For time-critical issues,
Do you mean that C is faster executing? Or that its performance is more
consistent (for a realtime system)? I don't think either statement is
particularly true, though some C and C++ features should be avoided in
code that should run in a bounded amount of time (e.g. no dynamic
allocation, no disk IO, etc.).
Sorry, I wasn't trying to start a language war. I program in both C
and C++, and have seen plenty of good and bad examples of both. I was
comparing well-written C with well-written C++ (not simply C-like code
compiled by a C++ compiler).
But generally, when using the constructs that make C++ a great
language, it is very much simpler to estimate the overhead of C
statements vs. C++ statements. (I'm not talking about C code compiled
by a C++ compiler!)
smaller code size, better memory consumption,
C does generally produce slightly smaller code, due to the overhead EH
and RTTI in C++. However, both of those may be avoided if desired.
In my experience, you have to know a lot more about C++ (and how it is
implemented on a particular platform) to make it as efficient (memory
and speed-wise) as well-written C.
improved control over efficiency,
How so?
Because, as examples, overloaded operators and virtual functions
introduce non-obvious overhead that is more explicit in C.
improved code generation,
The code generation is generally worse in C, since I believe that type
based alias analysis isn't as good in C. Is there any other respect in
which you think C can generate better code?
You're probably right, in the general case of compiling simple C++
code; and in some cases (i.e., templates) even when generating complex
code. But once you start using the things that make C++ such a
wonderful language, the generated code tends, in my experience, to
become bloated and wasteful -- and much more difficult to debug.
simpler interface to assembler,
What do you mean?
I am speaking of calling assembly from C++ or vice versa, not inline
assembly, which is quite platform-specific.
One example: since assembly language has no concept of C++ objects,
you have to "deobjectify" any data you want to access from assembler
(or C for that matter!), or know a lot about how a particular C++
compiler represents objects in memory and write extra assembly
language to work with them.
and easier debugging (especially the kernel and low-level code)
But macros are far harder to debug than inline functions!
Most modern C compilers include inline functions, though by looking at
code generated by MS and GNU C++, macros are often much more
efficient, and thus often more appropriate for OS code.
The difficulty I was referring to was the semi-invisible things that
C++ does, that require you to know the implementation of classes you
use. Overloaded operators (-> and [] come immediately to mind) make
debugging a loathesome task unless you have access to the source code
for the original class. Even in those cases, it's often difficult to
figure out what exactly is going on behind the scenes.
I've seen well-written C++ code that is a joy to work with, but a lot
more of it is obfuscated (unintentionally?) to the point of
hair-pulling. Most of Microsoft's C++ falls into the latter category!
When writing C++, I love STL and wish that MS had not tried to make
their own horrid messes first.
the guts of Windows are mostly written in C.
That I know nothing about, but it certainly sounds true. But I believe
much of the Linux kernel is now written in C++ (as was BeOS). C++ is
primarily a systems programming language - it was specifically designed
for writing OSes (among other things), hence the priniciple of "You
don't pay for what you don't use."
I agree that well-written C++ code (in a _specific_ rather than
generic way) is very appropriate for operating systems, as long as
provisions are made for using the OS API from other languages.
I'd definitely prefer to write an OS in C++ rather than C, and the
resulting OS would probably be faster and better for it (though possibly
not smaller).
I think it boils down to whether the code is well-written or not; the
simpler basis of C makes it easier, in my opinion, to write efficient
and understandable code. That being said, I have worked with and
(hope) I have written efficient and easily maintainable C++ code as
well.
--
Sev
"Rob" <Ro*@discussions.microsoft.com> wrote in message
news:44**********************************@microsof t.com... All of this has to be small and preferrable fast. So its all assembly or
C,
because C++ requires a fat runtime and excessive memory management.
A common misperception, but largely untrue. The big exception is C++
IOStreams which IS a huge runtime, but an OS, even one written in C++ would
be unlikely to use IOStreams IMO.
The guts
of windows primarily reside in nt.dll and kernel32.dll, both under 1MB.
These binary contain the Native API in 100% C wrapped around assembly. The
subsystems that sit on top of this, the most well known being the Win32
subsytem, basically wrap around these native api calls, translating the
low-level system objects like disks, partition, and file descriptors into
things we can visualize like drives, directories etc. Could the Win32
subsystem be implemented in C++, of course. But unless something genuinely
need to be implemented in OOP, why bother.
Not quite true. ntdll.dll is nothing but a gateway - there's virtually no
actual code in there. The kernel code is in ntoskrnl.exe (2Mb) plus a
number of kernel-mode DLLs and tons of device drivers.
kernel32.dll is the basic Win32 API (Process/Thread API, File/IO API
mostly). These are generally thin wrappers over the "native API" exposed by
ntdll.dll and are written in C (mostly if not entirely).
The windowing portion of the OS is primarily implemented by user32.dll,
gdi32.dll and win32k.sys, which are written in C (mostly if not entirely).
Many of the other Win32 API components are in fact written in C++.
In all of the OS code there is virtually no assembly language other than
some start up code and the lowest level CPU support code in the HAL.
-cd This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: sidd |
last post by:
Hi All,
i have some doubts on .net windows services..
please see if some one could help me understand this..
1)is it possible to install a windows service which does not have a
installer added...
|
by: SP |
last post by:
Hi All,
I wrote a windows service which is supposed to stop after specified amount
of time. I am calling OnStop() after specified time. OnStop() methods
executed but I dont see the service...
|
by: Blaxer |
last post by:
I have read approximately 30 articles now on various methods to make your
vb.net application automatically update itself and I can't see how they apply
to a vb.net windows services projects. The...
|
by: sidd |
last post by:
Hi All,
i have some doubts on .net windows services..
please see if some one could help me understand this..
1)is it possible to install a windows service which does not have a
installer added...
|
by: =?Utf-8?B?TWlrZVo=?= |
last post by:
How Can Windows Service Application Reatarts itself? Thanks.
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
