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]

Re: sector , file and partition reading in C++

"shakeel-ur-rehman" <shakeelj2k@yah oo.com> wrote...[color=blue]
> 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++.[/color]

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]

Re: sector , file and partition reading in C++

Victor Bazarov wrote:
[color=blue]
> Neither C nor C++ has any means
> to control/communicate with a device (in your case a hard drive).[/color]

Nonsense!
Most hardware drivers are written in C.
[color=blue]
> Whatever mechanisms are available for that
> are hardware- and platform-specific and as such are OT here.[/color]

That is correct.
[color=blue]
> Please ask in the newsgroup that deals with [Assembler][/color]

Please don't. This would be off-topic there as well.
[color=blue]
> or with your [Operating System]
> (even though you don't want to use their API, you may have to).[/color]

Correct.

[Rolf Magnus]

Re: sector , file and partition reading in C++

E. Robert Tisdale wrote:
[color=blue]
> Victor Bazarov wrote:
>[color=green]
>> Neither C nor C++ has any means
>> to control/communicate with a device (in your case a hard drive).[/color]
>
> Nonsense!
> Most hardware drivers are written in C.[/color]

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]

Re: sector , file and partition reading in C++


"Rolf Magnus" <ramagnus@t-online.de> wrote in message
news:butl1f$fae $05$1@news.t-online.com...[color=blue]
> E. Robert Tisdale wrote:
>[color=green]
> > Victor Bazarov wrote:
> >[color=darkred]
> >> Neither C nor C++ has any means
> >> to control/communicate with a device (in your case a hard drive).[/color]
> >
> > Nonsense!
> > Most hardware drivers are written in C.[/color]
>
> 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.[/color]

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]

Re: sector , file and partition reading in C++

dude wrote:
[color=blue]
>
> "Rolf Magnus" <ramagnus@t-online.de> wrote in message
> news:butl1f$fae $05$1@news.t-online.com...[color=green]
>> E. Robert Tisdale wrote:
>>[color=darkred]
>> > Victor Bazarov wrote:
>> >
>> >> 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.[/color]
>>
>> 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.[/color]
>
> So C and C++ don't have any way to communicate directly w/hardware?[/color]

Right.
[color=blue]
> You can write an OS in almost all C...[/color]

....but only with system specific extensions that are not part of the
language itself (though they can often be used with that language).
[color=blue]
> 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?[/color]

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.
[color=blue]
> Wouldn't that be slow for programs like Norton Ghost and the like???[/color]

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.
[color=blue]
> 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.[/color]

[Alexander Terekhov]

Re: sector , file and partition reading in C++


Rolf Magnus wrote:
[...][color=blue][color=green][color=darkred]
> >> 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.[/color]
> >
> > So C and C++ don't have any way to communicate directly w/hardware?[/color]
>
> Right.[/color]

http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/PDTR18015.pdf

(see "The <hardware> Interface for C++")

regards,
alexander.

[Thomas Matthews]

Re: sector , file and partition reading in C++

Rolf Magnus wrote:[color=blue]
> E. Robert Tisdale wrote:
>
>[color=green]
>>Victor Bazarov wrote:
>>
>>[color=darkred]
>>>Neither C nor C++ has any means
>>>to control/communicate with a device (in your case a hard drive).[/color]
>>
>>Nonsense!
>>Most hardware drivers are written in C.[/color]
>
>
> 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.
>[/color]

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_RE G = 0x4000;
char read_from_uart( void)
{
return *UART_RECEIVE_R EG;
}

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.l earn.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]

Re: sector , file and partition reading in C++

Thomas Matthews wrote:
[color=blue][color=green][color=darkred]
>>>>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.[/color]
>>
>>
>> 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.
>>[/color]
>
> If the hardware is memory mapped, then you don't need any system
> specific extensions to the language, whether it be C or C++.[/color]

Yes, you do. That memory mapping already _is_ the system specific
extension.
[color=blue]
> 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_RE G = 0x4000;[/color]

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]

Re: sector , file and partition reading in C++


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

Alexander Terekhov wrote:[color=blue]
> http://anubis.dkuug.dk/jtc1/sc22/wg2.../PDTR18015.pdf
> (see "The <hardware> Interface for C++")[/color]

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.sa y("frode at age dee dee dot en oh");
}

[Karl Heinz Buchegger]

Re: sector , file and partition reading in C++

Fred H wrote:[color=blue]
>
> 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 :-) )[/color]

Slightly off-topic?

Completely off-topic.

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


--
Karl Heinz Buchegger
kbuchegg@gascad .at

[Fred H]

Re: sector , file and partition reading in C++


Thank you for your timely reply... :\

[color=blue]
> Slightly off-topic?
>
> Completely off-topic.[/color]

But still in the context of the thread.

[color=blue]
> What about asking in a newsgroup which at least deals with
> your operating system.[/color]

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]

Re: sector , file and partition reading in C++

Fred H wrote:[color=blue]
>
> Thank you for your timely reply... :\
>[color=green]
> > Slightly off-topic?
> >
> > Completely off-topic.[/color]
>
> But still in the context of the thread.[/color]

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++
[color=blue]
>[color=green]
> > What about asking in a newsgroup which at least deals with
> > your operating system.[/color]
>
> 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...?[/color]

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.

--
Karl Heinz Buchegger
kbuchegg@gascad .at

[Fred H]

Re: sector , file and partition reading in C++

[color=blue]
> Those very same people might provide a wonderful answer
> in one of the groups where your question is on topic.[/color]

....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.sa y("frode at age dee dee dot en oh");
}

[osmium]

Re: sector , file and partition reading in C++

Fred H writes:

[color=blue][color=green]
> > Those very same people might provide a wonderful answer
> > in one of the groups where your question is on topic.[/color]
>
> ...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 ;-)[/color]

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.program mer.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.