«

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

"shakeel-ur-rehman" <> wrote...
> 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

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.

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

E. Robert Tisdale wrote:

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

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.

"Rolf Magnus" <> wrote in message
news:butl1f$fae$05$...
> E. Robert Tisdale wrote:
>
> > 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.
>
> 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.

dude wrote:

>
> "Rolf Magnus" <> wrote in message
> news:butl1f$fae$05$...
>> E. Robert Tisdale wrote:
>>
>> > 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.
>>
>> 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?

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.

> 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 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.
> >
> > So C and C++ don't have any way to communicate directly w/hardware?
>
> Right.

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

regards,
alexander.

Rolf Magnus wrote:
> E. Robert Tisdale wrote:
>
>
>>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.
>
>
> 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

Thomas Matthews 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.
>>
>>
>> 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++.

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.

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

Alexander Terekhov wrote:
> http://anubis.dkuug.dk/jtc1/sc22/wg2.../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");
}