I believe Blindness should be on this list

Many years ago I remember using Visual Studio 6 (or a more recent version should be usable too, but I don't know), by using "customized build steps" or some similar feature, and you can do source level debugging. I don't remember finding another setup where you could do source level debugging.

GunnerInc, on 17 October 2011 - 06:17 PM, said:

First, thank you for this tutorials.

I wanted to add something just in case somebody wants to also write assembly code in Linux.

I was trying to do a mix of C++ and assembly in Linux, and then my program started ending unexpectedly and experiencing data corruption. I managed to isolate the problem to a few assembly function calls. Then I realized that all of the functions had something in common: the uninitialized data segment, ".data?"

All of the problems started when I decided to put all uninitialized data on the uninitialized data segment, and ended when I decided to put all of the data back on the initialized data segment and lose all uninitialized data segments, as it seems memory for the uninitialized data segments was not being allocated, or the appropriate pointers where not being updated by the Linux program loader, or some other problem. I was using NetBeans IDE, the GNU tool collection, and JWasm.

GunnerInc, on 17 October 2011 - 06:17 PM, said:

When I used to write Win32 assembly code, I preferred to instruct my IDE (Visual Studio 6 at that time) to use the following switches:

/c /coff /Cp /Cx /GZ /Zi

This way you only need to worry about including ".model flat" and let the IDE automatically set up everything else via command line switches.

The "/Zi" switch tells MASM to include debug information, even in release mode, but it's OK, as the linker will remove all debug information when linking in release mode, so you can use the same configuration for all ".asm" files in all modes and forget about it.

(By the way, IIRC, "includelib" did not seem to work in JWasm/Linux.)

Atli, on 17 October 2011 - 02:02 AM, said:

Thank you for calling these into my attention, and to tell you the truth, it's been a while since I did any *real* PHP programming.

Last thing I did was a forums website, in the interest of learning PHP, and I uses MD5. I intend to rewrite it, as I need to get my PHP skills up to date, and certainly will use SHA512!

Atli, on 17 October 2011 - 02:02 AM, said:

I should have known better, I remember reading something about it in the book "Code complete," a long time ago. I *really* need to re-read this book!

I would like to propose some changes:

Add a new boolean field to the user record, may be call it "PasswordUpdated", and set it to false for everybody.

Then, starting at the line #22:

// Check for our password
$shapass = hash("SHA512", $password, false);
if($result->password != $shapass){
    if($result->PasswordUpdated){
        // User's pass is incorrect.
        echo "Wrong username/password";
        exit();
        }
    else {
        $md5pass = md5($password);
        if($result->password != $md5pass){
            // User's pass is incorrect.
            echo "Wrong username/password";
            exit();
            }
        else {
            // User is correct, but his password has not been updated
            // Update his password
            // No fancy spanshy result checking, because they can still login even if the update fails.
            $mysqli->query("UPDATE users SET password='$shapass', PasswordUpdated=true WHERE username='$username'");
            }
        }
    }

// If we get here, user's pass has been updated and is correct with pass in database.
// Run whatever they needed to login for
echo "Thank you for logging in";

This way:

1- Except when doing the transition (or wrong passwords before the transition), no need to do more than one hash calculation.
2- No need to keep testing for the old password encoding schema if the user enters the wrong password (after the transition)
3- Only one "successfully logged in" code block