sector , file and partition reading in C++

Discussion in 'C++' started by shakeel-ur-rehman, Jan 24, 2004.

  1. 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, Jan 24, 2004
    #1
    1. Advertising

  2. "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, Jan 24, 2004
    #2
    1. Advertising

  3. 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, Jan 24, 2004
    #3
  4. shakeel-ur-rehman

    Rolf Magnus Guest

    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, Jan 24, 2004
    #4
  5. shakeel-ur-rehman

    dude Guest

    "Rolf Magnus" <> wrote in message
    news:butl1f$fae$05$-online.com...
    > 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, Jan 24, 2004
    #5
  6. shakeel-ur-rehman

    Rolf Magnus Guest

    dude wrote:

    >
    > "Rolf Magnus" <> wrote in message
    > news:butl1f$fae$05$-online.com...
    >> 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, Jan 24, 2004
    #6
  7. 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/wg21/docs/PDTR18015.pdf
    (see "The <hardware> Interface for C++")

    regards,
    alexander.
    Alexander Terekhov, Jan 24, 2004
    #7
  8. 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, Jan 25, 2004
    #8
  9. shakeel-ur-rehman

    Rolf Magnus Guest

    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.
    Rolf Magnus, Jan 26, 2004
    #9
  10. shakeel-ur-rehman

    Fred H Guest

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

    Alexander Terekhov wrote:
    > 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");
    }
    Fred H, Jan 26, 2004
    #10
  11. Fred H wrote:
    >
    > 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.


    --
    Karl Heinz Buchegger
    Karl Heinz Buchegger, Jan 26, 2004
    #11
  12. shakeel-ur-rehman

    Fred H Guest

    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...?
    Fred H, Jan 26, 2004
    #12
  13. Fred H wrote:
    >
    > Thank you for your timely reply... :\
    >
    > > Slightly off-topic?
    > >
    > > Completely off-topic.

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

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


    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
    Karl Heinz Buchegger, Jan 26, 2004
    #13
  14. shakeel-ur-rehman

    Fred H Guest


    > 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");
    }
    Fred H, Jan 26, 2004
    #14
  15. shakeel-ur-rehman

    osmium Guest

    Fred H writes:


    > > 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 ;-)


    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, Jan 26, 2004
    #15
  16. shakeel-ur-rehman

    osmium Guest

    osmium writes:

    > 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!!
    osmium, Jan 26, 2004
    #16
  17. shakeel-ur-rehman

    red floyd Guest

    osmium wrote:
    > osmium writes:
    >
    >
    >>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!!
    >
    >


    Of course, given that petrol burns easily.... :)
    red floyd, Jan 26, 2004
    #17
  18. U¿ytkownik "Fred H" <> napisa³ w wiadomoœci
    news:eek:...
    >
    > 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
    Krzysztof Zelechowski, Feb 1, 2004
    #18
  19. On Sun, 1 Feb 2004 23:10:08 +0100, "Krzysztof Zelechowski" <> wrote:

    >
    >U¿ytkownik "Fred H" <> napisa³ w wiadomoœci
    >news:eek:...
    >>
    >> 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


    <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.
    Alf P. Steinbach, Feb 1, 2004
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. news
    Replies:
    0
    Views:
    358
  2. Replies:
    7
    Views:
    987
    Claudio Grondi
    Oct 13, 2005
  3. Gnurto
    Replies:
    3
    Views:
    1,218
    Victor Bazarov
    Dec 5, 2005
  4. Replies:
    1
    Views:
    373
    Victor Bazarov
    Oct 9, 2006
  5. bolega
    Replies:
    1
    Views:
    675
    Stan Bischof
    Mar 28, 2011
Loading...

Share This Page