Thread: errr, is my code "good" ?

ZipCheck doesn't do anything - in particular, it doesn't return pass/fail back to the caller.

FileCopy is randomly indented, which seems to be caused by using spaces and tabs to indent with.
Nearly every editor can change the tab width, but the only way to be sure your code stays looking nice is to use spaces.

These two lines do not need the {} and the indentation, which makes them seem part of a while statement.
fclose ( out );
printf("\nCopied: %s\n", Display);

A more consistent function naming style would help - you have at least 3 styles of caps/underscores
void full_screen(void);
void clrscr(void);
void PcGames(void);

install.h
> int SetColor( Color );
This prototype is inconsistent with the rest, which also have a name for the parameter, not just a type

Also, including header files inside header files can be bad. You've traded short-term easy typing with a long term maintenance problem.

The only header file I would include in install.h would be the header file which contained the declaration of the Color type (as used by SetColor).

It hides dependencies. Not only does this make it difficult to figure out whether 'a' depends on 'b', it also makes it easy to generate needless dependencies by accident. It's simply way too easy to put something in the wrong place and have it compile.

It increases compile times - everything includes everything.

Personally, I would make each .c file have its own .h file. I know its cumbersome to include half a dozen (or more) .h files at the start of each .c file, but you'll know where everything is, and how and where to put new stuff.

In your case, only the main function will include everything. Each component source file will only include what is necessary to make it compile.

It also forces you to think a bit more about how the code is structured, and to keep thinking about it as the program develops.

As far as the placement of functions inside files goes, it seems OK to me