Antti wrote:
JAAman wrote:
VC++ was specifically designed for OSdev
Does the license even allow this for other users? I could easily change my build scripts to use cl.exe as a compiler (for kernel, tools are normal programs), but I'm quite sure that this would violate the terms of usage. If not forbidden outright, it would be morally/ethically questionable. It is clear that the intent for the cl.exe is to produce executables that run on MS platforms.
yes, this is completely allowed by the license agreement (they changed it recently, and I carefully examined it to be sure this is allowed because some people have falsely claimed that it wasn't allowed)
there are a few components of VS that are not allowed for use for anything not targeting windows (under the new license they have a separate license that covers them) -- but these are all windows-specific advanced debug tools and a few libraries (MFC and ATL, iirc, don't remember if this included the windows header files also? but I actually don't think it did but might include the new library that replaced them) and would be mostly pointless for anything not targeting windows anyway, older versions of the license were not as clear, and included everything in a single license which mentioned "portions" which were not allowed to use for anything not targeting windows
CL does not have a separate license, and falls under the main license... which comes specifically configured for android and ios development! (if you check the android and IOS options in the installer) and thus clearly not intended for windows only development (though android and IOS targeting use a different compiler (clang, iirc), the CL license is the same as the VS license)
let me be very clear here: while the current license is much more clear, it has never been a violation of the license to OSdev using VS/VC++/MASM
if you use CL, however, remember that it isn't incredibly buggy, and therefore you should not ever use /Wall /Werror... as this will not be capable of compiling anything non-trivial (or perhaps even trivial code)
Quote:
Where are these build targets documented? Microsoft's Visual Studio documentation makes no mention of them.
just looked it up, and my memory was a little off... the setting I was referring to is called "subsystem" (in Linker->System, or on the commandline: "/SUBSYSTEM:<specify target subsystem>) and it is documented (though the current options don't provide the "freestanding" option I thought I remembered... that is what time does to memory) but it isn't necessary for OSdev at all... instead the option that you need (I correctly remembered that only 1 option was needed...) is to specify the entry point (in Linker->Advanced, or on the commandline "/ENTRY:<function name>") of course even this is only necessary if you don't want to use the default entrypoint function name
while no option is strictly necessary, there are only 3 options that are relevant for OSdev (that aren't directly related to regular application development)
1) disable exceptions (C++ ->code generation->Enable C++ Exceptions -- on the commandline this is: nothing specified) -- the code shouldn't produce any exception code if you don't use exceptions in your code, therefore this should be irrelevant (it would only affect the CRT code, which shouldn't exist in your OS kernel or bootloader), in fact I'm not convinced this actually has any effect at all (I think, but I don't know, if exceptions exist in the code being compiled, it will default to something rather than failing with an error -- the option exists to allow you to choose between different types of exception handling, not to disable exception handling)
2) disable standard libraries (Linker->Input->Ignore All Default Libraries -- on the commandline this is /NODEFAULTLIB) again, this isn't necessary but will prevent the compiler from searching the standard libraries for code you call but fail to provide (I consider this the OSdev equivalent to using /Werror -- turns what could be incorrect code generation into a hard error)
3) entrypoint (Linker->Advanced->Entry Point -- on the commandline this is /ENTRY:<specify entry point function name>) this will allow you to specify the true entry point function name, overriding the default one provided by the CRT (necessary if you don't use the default function name)