sector , file and partition reading in C++

[shakeel-ur-rehman]

I am wrtiting programm in C++ to read/take complete image of the
partiton. can any one let me know the internet resources and web
sites having tutorials relating to this and tell any sequence of how
to writing code in order to catch and complete directory structure of
a partition with out using windows API i mean only assembly and C or
C++.
Shakeel

 

[Victor Bazarov]

I am wrtiting programm in C++ to read/take complete image of the
partiton. can any one let me know the internet resources and web
sites having tutorials relating to this and tell any sequence of how
to writing code in order to catch and complete directory structure of
a partition with out using windows API i mean only assembly and C or
C++.

Neither C nor C++ has any means to control/communicate with a device
(in your case a hard drive). Whatever mechanisms are available for
that are hardware- and platform-specific and as such are OT here.

Please ask in the newsgroup that deals with Assembly or with your OS
(even though you don't want to use their API, you may have to).

V

 

[E. Robert Tisdale]

Neither C nor C++ has any means
to control/communicate with a device (in your case a hard drive).

Nonsense!
Most hardware drivers are written in C.

Whatever mechanisms are available for that
are hardware- and platform-specific and as such are OT here.

That is correct.

Please ask in the newsgroup that deals with [Assembler]

Please don't. This would be off-topic there as well.

or with your [Operating System]
(even though you don't want to use their API, you may have to).

Correct.

 

[Rolf Magnus]

Nonsense!
Most hardware drivers are written in C.

If people write about "C" or "C++" here, they mean those languages as
defined by the ISO/IEC standards, and those really don't have any way
to control hardware. You need system specific extensions that are not
part of the language itself.

 

[dude]

If people write about "C" or "C++" here, they mean those languages as
defined by the ISO/IEC standards, and those really don't have any way
to control hardware. You need system specific extensions that are not
part of the language itself.

So C and C++ don't have any way to communicate directly w/hardware? You can
write an OS in almost all C... So if you booted to DOS or something like
that you would HAVE to use the DOS interrupts to read/write to the hard
drive? Wouldn't that be slow for programs like Norton Ghost and the like???

I know this is off topic but Robert said it would be off topic in an
Assembler group as well. If C can't do it Assembler certainly could.

 

[Rolf Magnus]

So C and C++ don't have any way to communicate directly w/hardware?
Right.

You can write an OS in almost all C...

....but only with system specific extensions that are not part of the
language itself (though they can often be used with that language).

So if you booted to DOS or something like that you would HAVE to use
the DOS interrupts to read/write to the hard drive?

You have to use the standard C and C++ functions to open, read and write
files. Whether those files are at all on a hard drive depends on the
system.
However, that doesn't mean that you can't use C or C++ to do low-level
work like raw disk sector reading/writing or directly access hardware
like you need to do in a driver. If you're programming for a specific
system, you can of course take advantage of that and use whatever
possibilities that system offers you, which is usually much more. It's
just that the languages have no built-in facilities for it, since
operating systems and hardware devices are just too different from each
other and evolving too fast, so such facilities would always be
non-portable.

Wouldn't that be slow for programs like Norton Ghost and the like???

Are those still running under DOS? Note that many modern operating
systems don't even give you direct access to hardware, since that would
endanger system integrity.

 

[Alexander Terekhov]

Rolf Magnus wrote:
[...]

Right.

http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/PDTR18015.pdf
(see "The <hardware> Interface for C++")

regards,
alexander.

 

[Thomas Matthews]

E. Robert Tisdale wrote:




If people write about "C" or "C++" here, they mean those languages as
defined by the ISO/IEC standards, and those really don't have any way
to control hardware. You need system specific extensions that are not
part of the language itself.

If the hardware is memory mapped, then you don't need any system
specific extensions to the language, whether it be C or C++.

For example, if a UART receive register is located at 0x4000 and
it is CHAR_BITS wide, then one could read a character by:
volatile char * const UART_RECIEVE_REG = 0x4000;
char read_from_uart(void)
{
return *UART_RECEIVE_REG;
}

In the above example, it is valid C++. The location is volatile
because its value is changed by the hardware without the program's
control. The pointer is constant because the UART's receive
register is mapped to a fixed address in memory.

If the hardware devices are mapped to a different space, such
as ports, then some kind of language extension is required since
the C++ language does not have facilities for ports.

If an application, whether it be embbeded or not, wants to use
an operating system function for accessing hardware, then those
functions are not part of the _standard_ language. The functions
would be platform specific.

Since I have used specific values for addresses, the function
is not portable; but it is still compliant.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library

 

[Rolf Magnus]

If the hardware is memory mapped, then you don't need any system
specific extensions to the language, whether it be C or C++.

Yes, you do. That memory mapping already _is_ the system specific
extension.

For example, if a UART receive register is located at 0x4000 and
it is CHAR_BITS wide, then one could read a character by:
volatile char * const UART_RECIEVE_REG = 0x4000;

The result of an integer-to-pointer conversion is implementation
defined. That means that the C++ standard doesn't actually state what
the value of the resulting pointer will be if you assign 0x4000 to it,
IOW it's system specific, and of course it's also system specific
whether there is any special hardware at that address.
IMHO, those things all fall into the category of system specific
extensions.

 

[Fred H]

I'm faced with much the same problem as the OP.

http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/PDTR18015.pdf
(see "The <hardware> Interface for C++")

I copied the following code from the above document:

#include <hardware>
#include "driv_defs.h"
register_access<PortA1_T, Platform> devStatus;
register_access<PortA2_T, Platform> devOut;
const uint8_t statusBusy = 0x4;
uint8_t ch = ' ';
// Wait until controller is no longer busy:
while (devStatus & statusBusy) ; // do nothing
// Write some value to controller:
devOut = ch;

I get the big picture, and this is just plain beautifull.
But where can I get the <hardware> interface? And say that
I'm trying to communicate with a hard disk drive on an
Intel PC, where can I get the "drive_defs.h" for this
platform?

Where does one find information about this stuff...?

And does anyone know how (or where to find out how) one
plugs into say the Linux and Windows core, in order to
actually get the permission to do such low level calls
to a device? (Ok, slightly OT for the group, but hey,
the whole point is that I don't know where else to ask )


--
Fred H, paranoid norwegian hardware developer

void FredH::Contact() {
TextToSpeach.say("frode at age dee dee dot en oh");
}

 

[Karl Heinz Buchegger]

Where does one find information about this stuff...?

And does anyone know how (or where to find out how) one
plugs into say the Linux and Windows core, in order to
actually get the permission to do such low level calls
to a device? (Ok, slightly OT for the group, but hey,
the whole point is that I don't know where else to ask )

Slightly off-topic?

Completely off-topic.

What about asking in a newsgroup which at least deals with
your operating system.

 

[Fred H]

Thank you for your timely reply... :\

Slightly off-topic?

Completely off-topic.

But still in the context of the thread.

What about asking in a newsgroup which at least deals with
your operating system.

Sure, but why go ballistic just because I ask one OT question
in the context of the thread, when there's obviously people
present that might have an answer...?

 

[Karl Heinz Buchegger]

Thank you for your timely reply... :\


But still in the context of the thread.

How come?
Just because you program in C++, it doesn't mean that
all problems you encounter while doing your program
are automatically C++ problems and will be discussed in
comp.lang.c++

Sure, but why go ballistic just because I ask one OT question
in the context of the thread, when there's obviously people
present that might have an answer...?

Because those people know the rules of the group and ...
mark your post as off topic and don't answer.

Those very same people might provide a wonderful answer
in one of the groups where your question is on topic.

 

[Fred H]

Those very same people might provide a wonderful answer
in one of the groups where your question is on topic.

....which is why I also asked for -where- I might find
more information, since I, for one, don't know all
usefull usenet groups off the top of my head.

But this OT discussion is now getting REALLY OT,
so I'll try and find some answers elswhere.

....he bitterly groaned ;-)


--
Fred H

void FredH::Contact() {
TextToSpeach.say("frode at age dee dee dot en oh");
}

 

[osmium]

Fred H writes:

...which is why I also asked for -where- I might find
more information, since I, for one, don't know all
usefull usenet groups off the top of my head.

But this OT discussion is now getting REALLY OT,
so I'll try and find some answers elswhere.

...he bitterly groaned ;-)

Sorry for the blank post.

You have a common problem. What I would do is go to google advanced groups
and search for likely groups. Require <windows api> and at least one of
<sector file partition> Then look at the *groups* returned, not so much as
the message. You may (depending on what browser you have) be able to
examine the group for being dormant without leaving the environment you have
set up. I have just done this for your question and come up with
comp.os.ms-windows.programmer.win32 as a likely candidate.

Many of us think of Petrol as being *the* Windows API, but in fact it is
only the GUI part of the API. If I were in a hurry and couldn't find a lead
in a few minutes I would be off to the book store to look at books on the
Windows API. But of course this only works if you are in fairly sizable
city.

 

[osmium]

Many of us think of Petrol as being *the* Windows API, but in fact it is
only the GUI part of the API.

Petzold. Damn spell checker!!

 

[red floyd]

osmium writes:




Petzold. Damn spell checker!!

Of course, given that petrol burns easily....

 

[Krzysztof Zelechowski]

And does anyone know how (or where to find out how) one
plugs into say the Linux and Windows core, in order to
actually get the permission to do such low level calls
to a device? (Ok, slightly OT for the group, but hey,
the whole point is that I don't know where else to ask )

You have to write a device driver. Device drivers run in privileged
mode on Intel so you can access your hardware from there. There is no way
to work around it because only interrupts swith to privileged mode and you
have to run your code as an interrupt handler on from an interrupt handler.
Device development kits provide you with ways to do this. You have to
install the driver and reboot (Windows) to get it to work.

If you think it is nasty and you lack experience with device drivers,
try to do what you want from bare DOS. You can use Caldera DOS for that
purpose.

And besides, the SDK also provides you with some low level calls, e.g.
DeviceIOControl. Hoveewer, it is probably too limited for your needs.

Chris

 

[Alf P. Steinbach]

You have to write a device driver. Device drivers run in privileged
mode on Intel so you can access your hardware from there. There is no way
to work around it because only interrupts swith to privileged mode

<ot>
This is off-topic, but it's not true that only interrupts switch to
privileged mode. There are several mechanisms that can be used. If I
recall correctly, one such mechanism employed on x86 processors,
introduced with the 80286 (or perhaps the 386), was the "call gate".
</ot>

You're right that this is not a task that can be accomplished using
only pure standard C++, or has anything to do with C++, and so is OT.