OSDev.org

This has annoyed me for a while now. I personally don't think IDEs are OSDev-related enough to warrant being in the OSDev wiki. It's about OSDev, not programming in general. Until I deleted them way back, there were articles on Emacs and Vim as well. I mean, come on!

The only reason I can see for keeping these articles is a small amount of content related mostly to setting them up for OSDev. I think this should be packaged onto a single page, named IDEs or something similar.

I voted "No". There was no option like "Just setting IDEs up for OSDev should be covered". If that option would have been there I'd have choosen it.

Reason: I personally find it the most annoying part of IDEs to get it ready for work, especially for OS development. Sometimes I felt like "Okay, there are thousand switches, this will take me forever to setup; um, I'll use a simple text editor." If someone has a good insight how to setup an IDE for OS dev (and related, like using the standard GNU toolchain that isn't supported out of the box, or like configuring make as a build target), I think it would definitely be worth sharing it in the wiki.

--TS

Well, we do have an article on creating a cross compiler - so if it's not just a list of IDEs, but rather some information on how to use different IDEs for kernel compiling / debugging, I would vote in favour of it. So, I share Hyperdrive's opinion.

No - prerequisite knowledge is previous coding experience, and by the time you take on an OS you should already have an IDE you know and love.

Yes and no. Yes you should know your IDE. No, OS development uses a certain set of features that you wouldn't normally have used. I mean, even the best of programmers might never have needed to change the compilation settings in visual studio or dev-c++ to the extent needed for OS development. (setting up msvc for osdev is non-trivial, setting up your crosscompiler to work outside of cygwin is also non-trivial)

Therefore, yes, the non-stub articles on IDEs should be kept.

Editors and stub-only pages however can be exited IMO. (that basically leaves the VS and Turbo C pages)

Combuster, again, sums up what I wanted to say nicely.

I beg to differ. Setting up any recent version of VisualStudio is fairly straightforward. Disable any msvcrt support (buffer check: no, basic runtime checks: default, runtime library: multithreaded DLL (no, you wont actually need it)), set some more options as you like (I use these: enable function-level linking: yes, enable string pooling: yes, calling convention: stdcall, use precompiled header: yes, treat wchar_t as builtin: yes, ignore standard include path: yes, detect 64-bit issues: yes, warning level: max, output directory: x64\$(ConfigurationName) or x86\$(ConfigurationName); linker: references:eliminate unreferenced data, enable comdat folding, target machine: x64 or x86 ) and you are ready to go.

Actually, there are two things needed for OS development: first is to disallow any linking to the msvcrt library, second is to either reuse the entry point expected by the linker (extern "C" int _DllMainCRTStartup(void* hModule, unsigned int ulReason, void* lpReserved) ), or instruct the linker to use a different entry point. However, I still voted 'No' as I think figuring out these options should be trivial to anyone seriously thinking about osdev.

Im going to have to agree with ru2aqare here. Nothing is "hard" about setting up any environment if you have experience with it and already know what to do. This may be why myself and ru2aqare (and others) find setting up msvc to work in kernel land easy. It all comes down to knowing your toolchain and environment well.

Hmmmm. I think I'm going to agree with combuster. I've been working with MSVC for over 10 years, and I have never messed around with some of the options that ru2aqare suggests. I wouldn't know to do some of that. It would take me several frustrating days of messing around to get it to work -- that I wouldn't want to waste that way. And we get sooooooo many newbies doing this stuff that I'd rather have them find some basic instruction on the wiki, rather than have them ask questions about it on the forums.

(But isn't using MSVC for kernel dev against the licence agreement anyway? )

It took me only a couple of hours to work out the options required. This was way back when I was using VS2oo3. Since then, I have been copying that 'template' project file (with all the options set to the 'good' values), sometimes refining it. I don't use these options for osdev only - when I want a pure Win32 application, that doesn't contain any msvcrt fluff, these options are what I need. If anyone wants to wikify the options, go ahead...



I have no idea. Some say that the 'masm' assembler (that comes with VS) can't be used for osdev, citing the license of the 'masm32' package (which also happens to contain masm, but is not official, and does not come with the VS setup).

And even if that would be the case, you can always configure VS to use a different compiler - say ICC or GCC. Although I have never tried that, so I can't say how difficult it gets.

No, it is fine to use. The inline assembler is not masm32. And, if you need to use an external assembler, you can configure it to use another assembler instead of masm32. (I personally use nasm)

I don't personally know why a "template" should be required...the options needed in MSVC for kernel land are not that hard...and only takes a few minutes..

Then again, it still all comes down to knowing your environment well...Those that are used to using MSVC and know it well may find it easy to set up. Similarly, those who are more comfortable with GCC and LD may find GCC and LD easier to set up then MSVC and other environments.

Sometimes I'm lazy, and I can't be bothered to change the options. Copying a 'known good' project file only takes a second...

plus one to combuster's ideas and bewing's insights.

I've just sat staring at Xcode 3.1 for the past 4 hours (now roughly 2am right now), and having never used it for anything but Mac OS X and iPhone development, a lot of the things i see have never been clicked. i had the idea a few months back to make an Xcode project for my OS but i could never get it to work, mainly because of the abundance of templates.

so far, I've just been playing with the 2 usable templates, and have managed to get a makefile based project off the ground. it was alot easier than it looked, but it is quite difficult if you just wanna get it setup without too much fiddling. If you want to add Xcode to the list (I know of a few devers around that may like to give it a look), i would be more than happy to write up a How-to for it.

I only have 1 lesson in college tomorrow(only 50 minutes of the day will disappear), so i will be researching(well... poking around) into a more reasonable build mechanism in Xcode (automatic build sequence, to get rid of having to update makefile all the time.)

cheers,
James.

P.S if anyone wants to know how i have set-up my Xcode project, just pm me and I'll be happy to divulge my... "expertise"...

P.P.S I'm planning on suggesting Xcode for addition to the IDE category, but only upon getting a more complete guide to setting up Xcode for OSdev. makefile based project is sufficient (is basicly just combining editor and command line, so makefile needs manual attention) but i think an automated system is more effective.

I know this topic's been up for a while, but seeing as it's been re-awakened anyway, I'll post my views

I generally go against the general consensus in the poll above and have voted for IDE articles to be kept. I think that the IDE is an important part of the toolchain. Someone entering osdev from applications programming may not have used many of the relevant features of their IDE.

Having said this, I think than any IDE articles should read like crib sheets for OS Dev - I'm not suggesting that they should tell you how to use an IDE from scratch.

Cheers,
Adam