• Advertisement
Sign in to follow this  
  • entries
    70
  • comments
    185
  • views
    53211

ReComputing in a Windows World

Sign in to follow this  

140 views

Yesterday I introduced/announced my Project ReComputing initiative. I left off asking the question of how I would make it relevant in a 95% Windows World.

The Microsoft Windows NT operating system is incredible. Windows gets a lot of knocks because of its perceived insecurities, and a lot of those are warranted, but those are mostly user space flaws. The NT kernel (considered as an aggregate for now) is actually quite secure; the problem lies in the fact that user space applications and even subsystems may not take advantage of the security functionality.

Anyway, the real marvel is the way the operating system is designed. The NT Kernel sits above the hardware abstraction layer (HAL), with the NT Executive wrapping that and exposing an interface to one or more subsystems, one of which is Win32. The implication of this is the fact that additional subsystems can be developed and installed at, essentially, supervisor level, interacting directly with the NT Executive and with the Win32 subsystem (all subsystems require Win32 to some extent). This is how Citrix was implemented, which has since been acquired by Microsoft and morphed into Services for Unix, a (fairly) complete UNIX environment for Windows NT-based operating systems.

In case this hasn't seeped in, Win32 is not an exclusive option on Windows NT-based OSes.

My intention is to implement a ReComputing subsystem for the NT Executive, and then a ReComputing shell environment to replace Explorer and its cohorts. I'm still in the early stages of learning in depth how the NT Kernel works (I'm reading a book titled Operating Systems Projects Using Windows NT by Gary Nutt, which is really a lab manual containing a series of exercises focusing on designing and implementing various functionality using the kernel), but I'll probably dispense with GDI and other such familiar user space libraries, pretty much requiring only NTOSKRNL.EXE, HAL.DLL, and other such low-level components.

Windows will be the primary target for ReComputing, allowing the largest population of users to simply install it an experience the difference. I'll try to find a way to ensure that existing Windows applications can continue to run, probably by launching GDI32.DLL and so forth within a sandboxed environment. I'll also build a Knoppix-like bootable CD-ROM demo version of ReComputing, allowing people to try it out and experiment without making any significant changes to their installations.

The intention is then to port ReComputing to other platforms such as Mac OS, Linux and BSD. Hopefully by that time the source would have been opened, so others will handle that aspect.

I'm currently looking for copies of Inside Windows NT and Inside Windows 2000 by David Solomon (highly recommended by Prof. Nutt), and will be spending a fair amount of time at sysinternals.com as well.



In other news...

My laptop's warranty information is nowhere to be found. I'm inclined to just write the thing off (ouch!) and focus on getting a new machine. There's a screwdriver shop not too far away from me, so I want to stop by and see what they've got, and see if they'd be willing to lease a machine. Wish me luck.

I also grabbed a copy of Foley, Weiner et al from the library yesterday (I love college libraries; access to tons of books without having to buy any). For the uninitiated, that would be Computer Graphics: Principles and Practice. It's for refreshing my graphics knowledge, providing a relatively familiar escape from the internals of Windows NT when stuff gets hairy, and for helping me design and implement SSR.

I'm also in the market for a 1963 to 1976 two-door muscle-ish car in "runs but needs love" condition, preferrably $700 or less in the NYC/Long Island area. All stock, nothing fancy. Seats at least four adults. Solid body preferrable; interior not that important as I'll rip it all out anyway. Plan to do some custom detailing and throw in some custom electronics (mini-ITX-based infotainment system). If you know of anything - or any tips on good places to look - leave a comment or drop a line.
Sign in to follow this  


4 Comments


Recommended Comments

This ReComputing project you're beginning work on sounds extremely interesting, it would be nice if some of the ideas from it caught on. Though I believe the WinFS filesystem in Longhorn is similar in some ways to the file system you described in the previous journal post (mainly that there is no directory hirearchy as such and things are identified via metadata).

How exactly do you go about drawing stuff without the use of GDI? Can you just directly call the HAL to perform low level graphics operations?

Share this comment


Link to comment
Quote:
Original post by Monder
This ReComputing project you're beginning work on sounds extremely interesting, it would be nice if some of the ideas from it caught on. Though I believe the WinFS filesystem in Longhorn is similar in some ways to the file system you described in the previous journal post (mainly that there is no directory hirearchy as such and things are identified via metadata).
There is an amount of similarity with WinFS, but very little in the way of specific information is available. You usually get a blurb to the effect "building on top of NTFS and Yukon - the next generation of SQL Server - to provide relational database-like access to files via metadata properties."

One thing I know from experience (see TickerWatcg, for example) is that delivered software often falls short of projected functionality, so I'm not going to hold my breath for WinFS until I get to play with a beta.

Quote:
How exactly do you go about drawing stuff without the use of GDI? Can you just directly call the HAL to perform low level graphics operations?
GDI itself is implemented in terms of accessing generic functionality of the video device driver. Device drivers in the NT kernel are quite interesting, as they are essentially stackable (so you can, for instance, have a Network File I/O driver intercept messages bound for files located on a remote resource and respond appropriately - handle synchronization, PUT/GET operations, etc).

Device drivers are part of the I/O Manager architecture, which handles virtually all device reading and writing in a fundamentally generic way. In essence, I'd write my own equivalent of GDI to provide basic drawing functionality as needed.

Hope that answers your question.

Share this comment


Link to comment
Just thought I'd add in that the book you're using is most excellent for Windows OS level programming. It should cover everything you need and/or show you the right direction.

Share this comment


Link to comment
Quote:
Original post by KHawk
Just thought I'd add in that the book you're using is most excellent for Windows OS level programming. It should cover everything you need and/or show you the right direction.

Thanks!

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement