OSDev.org

Same experience here with MSDN. I always find a ton of information on the things I'm looking at and it's extremely clear in what header something is and when that call was introduced etc.. I've recently been doing a lot of OS X development and I'm much less impressed with that documentation thus far....

Heh. I'd like to see the two of you try to find info in my MSDN CDs about "how to change the printer paper tray". Or to permanently change to Landscape format, from inside an app.

In my copy, the search function is beyond pitiful, the keywords stink (and are mostly missing), and the hyperlinking is sub-minimal.

I only browse MSDN online, and I use the common dialog control for printers

bewing wrote:Heh. I'd like to see the two of you try to find info in my MSDN CDs about "how to change the printer paper tray". Or to permanently change to Landscape format, from inside an app.

http://msdn.microsoft.com/en-us/library/ms535488.aspx
(the structures you need are explained in articles linking from that page)

and some example code thanks to the power of google:

http://www.codeproject.com/KB/printing/ ... ation.aspx

However, it's probably a *bad* idea to change the printer's default paper tray or format programatically in your program unless your a sys admin at a company maybe (but even then there's better ways through policies I'd imagine) since most users want to have control over such matters.

bewing wrote:In my copy, the search function is beyond pitiful, the keywords stink (and are mostly missing), and the hyperlinking is sub-minimal.

I haven't used the DVD version in probably 5 years. I only use the online one (http://msdn.microsoft.com/library) and searching on the API I want. Or use google it and almost always the top hit will be in the MSDN docs.

But the index isn't always that logical (although it has gotten better). The printing stuff for example is under Win32 and COM Development -> Graphics and Multimedia -> Windows GDI -> Printing and Print Spooler

And as an aside, the docs usually focus a lot on the specifics of each API, not always on how to combine them (like in the sample code above). So for that sort of thing I usually use google to find some sample code which sometimes is in MSDN and sometimes isn't.

HTH,

Thanks for trying, Rob -- but I coded this project 6 months ago.

And even that most recent info you got is misleading in several places. That is my point. To do both the things I suggested, the vital thing you need to do is to get a DEVMODE structure, and then create a new DC with it. The documentation never explains this. You did seem to notice that to get a code example, you had to search the web, and not MSDN. Yes, the web has very good search engines, and LOTS of info. MSDN does not. It does not explain that is it better to use the Document_Properties function, rather than the Get_Printer function. On older copies of MSDN it said to use a function called Get_Job -- which was stubbed and non-functional on every version of Windows that I ever found.

(And I'm pretty sure that code example you linked to will not work on Win'98 -- the JOB_INFO_2 structure will always contain a NULL pointer instead of a DEVMODE pointer, AFAIK. Another basically undocumented factoid.)

Win 98? What's that?

I get what you're saying. I think we might never have perfect documentation, but thus far I've had the best luck with MSDN (doing Win & OS X dev)....

I'm finding that out myself as well both professionally and personally. It's hard to write (thorough) documentation and even harder to write a good API and document all the requirements / use cases / border cases and what not.

lollynoob wrote:Hey.
I mean usability for programmers as well; usable in the sense that to make a little box on the screen I don't have to write a 200-line base of code (win32, I'm looking at you) before I actually start my own program; usable in the sense that if I want to make a game, I shouldn't have to use someone else's API to make it. If I, as a programmer, want to use the screen as an array of pixels, I should damn well be able to.

Now, DOS did this. A VGA screen mode was one "int 10h" away, the hardware was left open to be accessed by user programs, and (gasp) when programs screwed up, they could screw up a lot of things;

The reason DOS programmers could be allowed direct hardware access, and Windows programmers can't, is the fairly obvious one that DOS was a single tasking OS and Windows isn't. It would not exactly make sense to have two or three different programs trying to simultaneously manipulate the same area of the screen, or simultaneously trying to send data to LPT1. A central function of a multi tasking operating system is to act as a benevolent dictator, because otherwise chaos would most assuredly follow.

In any case, why are you a hobby OS developer except to have fun directly manipulating the hardware?

I think we don't even need an operating system. Why don't everybody start creating multi-boot compliant application . No more restriction, bloat and insecurity.

By the time you add multitasking support to GRUB, it starts to look like an operating system anyway. Indeed, it already looks a fair lot like a single tasking one!

Sure it is. You will need to reboot everytime you want to switch application.