You are browsing as a guest. Sign up (or log in) to start making projects!

6h 48m 43s logged

C Navigation System — Devlog #3: Windows Compatibility

After submitting the project for certification I ran into a problem that hadn’t even crossed my mind: the program simply didn’t run on Windows. I got feedback from a reviewer with a video of the error, and the message was clear, “clear is not recognized as an internal or external command.”

The explanation is simple once you get it. I had written and tested the code only on my Linux environment, and used system("clear") to clear the screen between each frame of the animation. Turns out clear is a command that exists on Linux and Mac, but on Windows the console uses cls. I’d never thought about this because I’d never tested outside my own system.

The fix was to use a preprocessor directive, #ifdef _WIN32, which lets the compiler choose which code to include depending on the operating system the program is being compiled on. This way the clear() function decides on its own whether to call system("cls") or system("clear"), without me having to maintain two separate versions of the file.

void clear() {
#ifdef _WIN32
    system("cls");
#else
    system("clear");
#endif
}

While reviewing the code I realized there was a second problem waiting to happen. I was using usleep() to control the timing between animation frames, and that function is also exclusive to Unix-like systems, it doesn’t exist on Windows. It probably wouldn’t have thrown an error right there in the video, but it would have further down the line as soon as the robot started moving. I solved it the same way, creating my own esperar_ms() function that uses Sleep() on Windows (which works in milliseconds) and usleep() on Linux (which works in microseconds), and swapped out all the old calls for this new function.

void esperar_ms(int ms) {
#ifdef _WIN32
    Sleep(ms);
#else
    usleep(ms * 1000);
#endif
}

The annoying part wasn’t so much writing the fix, it was realizing I had to test both versions before requesting re-certification again. I compiled it again on Linux to make sure I hadn’t broken anything, and the program still worked fine, I just got some unused variable warnings that were already there before and have no impact on execution.

The lesson I’m taking from this is that testing only on your own operating system gives a false sense that the program “is ready.” Only an external test or review catches these things, because in my own environment I would never have seen this error myself.

0
1

Comments 0

No comments yet. Be the first!