How to read Windows MFT

[hutch--]

Having read JJ's last post, I know why I detest C++, endless clutter, unnecessary complexity and lousy performance.

[aw27]

Congrats, so you finally realised that shared access had nothing to do with the problem

No wonder, your default is actually shared access.
Should be a bug somewhere in your libs.   :idea:

M$ doesn't lile your code

I always use M$ and normally the latest version. Builds without warnings or errors.

[aw27]

Having read JJ's last post, I know why I detest C++, endless clutter, unnecessary complexity and lousy performance.

I am not talking about C++ with objects, straight C++ is as performant as C and in many cases outperforms no optimized ASM. I have proven that and am still waiting for a contradiction.

[hutch--]

Jose,

Forgive my humour here but I have heard this one many times.

performant as C and in many cases outperforms no optimized ASM

The simple answer is,

performant as [put any language you like here] and in many cases outperforms no optimized [put any language you like here]

:P

[aw27]

Forgive my humour here but I have heard this one many times.

Hutch,
This is small talk, actually with some sense of humour.
But I prefer this one for a good laugh:
Please translate this French sentence:
dans la cuisine=

[habran]

Hi aw27
nice proggy :t
It can be build as C or CPP
It builds instantly from the box with MSVS 2013 Community, however, it gives me:

Code Select Expand

Can't open MBR. Are you launching as Administrator? even though I run it as administrator
That doesn't mean tat it is something wrong with your proggy, it is probably my windows 8.1 fault

JJ, you need to set up your MSVS properly as it is obvious that it doesn't like you because it is aware that the filing is mutual

[jj2007]

JJ, you need to set up your MSVS properly as it is obvious that it doesn't like you because it is aware that the filing is mutual

My C or C++ stuff builds just fine with MS VC and GCC. Even José's code builds without errors with GCC if I add a "W":

CreateFile(L"\\\\.\\PhysicalDrive0", ....  //WRONG
CreateFileW(L"\\\\.\\PhysicalDrive0", .... //RIGHT

Which won't help for the M$ compiler, its linker complains about "error LNK2019: unresolved external symbol ___report_rangecheckfailure referenced in function "void __cdecl hexDump(void *,int)" (?hexDump@@YAXPAXH@Z)"

Having read JJ's last post, I know why I detest C++, endless clutter, unnecessary complexity and lousy performance.

But it keeps Google happy: Countless C/C++ coders searching the internet in a desperate attempt to understand their endless error messages. Trial and error as the ultimate programming paradigm. Even ML64 is more compatible and consistent than the average C++ compiler

[habran]

aw27, I'd suggest you to rewrite it in asm 32 and 64 bit and post it here
we can include it in Sample folder for UASM

[habran]

JJ, you just said it wouldn't build and I have done it instantly, so, what conclusion we can draw from that?

I am not trying to make you stupid or something, I appreciate you and your programming skills as well as your personality :t
However, if your M$ refuses to build such a simple proggy than I have to come to conclusion that something is wrong with it.
Wouldn't you agree with that logic?

[aw27]

That doesn't mean tat it is something wrong with your proggy, it is probably my windows 8.1 fault

Hi habran!
I tested in Windows 8.1 and it works, a possible cause might be security software.

I'd suggest you to rewrite it in asm 32 and 64 bit and post it here

All right, I will put on the agenda. :t

[jj2007]

However, if your M$ refuses to build such a simple proggy than I have to come to conclusion that something is wrong with it.
Wouldn't you agree with that logic?

Absolutely :t

Btw José's code works, when compiled with GCC and run as admin, see attachment. A bit bloated at 29k but ok, let's be generous

[aw27]

CreateFileW(L"\\\\.\\PhysicalDrive0", .... //RIGHT

JJ, the default for M$ in this century is Use Unicode Character Set. But M$ is flexible and will let you use Multibytes (select it in Project Properties), in which case you need to remove the L", which means (guess what?)

[jj2007]

JJ, the default for M$ in this century is Use Unicode Character Set.

Is it? My M$ C compiler is version 19.00.24215.1, 21st century. Besides, GCC uses another default. Aren't C compiler supposed to be "compatible", whatever that means...?

[habran]

aw27,
I have no idea what is wrong with my system, there is quite a few issues with it, I was not even able to install MSVS 2017 because of some administrator's bull**it, however, other people had the same problem
However, I am happy for now with MSVS 2013 Community :t

[jj2007]

I have no idea what is wrong with my system

OMG, your M$ is also rotten? It seems the World is full of rotten M$ systems and compilers

(hint: Masm32 works out of the box on all Windows versions since the beginning of the 21st Century ;))