Mars Exploration Rover Update - May 1, 2006

http://marsrovers.jpl.nasa.gov/mission/status.html

SPIRIT UPDATE: Spirit Continues Winter Science Studies on Mars -
sol 820-827, May 01, 2006:

Spirit remains healthy and is making good progress on the rover's
winter
campaign of scientific experiments. This week Spirit continued
collecting a full-color, high-resolution, 360-degree panorama called
the
"McMurdo pan." When complete, the panorama will be a mosaic of 27
columns of images. The product could be finished in about six weeks,
given power and data limitations.

Spirit also conducted scientific analysis of a soil target nicknamed
"Progress" using the instruments on the rover's robotic arm.

Sol-by-sol highlights:

Sol 820 (April 24, 2006): Spirit worked on acquiring column 4 of the
McMurdo pan and made ground observations using the miniature thermal
emission spectrometer.

Sol 821: Spirit continued work on acquiring column 4 of the McMurdo pan
and making ground observations using the miniature thermal emission
spectrometer.

Sol 822: Spirit began characterization of the undisturbed soil surface
of Progress using the microscopic imager and the alpha particle X-ray
spectrometer. The rover also began acquiring column 5 of the McMurdo
pan
and made observations with the miniature thermal X-ray spectrometer.

Sol 823: Spirit continued work on characterizing the undisturbed soil
surface of Progress using the microscopic imager and the alpha particle
X-ray spectrometer. The rover also continued acquiring column 5 of the
McMurdo pan and making observations with the miniature thermal X-ray
spectrometer.

Sol 824: Spirit continued work on characterizing the undisturbed soil
surface of Progress using the microscopic imager and the alpha particle
X-ray spectrometer. The rover also continued acquiring column 5 of the
McMurdo pan and making observations with the miniature thermal X-ray
spectrometer.

Sols 825-827 (April 29 to May 1, 2006): Plans called for analyzing
Progress with the Moessbauer spectrometer and acquiring columns 6 and 7
of the McMurdo pan.

Odometry:

As of sol 824 (Apil 28, 2006), Spirit's total odometry remained at
6,876.18 meters (4.27 miles).

Log: Don't mean to be a jackass.

Dark matter energy source: explained (for real).
Gravitational atmospherics (discovered, thermogravitation exists)
Black holes: under study, they shouldn't exist in large spiral galaxies
as
a larger full swirling system such as a hurricane would form and take
shape.
White holes: may exist in the large spiraling galaxy nucleus (nothing
can enter the eye, not even light, as mass moves with maximum energy,
extremely high energies and heat, repelling all electrons in the eye
in such highly energized conditions.
though larger jets are seen in old galaxies meaning larger mass,
but also more chaotic debris entering the eye, causing electrons to
be repelled from a highly charged energetic central galaxy eye (eyes
are used for hurricanes, perhaps a better name is needed for the
spiral galaxy nucleus)
Quasars: explained. The eye phenomena explains why quasars appear
as bright lights. The source of the light comes from the center of the
galaxy, from its eye, and appears as quasars (the source of light
arriving
from the galaxy outshgines the whole galaxy itself), because the galaxy
is facing Earth head on from its center. The current speculations that
quasars may be galaxies that went on fire, its gasses at large seems
to be a less convincing explanation.
Spiral galaxy rings: Hundreds of millions of old stars surround spiral
galaxies in a ring, a debris basically like Saturn's ring, but not one
that is cause by collisions or breaking moons, but for any active
spiraling galaxy Debris naturally accumulates in a ring around the
whole active structure.

I love logs.

Reposting yesterday's research, which was denied as all deny
what is not a lie.

--

Spiral galaxies should not have a solar object in their center,
but the swirling characteristics expanded to the system at
large, as a hurricane, a full swirling system and an eye.

One of the findings which proves this observation is that I
read that no X-Rays seem to be arriving from the nuclei of
quasars, a place where a massive black hole was expected,
but years of testing and gathering X-Ray signals indicated
that the galaxy nucleus did not produce X-Rays. A different
source of X-Rays arrived from jets.

I do not have a reference to the publication unfortunately
which I read once.

--

Quasars turn out to be galaxies facing Earth.
Their eyes like lasers outshining the whole Galaxy,
eyes of light, shining out of... an eye of spiraling
conditions. Two tails like often seen with hurricanes.
Huge explosive turbulant activities near the center.
The center that is like inside a planet, void of gravitation,
a natural place for an opening. A hurricane. A spiral
galaxy. A central place of high energy, temperature
and heat generating very bright light. Where is the
blackhole they are talking about? Somehow momentum
seems to overwhelm Einstein's relativistic black holes,
his models, the world's models. Perhaps the Universe
is simply a lot bigger than it appears in the minds of
human beings. Once the Universe was an Earth, and
the Sun, the Moon and the stars orbiting it, below hell,
above in the clouds: heavens. Hurricanes are very small
and disorganized. They are equivalents of smaller galaxies.
http://www.howardsview.com/Revenge/hurricane.jpg
Galaxies are more. Pour rain into the eye of the hurricane
and its humidity spirals up and out. Low pressures keep
things there dry. Low pressures keep things there cool.
Very cool, and very dry. Old galaxies were more active in
their nucleus producing stronger jets, because the Universe
was more chaotic. That is.


http://www.burg-halle.de/~albrecht/b...laxy%20M51.jpg


It is heavy raining. Heavy turbulance producing gravitational
waves and many things, but unlike hurrican storms moving
along currents, often more than one hurricane in a row,
these objects are unique, and attract each other.


I propose that all spiral galaxies have a faint ring surrounding
them. A ring consisting hundreds of millions of old stars,
accumulated from the cosmos, a ring which feeds the tails
of the spiraling galaxy storm. A storm of heat, as heat needs
action. Collisions. Accumulation. And high and low atmospheric
pressures. Except low pressures in space may not have
ability to attract matter more, but it probably does, we know
so little of dark energies.

--

Except low pressures in space may not have
ability to attract matter more, but it probably does, we know
so little of dark energies.

Expand this, ok? : You need to see first that a spiral
galaxy acts as a full swirling system as a hurricane,
swirling away anything from the center, thus due to the
magnity of spiral galaxies, one can conclude observing
the nature of strong swirling properties resembling hurricane-
like features, that if no solar mass exists in the center
of such naturally swirling entities, then we are talking of
an atmospheric phenomena where high and low pressures
exist. The proof of dark matter energy lays in the realization
of void space carrying a gravitational pressure in comparison
to high-pressure regions where matter is dense in the
region. If there is no black hole in the heart of spiral
galaxies due to the swirling hurricane-al natures, then
one finds that due to the appropriate natures of gravitation
applied in spiraling galaxies, there is a necessity for
gravitational growth in low-pressure mass-free regions,
thus the correspondense of weaker gravitational aspects
playing roles in high-pressure regions of space. Why?
Why does this explain dark energies arising in the emptiness
of space?

In my mind it was all so clear yesterday because I
understood everything that I was talking about.

Let's prove the discovery.

a) assumption: "no X-Rays arrive from the spiral galaxy
nucleus (and quasars) as expected." (Read an article once
that that is the case with a quasar, where years of X-Ray
measurements showed that X-Rays did not arrive from a
hypothetical black hole there as was expected). I propose
that is the case for most galaxies, that no X-Rays should
arrive from their nucleus, and jets should carry different X-Rays.

b) assumption: "most spiral galaxies and large swirling
entities in space which was calculated to have a black hole
should have a light beam exiting its nucleus in North and
South directions." This is based on hurricanes and the
nature of general swirling conditions. My proposition is that
rather than a black hole, the way nature works is that for
'masses of black holes', high energy conditions are reached
and swirling characteristics with an eye are born, from where
the inner wall of the eye generates an outward-evaporative
environment of high pressure from where matter swirls out
very energetically along the North and South poles of the
environment titulated as having a black hole. This can be
modeled as pouring rain into the heart of a hurricane eye
would quickly dry and evaporate up in swirling fashion along
currents, just as electrons form jets in active galaxies. The
source of the jets may be that debris in a chaotic galacy nucleus
may make it into the eye from the North and South opening
of the eye, and the highly energized wall matter in the eye
rejects electrons, which escape from this high magnetic
energy zone in forms of jets in two directions, repelled. The
region surrounding the wall of the eye of is of course highly
charged as the swirling of very high-pressure, high-temperature
mass is very energized from its nuclear activities, a very
turbulant and explosive region of a highly-compressed and
massive environment. One needs to see that accumulation
of percipitation near the center of the hurricane does
not close up its eye, and explain why that is.

To arrive to showing that dark energy arises in space void
of matter, one first needs to show that there is no solar mass
in the nucleus of large spiraling galaxies as such a galaxy
as a full acts as a hurricane system, producing an eye and
not a mass central solar object called a black hole.

So dark energy exists, because:

Its how it works. It has to be there because if its like
this in one place it has to be that in the other. I already know,
but I don't know how to say it. So, its proof.

Its simply because dark energy exists because the light
one exists in otherwise black holes, which sieze to exist
in spiral galaxy nuclei as a solar object, but important
to be recognized in terms of spiral galaxies acting as a
swirling system, as a whole, as a hurricane. And from that
conclusion, one finds the properties of dark energies being
a natural conclusion of this good nightly sky of the place
that has acting in the other which is then of proof of the
this because that of an area of the highlight of the place
because.

Proof. Why don't just scientists want to work on this.
The moderated sci.astro.research people say this
is no accept, for here. And I tried to be serious,
but they did not like to see hurricanes and mixes of
issues which they think is the case but its not that
like they think of my approach. It is has to be of that
normal which they are not that of agreement with the
approach of the presentation of the information presented
for the community which they moderate for their professional
sides to be of value of community and partnership standard
approach, in consideration with science and society and
standards which they feel as usual and scientific, I am
have a science degree as computer scientist, but I am
a scientist, but they will not get approved for solving my
science by my community.

Work of my science. The problem of the Microsoft OS's
handling of the internal graphics solutions, and they
should apply a different concept compatible with me.

---

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 simple 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
message maps can be (Is it time to move on from
'memory efficient' messaging models toward programming-
oriented graphical device programming approaches/models?
Hard to say for sure.):

Windows Interface 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 10 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 here
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
like 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
language 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 concept levels, particularly more
brief code and less need for general 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
utilize? 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 more brief, better managed source code and easier
approach, learning process and code management to the
overall fundamental aspects 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
solutions, say by 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 individual 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 the 'Machintosh design' would
address this by allocating a 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.

Conclusion:
The problem is using extra memory for keeping bitmap
copies of windows (memory is becoming less a problem
these days) and drawing twice, with say a line, once drawing
into the memory space of the window, and once to the screen,
and only hardware could optimize the two into a single efficient
operation, but graphics adapter manufacturers would not be
bothering with mixing otherwise needed graphical Windows OS
and hardware features for PC-s.

Always back in the past, with stupid people like Bill Gates
who said: nobody needs more than 128K memory. I was
never like that.

How does one beat Windows makers and make them
think of the future and not only of the present and past
and not how things are put together bit by bit (Microsoft),
but how things really are?

Summary: It is time to rebuild Windows from scratch
according to current memory capacities, and not build
on the old technologies. Again, rather than this update,
Microsoft should be thinking of the future, which it won't.
Knucklehead Gates.