I realized that some users might try to turn these routines into objects so that they can be accessed as static library (.obj, .o). So I transferred all local data declared via data directives (db, dq, dw etc) back to stack. Safer this way but probably less convenient for beginners since I don't put enough documentation for the stack partitioning.

This latest update is compiled with FASM 1.71.40 without any problem (October 21st, 2015).

My next plan is to complete the internal documentations and line comments to make it even more readable and useful. But it's not going to be completed any time soon (probably will never be completed anyway). Time is against me when year end is approaching. But up to this point, I am throwing everything in.

These latest additions should help beginners to understand more about memory (usage, addresses) and how their instructions are encoded (instruction size, placement and encoding).

I intend to turn these library to DLL and SO form instead so that it can run cross assemblers / compilers and can promote better information hiding. But I am having second thoughts about it because it will no longer be open source.

On the other hand, exposing codes that should be hidden may not be appropriate in formal education environment. I don't know. Only time will tell. But for sure I am not releasing both the source and binary format.

See you all again next year. Year-end auditing work is stacking up mountain high. LOL

Debuggers are not counter productive. The word even describes what they do. They help you identify bugs. If you debug your code thoroughly you won't have to go back and forth trying to figure out why nothing is working.

Debuggers are not counter productive. The word even describes what they do. They help you identify bugs. If you debug your code thoroughly you won't have to go back and forth trying to figure out why nothing is working.

That's what's this library is all about. Beginners can code & debug at the same time so that they don't waste their time going back and forth the debugger. That is to say they can prevent bug from occurring in the first place.

I don't know about you but I'm not relying on C/C++ programmers to write a debugger so that I can check what's wrong with my low-level assembly code. See the irony here? Assembly programmer will have to rely on C programmers / programs to see what's going down with their own assembly code???? LOL

I don't know about you but I'm not relying on C/C++ programmers to write a debugger so that I can check what's wrong with my low-level assembly code. See the irony here? Assembly programmer will have to rely on C programmers / programs to see what's going down with their own assembly code???? LOL

But you are relying on a Linux kernel which is written by C programmers

randall I am referring to people's obsession with debugger, not with kernel. Even FASM rely in some way on windows library/headers to make it work on Windows. You are missing the point. Besides, syscall is the lowest I can go for this little 'app' without breaking anything on the user's side or on my side. Btw, I do have the 16-bit version of this library using the BIOS interrupt services. No C.

I have nothing against debuggers or C programs. My only issue is that assembly programmers are pushing the idea of 'must-have debugger or you die'. That really is burdensome to assembly beginners when in reality the use of debugger can be completely avoided by using library like this, by assembly programmers, for assembly beginners. More time can be saved because beginners can code and debug at the same time.

But I have to admit that debugger is inevitable when it comes to advance things like windows programming. But this library involves no such headers. Just simple command-line assembly library.

A debugger may be easy for an individual PCs/users, but for large multi-platform learning institutions with hundreds of non-standard PCs, a debugger will be too luxurious to implement. So the safest, easiest and cheapest alternative is a library like this one

People will do what they find the most comfortable at the time. Sometimes I use a debugger, sometimes I just print out debugging information. I do whatever is easiest and most prudent to fixing the problem.

I don't agree that printf is always better than debugger, or that a debugger is always better than printf. Each has its place. And learning to recognise when to use each one is a very important skill.

I use both s/printf and debuggers - homemade disassemblers, FASM "display" and PE Browse Pro for .EXEs - whatever is the fastest, easiest and/or most convenient.

After you finish a LL library in ASM, you may decide later to create a separate higher level DLL in C or FASM macros that encapsulates all of this with Windows UI and controls. Iczelion's Windows ASM Tutorials (MASM is easy to translate).

I changed the source to a new name CORE64, reflecting my intention to turn these library into SO and DLL soon.

I altered "memview" so that the Address column is placed on the right. The content is now read from left-to-right. Left=MSB and Right=LSB. For example, an attempt to probe the memory dump backward to read the ELF64 header;

I am not sure if this new arrangement will be the best, but I am more comfortable reading the content from left-to-right, from MSB to LSB. The address represents the offset of the byte nearest to it. For example address 0x400058 contains 78h, 0x400059 contains 0, 0x40005a contains 40h and so on.

As for "encoder" routine, I am not very sure how to properly implement it as I don't have good knowledge on encoding, plus there's no way we can be fully sure of what those opcodes really represent. For example 48h is either DEC or it could be a REX prefix. DON'T ASK ME. I DON'T KNOW. I just print them out for you xD

I use both s/printf and debuggers - homemade disassemblers, FASM "display" and PE Browse Pro for .EXEs - whatever is the fastest, easiest and/or most convenient.

After you finish a LL library in ASM, you may decide later to create a separate higher level DLL in C or FASM macros that encapsulates all of this with Windows UI and controls. Iczelion's Windows ASM Tutorials (MASM is easy to translate).

I don't know how many years to go so I can finally catch up with you. By looking or should I say 'staring' at your codes, I probably never will. You are way too advance my friend.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum