atrodo.org News Vote Rant Projects		atrodo.org dwin draak atrodo E-mail
	DWin RFC Introduction In the following documentation I will be describing and introducing the technology new to DWin, some very exciting offerings being developed here at The Original Atrodo(s) Company. These technologies describe two things: DWin the GUI and DWin the environment. Ultimately DWin has a two fold purpose. The first is to create a useful Graphic User Interface that will be intuitive not only to users, but also to programmers, created from scratch with the programmer in mind. The GUI platform will be portable, allowing a write once, compile anywhere philosophy for the programs developed for DWin. The second purpose is to develop a programming environment that is easy for programmers to pick up, but offers a powerful system once you are acquainted with it. This environment, to the greatest extent, requires it's own operating system. Indeed, the environment is meant to be an operating system replacement, but that does not stop users of a cross-platform DWin from realizing some of the power behind DWin. Because of this duality of DWin, we will define two terms when talking about DWin: DWG and DWE, the DWin GUI and the DWin environment. These are very descriptive names used for this paper. At a later point, these names maybe changed to a codename, but for the remainder of this paper, DWG will refer to the GUI while DWE will refer to the environment. It would aid to define what is in each of these terms. DWG is the framework that allows a programmer to create graphical interfaces inside of DWE. This means that a programmer does not need to deal with DWE if he works with DWG, but DWG does require a DWE to run. DWE introduces the image used throughout DWG, which is the basis for the drawing aspect of DWG. This drawing has the responsibility of actually drawing the graphics. Looking at the current DWin infrastructure, everything categorized in Gfx is part of the DWE, but the image class is used by DWG to draw the images. The reason that Gfx is not a part of the DWG is because of abstraction that takes place. DWE sits on top of the hardware or operating system, creating an environment for the programmer and DWG to sit on top of that is the same across platforms. If a port takes place, the only changed code should rest inside of DWE, keeping the visible API the same. This aids in the write once, compile anywhere goal of DWin. The DWE is not just a hardware/operating system abstraction, but an entire framework to allow programmers the ability to write code quickly and simplifies code reuse. DWE is a set of APIs that allows a programmer a standard, easy way to interact with the user and the system. It hides inconsistencies of different platforms while still making available characteristics of that system that are useful to the programmer. DWE does not need DWG, it is independent of anything higher then itself. In the following sections, we will describe the newest technologies to come out of the TOASC labs: TIO, registry, SAP, DTK, install.
				~
Note: This is an archived website. I built this between 2000 and 2004 and in some small way I feel that it has defined how I view my online presence. Although it's been years since I've updated, I have decided to keep it in its original glory and preserve it instead of replacing it with a blank page. Enjoy this glimpse into my younger self.