Normally you run a FreeRTOS application in a stand-alone environment - ie, the system boots directly into your application rather then being loaded by an OS (there may be an intermediate bootloader in some cases).
There is no concept of a "console" in FreeRTOS itself; your application must implement support for stdio or low-level I/O, typically via a UART and a terminal emulator running on the development host or by using semi-hosting via your debugger. This is a mater of porting your standard library rather than an issue for FreeRTOS. The standard library should have some sort fo pirting layer (known as "syscalls" in Newlib, or "Retargetting" in ARM/Keil toolchains for example).
FreeRTOS applications are built using cross-development tools rather than hosted development environments. That is the code is build on a development host using a cross-compiler then loaded to the target hardware and executed. There is a Win32 port of FreeRTOS that allows FreeRTOS applications to be built and executed on a Windows host, but the port is only a simulation, and does not provide hard-real-time scheduling. It is useful for development before hardware is available and testing and debugging using the more sophisticated debugging environment provided by Visual Studio that that typically available to embedded targets.
What you would normally do is select a hardware platform that FreeRTOS supports and meets your application needs, then select a toolchain that supports your hardware platform and is in turn supported by FreeRTOS. For most 32 bit platforms and the 8-bit AtmelAVR platform GNU gcc is near ubiquitous, and many proprietary compilers support GNU extensions for compatability. Unless you choose a particularly obscure toolchain/target combination, you are unlikely to not be able to either port to use an existing port of FreeRTOS.
