Is there a version of DD command written in C++ or C#?

You do realise that C++ is based on C - so if you don't understand C you probably won't understand C++.  Then C# is pretty similar to C++ (and C) but with lots of presupplied classes (.NET) and basically a lack of pointers (which can be difficult to cope with so that might be a help - depends how much of pointers was involved in your code you have).

Hi Andy, yes indeed Sir and you are absolutely correct.  It's not that I don't understand C entirely, I do, but C++ was designed as a type of "C with Classes". So, I would much (MUCH) rather review a version of C++ that uses classes than to try and figure out how they coded the classes into a raw version of C, which I haven't done in decades. But you are correct, if you don't understand C, C++ would be meaningless.

As for C#, it is quite similar to C++ in that they both use classes. However, as you know, C++ can get deeper into the hardware and run natively, whereas C# runs in a type of virtual machines (that being the .NET Framework).

So, I should have stated my level of understand in the question, which may have led you to believe I simply don't understand C at all.

I really don't know anyone (personally) that codes in C any longer. They all use either C++ or some .NET version of C. You can code C++ in Xcode as well, but I usually don't use Xcode for C++.

Thank you for your comments!  

ddrescue is written in C++  in think:   https://www.gnu.org/software/ddrescue/ddrescue.html
(this is a dd that can be used to reading data from diying disks, if cannot transform data while handling it line regular dd does....).

And what is WRONG with C.... that is solved in C++.....
Anthing that can be done WRONG in C, can also be done wrong in C++,  C++ code also has buffer overflows etc. unless there is checking code created for it by the programmer.  I have seen C++ code that was near impossible to debug..., there was some issue with a malloc done for a class somewhere.
No compiler complained and depending on (probably a compiler bug) code ran into failures after 24+ hours of run time or not.....some non related source change"solved" the issue / avoided the compiler bug.  (the change was in some code & data that were NOT involved in the code path that crashed, along adding variable i and use i++ in code that would only run on termination of the program.).

Not a lot of working prorgams written in a language are rewriiten in another language just for the sake of rewriting it.
dd    from the 1970's  is proven code.  Another example rewritng AWK for example would be a humongous task, as for all features there are test scripts & code available, that would need adjustment as well).

Noci... first and foremost, thank you for your input. I will look into DDRescue, but I'm not looking for the application, I'm looking for the source code. Hopefully your link will provided that.

Regarding C++ and C and so on... listen, I'm not looking to start a "flame war" here. If you like to code in raw C, have at it... there is nothing wrong with that. Heck, you can write poems with it if you'd like. That's fine with me.

My point is that I like C++ better. Just like I like Swift better than Objective C. Swift still has some old Objective C references, but its a completely new experience. That's the way I feel about raw C. I didn't like it when I learned it back in 1988 and I don't like it now in 2022. I like C++, not because it's a beautiful language to write in, but because its simpler to use (at least to me).  That said... I never said there was anything wrong with C. I simply don't care for it unless I absolutely have to go back 30+ years and relive that experience.

However, we are all free to do what we like. If you like raw C, go to it... I applaud you for it. Its not my speed, but I'm glad you like it.

Regarding why I want to examine the DD code... I simply want to understand how it does what it does. From a Forensic perspective, I find it extremely interesting how the DD file can make an exact image copy of a disk or file. I would like to know how it does that (programmatically and examine the code). - That's all.

Again, thank you for the link and I will look into it. 

Thanks for explaining.
Should you not get further then I'd suggest looking into the C code and seeing just what you do understand AND just what needs clarification - then asking specific questions concerning those parts.

Hello Andy, thank you and yes, you have a good idea. I've been doing just that. There are a couple thousand lines of code in DD (much of it is comments), so that's going to take a while.

I just want to focus on the part that creates the image. DD does a lot of different things, like zeroing out a drive, etc. Right now, I'm just interested in learning how DD makes the image.

Thanks again and stay well.  

As @AndyAinscow, if you'd like dd written in c++ or c#, usually you can just compile C under a c++ or c# compiler.

This provides zero benefit + you can certainly do this.

Tip: The dd code is so old... so many eyes on the code... it's doubtful if changing over to C++ or any other language will fix any coding bugs, as it's doubtful any coding bugs live in code this old, that's used on every Linux install.

Using c++ will just bloat the code, by pulling in c++ libraries.

I've never seen any non-C dd code, so this suggests, if you must create a c++ version, then you'll write this yourself.

Suggestion: Clarify why you care about any of this.

The dd command is used so infrequently, likely there's a better approach than rewriting dd in c++.

Mention the exact problem you're trying to fix through a dd rewrite + likely someone can provide an alternative.

Hello David, you provided some interesting information....I actually didn't know a C program would compile under C++, that is interesting. However, the compiler won't use the library, so even if it compiles, it won't teach me what I need to learn.

To answer your question, which is a very good one - I'm interested in learning about how the DD command works, because I would like to incorporate some of its features (the image creation and image reading features) into an application I'd like to develop, but I don't want to use a 3rd party application to do that. I'd like my application to be able to be a stand alone application.

I want to write an application that reads (takes in as data) a DD image and read the file stream into my application and then reproduces the Drive / Directory / File Tree in a graphical manner. I also want to put all those file and folder artifacts into a DataGridView.

So, I thought by learning how the original DD command produces and processes a disk image, I could reproduce the features I'm interested in, into my own application using C++ or C#.

I hope that provide a better understanding of why I want to find something written in C++ or C#?

I want to be able to do the following:

1). Read a DD file into my application.
2). Produce a DD like disk image using my application.
3). Not use a 3rd party application to do these features. (Otherwise, I could just use DD and call out the commands from my app.

Thank you!

Hello Noci...VERY interesting explanation. I always though that DD was a byte by byte copy of the source (of course broken into blocks). So, you're saying that DD is nothing more than a CP command?

So based on what you're saying you could take a Text File (.txt) and use the DD command and you would get the exact same result as you would with the the CP command? You then could change the file extension from .dd back to .txt and have the same identical file?

Hmmm... I never knew that to be the case.  Im going to try that and view the two files with a Hex Editor and see if I can see a difference. Based on your explanation, if I understood it correctly, I should have two identical files.   

Hmmm.... VERY interesting experiments. OK, I'll try that. Thank you! You've given me some good leads.

WOW, all this time I thought DD was some magical data converter and unpacker that did something mystical that I never understood. Here you're saying its nothing but a glorified copy command. WOW!!!  I'm looking forward to experimenting with that.

Thanks again!

Hello Noci, WOW WOW WOW... you are 100% absolutely correct. The DD command is simply a glorified copy command.  I used the Windows10 versions in the /Git/usr/bin folder and did a DD of a simple Text file I had created. I then viewed both the original Text file and the DD file in a Hex Editor -- they were exactly the same.

I then made a copy of the DD file and changed its file extension to (.txt)... bingo, I was then able to see it with Notepad++.

Incredible.... I NEVER KNEW THAT!!!   I was always under the misconception that the DD file was some sort of magical byte by byte file reader can copier, which to some degree it is, but just not magical or mystical.

Noci Sir, you have definitely enlightened me on this subject.

Although I need to play around with this more, please be on the lookout for a few more questions from me here on EE about the DD command and how to use it to image a disk and read the byte stream back in. That is, I can do it for a file, but I need to try it out on a complete disk image, like a complete USB drive in drive E:\ for example.

However, for now... you have answered the core of my question 100%  -- Thank you!!!

Hi Mr_Fulano,

I know that you have already accepted an answer but I thought I would throw my 2c in to the discussion.

Hopefully by now, you have realised that there is nothing "magic" about DD, and so that your "DD image" is just a byte-for-byte copy of the source data, whether that is a file (as you experimented with above) or if it is a complete disk image (as you are looking to read/view). So, now if you refer back to one of your older questions, where the experts were talking about filesystem types (eg. FAT, FAT32, NTFS, etc), you might understand better what they were trying to convey to you. That is that the DD image that you are referring to, is a byte-for-byte copy of the source NTFS filesystem or perhaps the source was a FAT32 filesystem, etc, etc. So, say that you have one DD image of a FAT32 filesystem and one DD image of a NTFS filesystem, and both those filesystems contained exactly the same files/folders as each other. The bytes in the DD images would still be VASTLY different, because of those differences in filesystem types.

So, to do what you want, you would need to read the bytes from your DD image and then "interpret" them correctly for the filesystem that the image was originally created from. Does that make more sense now? Hopefully this can better focus you on the questions that you might now need to ask to get your application to where you want it. That being less about what DD is doing and more around "what libraries are available for reading/interpreting filesystems X, Y and Z" (whatever ones you would look to support in your app). Assuming that you wouldn't be looking to reinvent the wheel, writing your own filesystem handling code from scratch!

Hope that helps somewhat, and feel free to reply here or to start off with a new question!

Cheers
Phil

Hello Phil, first and foremost, thank you for adding your "2 cents", which are more like $1,000....LOL.  Yes, I can see now where they were coming from, but unfortunately, none of the folks that provided that input back then were as articulate or detailed as you and Noci. Both of you have given me a lot to think about and a lot to consider and reconsider.

I never cast any answers aside as trivial. I believe you can learn from anyone, as long as they're not flippant like some of the remarks I got, which seemed like arm-chair quarterbacking without providing much depth to their statements...as you and Noci did.

I welcome your thoughts and I welcome you contributions. I'm not one to think I'm always right and I have the best way to approach a situation. I welcome suggestions, so if you have one, please share. I'm going to post a new question here titled: What is the best approach to programming an application to read a filesystem imaged using DD?  Perhaps you would like to share your thoughts - I know I would appreciate your input.

Thank you Sir for your comments. Look forward to hearing from you again.  

Best is to use a filesystem DRIVER, on a read only image...

ie: have a file   make it read only,, on linux   tie it to a loop block devices (readonly mode),
then mount -r the filesystem and check what is there......

If you are looking for data in the "unused areas" of a filesystem (the bits that can be overwritten at any time), or deleted files you need tools that look for remnants, debris from a filesystem or left over bits in old fileheaders.   OS's are lazy..  to delete a file all blocks used are marked free in the bitmap table and a BIT is set in the header the file header is "deleted", available for use...  the allocation data may still hold valid data (allowing undelete's for partial data etc.).
Data blocks are not cleared (most of the time, so the content may still be there).. 

deleted data - which is why you can't just delete files and folders on a hard disc and think it is then safe to dispose off.

Saying "The DD command is simply a glorified copy command" is very simplistic, and likely incorrect, given specific context of what's being done.

Copy commands copy logical blocks, while dd copies bitwise data.

You can end up destroying entire disks using dd, as bitwise data != file block data.

Better to use a normal copy utility, rather than dd, so you can never destroy your file system.

@David... dd is just a plain copy command   albeit it can handle arbitrary blocks (size) of data.
And it  can manipulate them on the go.  So you can byte translate them (ebcdeic <-> ascii)   you can chop the start/tail of a block, add head or tail to a block.
resize blocks on the go...    And it is often MORE efficient as  you can tell it to use a 1GB block to better bulk read / write for devices with huge buffers on disk,
or 1MB blocks because it is better fitting the Row Clearing size of flash devices.
Special is that cp doesn't allow you to choose a blocksize, where dd does allow you to do it. 

DD and CP should be equal in their copying abilities (as would be backup/tar/cpio etc.)  because otherswise data would get mangled...

ddrescue is special as it keeps track of IO errors and retries info als after resetting a device etc. so it can attempt to read as much data from a device as is possible using "normal", ddrescue cannotmodify blocked data.

Any copy operation can destroy data. (It does in fact allways overwrite previous data on the used storage).