There are 3 ways to do an end of line. The Unix way, the Mac way and the PC way. Unix/Linux use the linefeed character. Macs use(d?) the carriage return (No idea what OS X uses since it's basically a Unix). The PC for some retarded reason uses both linefeed and carriage return characters for end of line. This makes it key to open files in binary mode on a PC or you end up with screwed up data. Same thing using Copy from the command prompt.

Linux/Linefeed = 0x0D
Mac/Carriage return = 0x0A
PC/retarded = 0x0D 0x0A

Vi is pretty weak. I've purged it from my mind except the sequence to get out of it if accidentally invoke. But many text editors for programming will let you specify the EOL sequence just because of this problem when taking source to different machines.

Now, that said, your instructor is a total dipstick if he's using notepad. And a double dipstick if he didn't know what was going on. Since he's on a PC and an instructor I would assume he had and used at least some version of Visual C++ or Dev Studio gotten at some dirt cheap educational price. It's editor has no problem with text from other standards. And I would assume at some point the code has to actually compile.

There may be some freebie util out there on the web to do the conversion or a text editor for programming that will save it PC style on SourceForge. If not, it's pretty trivial to write one on the PC. I did one a couple of years ago for a similar problem. I'd post it but it's 700 lines. But you could make a fairly simple one for your purposes easy. Open file read it in. scan for 0x0D output the buffer to that point and then output 0x0A, Continue scanning buffer for EOLs and repeat to end of file.

One thing you should be very careful of is the line continuation char backslash \
Most often it is used in macros. The danger is in taking a PC text file using it to a system that uses only a single char for EOL. The backslash tells the compiler to ignore the next char. On a PC the LF CR is read as a single char and the EOL is ignored and your macro continues on the next line. With a Linux compiler that same file unmodified the compiler will ignore the single LF but not the CR so your macro will end without continuing on the next line. And well comedy ensues as you spend nights trying to figure out why your code is broken until you go into disassembly mode and see half of what the line of code should have done is missing.