Displaying pixels (OS framework)

This thesis is on a new simplified concept on Windows
OS Display Management, based on my 1980's generic ideas
about early Windows programming methodologies:

I have developed for my thesis in 1989 a mini-windows
programming environment. I was fascinated with the
idea of windows systems, and built a graphics-based
windows GUI environment at the time with controls.

My research was independent at the time from Microsoft
Windows products. The main difference was that I was
not focusing on memory-saving architectures, but more on
how I envisioned the future. I assumed in my designs that
memory will be plenty and not to worry about. Basically
I came up with a lot simpler and 'friendlier' development
environment than the architecture of focusing on
'repainting' windows upon messages, I avoided a lot of
unnecessary coordinate calculations, complex message
maps and the use of complex macros. I tried to avoid
complex structures, preserve a simple command interface,
and have a set of simple functions available with as
little number of parameters as possible so I can
memorize the function names and program rapidly.

Although I used graphics modes such as Hercules Monochrome,
CGI, EGI, VGA and later Super-VGA, I kept a text-mode
element rastel for modeling control spacing (80 by 25
for basic resolution, I think 33 rows for VGA-mode) for
easy alignments of button widths, control spacings, to
avoid something that is often hard with Microsoft
Visual C++/MFC to align pixels. I have succeeded at
the time (late 80's, early 90's) to have a development
environment where I can type up GUI applications very
rapidly. What stopped my project in the market were
technological uncertainties as companies seeked standards
which were hard to synchronize into a development
product, especially compatibilities with Microsoft
Windows due to having different design approaches in
regards to my project. Visual C++ specialized on office
architectures, while I on simples windows and sub-windows
and simple programming commands.

After a decade and extensive working experience in the
client/server/telecom/database products world, I have
revised the idea of my old windows product, and its
potentials in 2006.

I would like to describe the importances of this
potential windows client/server/web/database/gaming/
busines development environment for Microsoft's
considerations.

What is so different about my old complete 'GLIB'
Windows Programming Environment? In two words:
memory management.

Certain simplifications. A window would be held in
memory, and write to the window's memory once, and not
having to worry about repainting, only upon the
programmer's decision to do so. Confusing?

Windows can be managed in memory and repainted
internally and automatically. Such a feature carries
huge programming benefits. In the early 90's memory
was expensive. Repainting windows was a memory-efficient
design. Having 20, 30 open windows and storing all
memory for pixel information today is not so resource
expensive and that is why I am writing about this
windows design. (see details below)

I will continue describing the highlights of my
old Windows OS by showing how complex features and
mnessage maps can be eliminated (its about time to
move on from memory efficient models toward programming-
oriented models?):

Simplicity: For example in my old design I had one
getkey() function to receive all messages with
extended message features for handling mouse and
windows commands. A simple case handling and routing
to functions rather a macro-defined message system.
All in one place and in front of the eye. A window
with a getkey() loop. The default message to a
window is a key pressed on the keyboard or a mouse
click, a window resizing instruction or messages
from buttons instructing to, say, close the window
and asking for the subsequent use of the CloseWindow
feature exiting the window's GetKey() loop.

The classic underlieing windows architecture described
here is based on internal management of pixels in a
window as if they were a screen of their own, which
is a window screen by default, a sub-screen, a
sub-monitor inside a larger screen/monitor.

Observe a simple program in this basic windows
development environment:

#include gwin.h

void WinMain( void )
{
WINDOW win = OpenWindow( 40, 10, "Sample window" );
// Opens Sample window dialog of 40 default characters wide
// and 20 default row heights" );
// Space added for 10 default text rows under Title Bar

win.AddBottomCenteredButton( "OK", MSG_CLOSE_WINDOW );
// Button displayed in horizontal center of 9th and 10th row

win.WriteCenteredText( 5, "Hello World!" );
// Y position = 5th row

while ( win.GetKey() != MSG_CLOSE_WINDOW )
;

win.CloseWindow();
// closes active window
}


The basic idea seen with the simple code above, is that
the development environment starts from somewhere basic,
and moves to more complex features. Note, there is no
need to repaint a window in the code above or add
additional message-handler functions, a window is
created and exists with its own pixel-memory space
and works on its own naturally, maintaining what's
been written in there until its closed. The window is
to be thought of as a display memory space. No complex
structures and maintenance are needed once something
is written into the window, but the use of simple
graphics function calls (and parameters) to write and
erase contents from the window. A printer would be
a window as well, and not a device context. OpenPrinter...
Draw... Print... ClosePrinter.

I would be interested in building up an OS development
environment based on this core windows programming
languege environment where a programmer uses functions
which write (directly would be most optimal) into the
window's memory, and a background interface takes care
of updating the screen efficiently based on the
pixel-information held in the memory for each window.
Of course one would arrive to the need of using repaint
features when a window is resized, but that is not so
Windows OS driven any more here but a programmer-specific
task. The memory-approach to windows vs. Microsoft's
repaint-message driven approach is very feasable
for implementation.

Memory is not as expensive today and plenty of memory
should exist for holding the contents of each window
pixel by pixel in memory. This windows memory-management
idea is based on a simple memory mapping system that
correlates screen memory with screen outputs intelligently.

This approach creates very beneficial programming aspects
in the educational world for learning Windows programming
and its basic concepts with ease, allowing overall easy
learning and Windows programming from the basic windows
methodologies and concepts levels, particularly much
briefer code and less need for maintenances... managing
a window as a memory screen of its own offering a much
simpler development environment. Basically this involves
taking a few features from Microsoft Windows and
automating them.

I would be happy to consult this concept with Microsoft
further. I can offer an easy design layout of such a
GUI system model, which lays in the core of the Windows
operating system. Such a change would have to be backwards
compatible with existing programs but offer a new set
of Windows programming tools and commands for developers.
Can the basics of Windows be preserved and returned
to writing to display memories as individual non-Microsoft
Windows applications used to do so? Can the powerful two
worlds reunite as a graphics standard that both graphics
card and display manufacturers, Microsoft and programmers
respect and adore? Perhaps saving memory resources
approach is not the most important in 2006 when memory
capacities in computers double for the money spent every
year or so. Perhaps some aspects can be simplified, or
at least in the research lab for now.

I believe I revised an old and worthy dream for a Windows
OS Model, one that brings Display/monitor features close,
features like programming and gaming, a feasable but not
most efficient solution today, but once accepted as
standard other industries could join in improving its
graphics control standards. The simple idea that each
window should have its memory space correlated with
displaying the contents of the window on screen, a
window which is like a screen of its own, a sub-screen,
and the Windows OS which is responsible for displaying
the windows based on their pixel-memory information and
not based on what needs to be repainted when a window
layout changes. There is a definite plus for programmers,
offers a briefer, better managed source code and easier
approach, learning process and code management to the
overall fundamentals of Windows programming.

What becomes most apparent is how one programs and
represents (in schools) windows programs in code.

OpenWindow (parameters, settings)
Draw
GetMessages loop/rout message handling
CloseWindow (when GetMessage returns CloseWindow instruction.)

Notice, no focusing on repainting and complex messages,
because those features are taken care of internally by
the Windows OS, and were really just resource-saving
driven concepts, an old design that follows the 80's
computer world architectures of basic computer resource
needs, computers with 64K memories. If you give my
automated windows memory management a chance, I am
happy to provide further concepts, implementation and
OS design details. And old idea, but perhaps no
better time to revise it. I have further enhanced design
concepts for OS-automated gaming, client-server,
datababase and web development needs, as well as
thoughts on platform compatibilities and interfacing
issues.


THE CURRENT APPROACH TO ACHIEVING STORING WINDOWS IN
MEMORY AND HAVING AN ENGINE AUTOMATICALLY DISPLAY THE
PIXEL CONTENTS OF THESE WINDOWS FROM THE STORED MEMORY
WOULD BE:

xxxxxxxxxxxxxxxxxx


A RECOMMENDED WINDOWS OS APPROACH TO STORE CONTENTS
OF ALL WINDOWS' DISPLAY AREAS IN MEMORY:

All drawing commands to the window make it directly
into the memory space of the window and changes to
the window in visible regions as fast as possible
appear on the screen as well. Graphics-card hardware
coordinating with the Window memory space (in the
hierarchies of windows) is probably not an ideal
solution for graphics card manufacturers, so the
Windows OS needs to maintain a screen for being
displayed. The windows needs to coordinate their
memory layout with the screen layouts and coordinate
visiblities and offsets. If a memory space is allocated
for the window - non-redraw based but statically generated
as part OS window frame / part window client area in
memory - the memory spaces need to flash accordingly
into the common screen memory space.

The argument here is that perhaps more is drawn,
if not the whole screen when say just a single
pixel is updated. This is not a desired solution.
The ideal solution would be something along Macintosh,
that the hardware would work together with the OS
graphics needs so that the pixel memory of a window
on screen would be reserved on the graphics adapter,
so all drawing would occur at optimal instant speeds
-- in other words so a SetPixel command would take
a brief hardware time to process. That's how it has
to be solved. Can it be solved?

A SetPixel instruction would take place in the
Window's memory, which is mapped to the screen memory
using coordinate offset maps. Perhaps the OS could
map many windows rapidly to use assembly to process
a SetPixel command, calculate its new offset on the
screen and determine if its in a visible region.

The Microsoft OS cannot be expected to step into
the territory of hardware specifications, so one
seeks the best software solution until in the future
standards may arise.

The Windows OS needs to have a very efficient set
of graphics functions that translate windows graphics
functions and display them on the screen as rapidly
as possible.

The thesis idea here that memory should be stored for
each window independently is further explored here for
programmer and operating system benefits and
disadvantages:

The windows operating system communicates with the
graphics driver. It fetches the data from the memory
spaces of the Windows it stores in memory, and
sends the composed results from the multi-windows
environment to the graphics adapter for displaying.
When a window appears or hides, the OS does not need
to ask for repaint instructions, but now manages most
of these tasks without repaint instructions occurring
to the indivisual windows. When a new window is painting
its contents, the contents make it both to the memory
space of the window and to the screen, which looses
processing time. I believe Machintosh design would
address this by allocating hardware process to each
window's memory and would use hardware to coordinate
the display of the changes by eliminating software
arrangements. Again, Microsoft using this approach
would remain in having to process the memory spaces of
windows, arrange and display the coordinated results
with extra software processings. A SetPixel would go
to the Window's memory space and to the Display through
offsets and determination of visibility in relation
to the order of other Windows and finally to the
Display. However the stored memory for each Window
would allow an effective management of Window ordering
without need for repainting, which I am trying to eliminate
basically for the programming comfort and elegance.

Once a line is drawn into a window, it can stay there
in its pixel memory space and painted and refreshed
on the screen from memory when window layouts change.
A repaint can occur if the window is resized and the
programmer desires to recalculate the layout for his
window, in which case he may need to erase the contents
of his window (either in memory until the repaint
operatins are complete) and have the window appear with
the changes, or have each instruction appear as drawn.

This approach sets the old-fashioned clean approach
to display management and its resources and takes some
time to reorchestrate into an efficient windows
graphical developer's user interface.

No focus on repainting as the visible contents of
the Windows are stored... Simply as now there is
sufficient memory available for such a Windows Operating
System feature and programming style should become
different, easier, cleaner. Once the pixels are in the
Window space, Windows can take care of painting it.
It shouldn't be too hard, and the windows should
flash into place instantly without observed redrawing
time when appearing from below another window. An
elegant feel when a browser window reappears without
processing time involved in connecting to the server
over the net and fetching the information. Storing
a copy of the window should steal microprocessing
time from drawing, but increase the speed involved
in switching between windows. If the graphics card
manufacturers would offer embedded windows offset
features, the issue with the loss of microprocessing
time with go away, and an overall smooth windows graphics
OS would be allowed to be born, perhaps similar to
Macintosh's coordination of Windows processes through
hardware and software and not only through the use of
software. From a programmer's standpoint of working
with the contents of a Window in memory makes work
with graphics far more comfortable, as dealing with
the graphics memories in older graphics adapters,
a direct access for the programmer to pixel data
makes life easier and the development becomes more
manageable and more fun as well.

Hi, gwin-

While I lack the technical expertise to properly appreciate what you have to
offer, I can tell you that Microsoft does not normally read the posts here.
Your idea may be a good one. Do you want to make money from it, or do you
hope to inspire others to take your concept and turn it into something?

In any case, if I were you, I would at the very least discuss this concept
on a more appropriate forum(s). I would also consider setting up a webpage,
thus allowing plenty of space for charts and diagrams, and, in general, the
proper presentation of the thesis.

You cannot expect a post here to generate much excitement, as it is a
generalist discussion group. However, in the right environment, you may find
much valuable feedback. Keep in mind, too, that if you intend to make money
from your idea, it will require patent protection, particularly if you plan
to discuss it on public forums.

Good luck!


gwin wrote:
This thesis is on a new simplified concept on Windows
OS Display Management, based on my 1980's generic ideas
about early Windows programming methodologies:

I have developed for my thesis in 1989 a mini-windows
programming environment. I was fascinated with the
idea of windows systems, and built a graphics-based
windows GUI environment at the time with controls.

My research was independent at the time from Microsoft
Windows products. The main difference was that I was
not focusing on memory-saving architectures, but more on
how I envisioned the future. I assumed in my designs that
memory will be plenty and not to worry about. Basically
I came up with a lot simpler and 'friendlier' development
environment than the architecture of focusing on
'repainting' windows upon messages, I avoided a lot of
unnecessary coordinate calculations, complex message
maps and the use of complex macros. I tried to avoid
complex structures, preserve a simple command interface,
and have a set of simple functions available with as
little number of parameters as possible so I can
memorize the function names and program rapidly.

Although I used graphics modes such as Hercules Monochrome,
CGI, EGI, VGA and later Super-VGA, I kept a text-mode
element rastel for modeling control spacing (80 by 25
for basic resolution, I think 33 rows for VGA-mode) for
easy alignments of button widths, control spacings, to
avoid something that is often hard with Microsoft
Visual C++/MFC to align pixels. I have succeeded at
the time (late 80's, early 90's) to have a development
environment where I can type up GUI applications very
rapidly. What stopped my project in the market were
technological uncertainties as companies seeked standards
which were hard to synchronize into a development
product, especially compatibilities with Microsoft
Windows due to having different design approaches in
regards to my project. Visual C++ specialized on office
architectures, while I on simples windows and sub-windows
and simple programming commands.

After a decade and extensive working experience in the
client/server/telecom/database products world, I have
revised the idea of my old windows product, and its
potentials in 2006.

I would like to describe the importances of this
potential windows client/server/web/database/gaming/
busines development environment for Microsoft's
considerations.

What is so different about my old complete 'GLIB'
Windows Programming Environment? In two words:
memory management.

Certain simplifications. A window would be held in
memory, and write to the window's memory once, and not
having to worry about repainting, only upon the
programmer's decision to do so. Confusing?

Windows can be managed in memory and repainted
internally and automatically. Such a feature carries
huge programming benefits. In the early 90's memory
was expensive. Repainting windows was a memory-efficient
design. Having 20, 30 open windows and storing all
memory for pixel information today is not so resource
expensive and that is why I am writing about this
windows design. (see details below)

I will continue describing the highlights of my
old Windows OS by showing how complex features and
mnessage maps can be eliminated (its about time to
move on from memory efficient models toward programming-
oriented models?):

Simplicity: For example in my old design I had one
getkey() function to receive all messages with
extended message features for handling mouse and
windows commands. A simple case handling and routing
to functions rather a macro-defined message system.
All in one place and in front of the eye. A window
with a getkey() loop. The default message to a
window is a key pressed on the keyboard or a mouse
click, a window resizing instruction or messages
from buttons instructing to, say, close the window
and asking for the subsequent use of the CloseWindow
feature exiting the window's GetKey() loop.

The classic underlieing windows architecture described
here is based on internal management of pixels in a
window as if they were a screen of their own, which
is a window screen by default, a sub-screen, a
sub-monitor inside a larger screen/monitor.

Observe a simple program in this basic windows
development environment:

#include gwin.h

void WinMain( void )
{
WINDOW win = OpenWindow( 40, 10, "Sample window" );
// Opens Sample window dialog of 40 default characters wide
// and 20 default row heights" );
// Space added for 10 default text rows under Title Bar

win.AddBottomCenteredButton( "OK", MSG_CLOSE_WINDOW );
// Button displayed in horizontal center of 9th and 10th row

win.WriteCenteredText( 5, "Hello World!" );
// Y position = 5th row

while ( win.GetKey() != MSG_CLOSE_WINDOW )
;

win.CloseWindow();
// closes active window
}


The basic idea seen with the simple code above, is that
the development environment starts from somewhere basic,
and moves to more complex features. Note, there is no
need to repaint a window in the code above or add
additional message-handler functions, a window is
created and exists with its own pixel-memory space
and works on its own naturally, maintaining what's
been written in there until its closed. The window is
to be thought of as a display memory space. No complex
structures and maintenance are needed once something
is written into the window, but the use of simple
graphics function calls (and parameters) to write and
erase contents from the window. A printer would be
a window as well, and not a device context. OpenPrinter...
Draw... Print... ClosePrinter.

I would be interested in building up an OS development
environment based on this core windows programming
languege environment where a programmer uses functions
which write (directly would be most optimal) into the
window's memory, and a background interface takes care
of updating the screen efficiently based on the
pixel-information held in the memory for each window.
Of course one would arrive to the need of using repaint
features when a window is resized, but that is not so
Windows OS driven any more here but a programmer-specific
task. The memory-approach to windows vs. Microsoft's
repaint-message driven approach is very feasable
for implementation.

Memory is not as expensive today and plenty of memory
should exist for holding the contents of each window
pixel by pixel in memory. This windows memory-management
idea is based on a simple memory mapping system that
correlates screen memory with screen outputs intelligently.

This approach creates very beneficial programming aspects
in the educational world for learning Windows programming
and its basic concepts with ease, allowing overall easy
learning and Windows programming from the basic windows
methodologies and concepts levels, particularly much
briefer code and less need for maintenances... managing
a window as a memory screen of its own offering a much
simpler development environment. Basically this involves
taking a few features from Microsoft Windows and
automating them.

I would be happy to consult this concept with Microsoft
further. I can offer an easy design layout of such a
GUI system model, which lays in the core of the Windows
operating system. Such a change would have to be backwards
compatible with existing programs but offer a new set
of Windows programming tools and commands for developers.
Can the basics of Windows be preserved and returned
to writing to display memories as individual non-Microsoft
Windows applications used to do so? Can the powerful two
worlds reunite as a graphics standard that both graphics
card and display manufacturers, Microsoft and programmers
respect and adore? Perhaps saving memory resources
approach is not the most important in 2006 when memory
capacities in computers double for the money spent every
year or so. Perhaps some aspects can be simplified, or
at least in the research lab for now.

I believe I revised an old and worthy dream for a Windows
OS Model, one that brings Display/monitor features close,
features like programming and gaming, a feasable but not
most efficient solution today, but once accepted as
standard other industries could join in improving its
graphics control standards. The simple idea that each
window should have its memory space correlated with
displaying the contents of the window on screen, a
window which is like a screen of its own, a sub-screen,
and the Windows OS which is responsible for displaying
the windows based on their pixel-memory information and
not based on what needs to be repainted when a window
layout changes. There is a definite plus for programmers,
offers a briefer, better managed source code and easier
approach, learning process and code management to the
overall fundamentals of Windows programming.

What becomes most apparent is how one programs and
represents (in schools) windows programs in code.

OpenWindow (parameters, settings)
Draw
GetMessages loop/rout message handling
CloseWindow (when GetMessage returns CloseWindow instruction.)

Notice, no focusing on repainting and complex messages,
because those features are taken care of internally by
the Windows OS, and were really just resource-saving
driven concepts, an old design that follows the 80's
computer world architectures of basic computer resource
needs, computers with 64K memories. If you give my
automated windows memory management a chance, I am
happy to provide further concepts, implementation and
OS design details. And old idea, but perhaps no
better time to revise it. I have further enhanced design
concepts for OS-automated gaming, client-server,
datababase and web development needs, as well as
thoughts on platform compatibilities and interfacing
issues.


THE CURRENT APPROACH TO ACHIEVING STORING WINDOWS IN
MEMORY AND HAVING AN ENGINE AUTOMATICALLY DISPLAY THE
PIXEL CONTENTS OF THESE WINDOWS FROM THE STORED MEMORY
WOULD BE:

xxxxxxxxxxxxxxxxxx


A RECOMMENDED WINDOWS OS APPROACH TO STORE CONTENTS
OF ALL WINDOWS' DISPLAY AREAS IN MEMORY:

All drawing commands to the window make it directly
into the memory space of the window and changes to
the window in visible regions as fast as possible
appear on the screen as well. Graphics-card hardware
coordinating with the Window memory space (in the
hierarchies of windows) is probably not an ideal
solution for graphics card manufacturers, so the
Windows OS needs to maintain a screen for being
displayed. The windows needs to coordinate their
memory layout with the screen layouts and coordinate
visiblities and offsets. If a memory space is allocated
for the window - non-redraw based but statically generated
as part OS window frame / part window client area in
memory - the memory spaces need to flash accordingly
into the common screen memory space.

The argument here is that perhaps more is drawn,
if not the whole screen when say just a single
pixel is updated. This is not a desired solution.
The ideal solution would be something along Macintosh,
that the hardware would work together with the OS
graphics needs so that the pixel memory of a window
on screen would be reserved on the graphics adapter,
so all drawing would occur at optimal instant speeds
-- in other words so a SetPixel command would take
a brief hardware time to process. That's how it has
to be solved. Can it be solved?

A SetPixel instruction would take place in the
Window's memory, which is mapped to the screen memory
using coordinate offset maps. Perhaps the OS could
map many windows rapidly to use assembly to process
a SetPixel command, calculate its new offset on the
screen and determine if its in a visible region.

The Microsoft OS cannot be expected to step into
the territory of hardware specifications, so one
seeks the best software solution until in the future
standards may arise.

The Windows OS needs to have a very efficient set
of graphics functions that translate windows graphics
functions and display them on the screen as rapidly
as possible.

The thesis idea here that memory should be stored for
each window independently is further explored here for
programmer and operating system benefits and
disadvantages:

The windows operating system communicates with the
graphics driver. It fetches the data from the memory
spaces of the Windows it stores in memory, and
sends the composed results from the multi-windows
environment to the graphics adapter for displaying.
When a window appears or hides, the OS does not need
to ask for repaint instructions, but now manages most
of these tasks without repaint instructions occurring
to the indivisual windows. When a new window is painting
its contents, the contents make it both to the memory
space of the window and to the screen, which looses
processing time. I believe Machintosh design would
address this by allocating hardware process to each
window's memory and would use hardware to coordinate
the display of the changes by eliminating software
arrangements. Again, Microsoft using this approach
would remain in having to process the memory spaces of
windows, arrange and display the coordinated results
with extra software processings. A SetPixel would go
to the Window's memory space and to the Display through
offsets and determination of visibility in relation
to the order of other Windows and finally to the
Display. However the stored memory for each Window
would allow an effective management of Window ordering
without need for repainting, which I am trying to eliminate
basically for the programming comfort and elegance.

Once a line is drawn into a window, it can stay there
in its pixel memory space and painted and refreshed
on the screen from memory when window layouts change.
A repaint can occur if the window is resized and the
programmer desires to recalculate the layout for his
window, in which case he may need to erase the contents
of his window (either in memory until the repaint
operatins are complete) and have the window appear with
the changes, or have each instruction appear as drawn.

This approach sets the old-fashioned clean approach
to display management and its resources and takes some
time to reorchestrate into an efficient windows
graphical developer's user interface.

No focus on repainting as the visible contents of
the Windows are stored... Simply as now there is
sufficient memory available for such a Windows Operating
System feature and programming style should become
different, easier, cleaner. Once the pixels are in the
Window space, Windows can take care of painting it.
It shouldn't be too hard, and the windows should
flash into place instantly without observed redrawing
time when appearing from below another window. An
elegant feel when a browser window reappears without
processing time involved in connecting to the server
over the net and fetching the information. Storing
a copy of the window should steal microprocessing
time from drawing, but increase the speed involved
in switching between windows. If the graphics card
manufacturers would offer embedded windows offset
features, the issue with the loss of microprocessing
time with go away, and an overall smooth windows graphics
OS would be allowed to be born, perhaps similar to
Macintosh's coordination of Windows processes through
hardware and software and not only through the use of
software. From a programmer's standpoint of working
with the contents of a Window in memory makes work
with graphics far more comfortable, as dealing with
the graphics memories in older graphics adapters,
a direct access for the programmer to pixel data
makes life easier and the development becomes more
manageable and more fun as well.