Can anyone tell me, why Menuet uses misaligned RRGGBB color byte format, especially with images?

I ask this regarding the current API implementation.

- At first, this data format is misaligned (3byte). For some reasons this is not really clever.
- Second, alpha is not supported. Byte one could be easily used for alpha byte. So we could implement semi-transparency as a generic principe for API drawing.
- Third, also windows and other drawing elements could be implemented in this way, if there was a well designed basic color format for the OS / API. Byte 1 is actually used for several (additional) flags with different API functions. This is not ideal and very confusing.
We should have a properly aligned 32bit color data format with the 4 bytes in the form: AARRGGBB, where AA is reserved for alpha byte (semi transparency). This also would simplify the access of new 32 bit portable graphics formats, like PNG od JEPG2000 and so on.

The only way to do some advanced graphics at the moment is to directly access the driver or doing some (unoptimized) tricks, like the "transparent window example application".

I think, before we develop some special applications, we should prepare a usable graphics/drawing interface to the API with a standardized general color format and then and a basic set of generic interface controls, like sliders, editfields and -boxes, trackbars, optionfields and so on, based on 32bit color. At the moment each developer has to invent the wheel new each time.
At least we need something like an API controlled draw context handling for windows and a well designed iterface API for easy access by application developers. The current state, with transfering images to window contents is not satisfactory. Also using simpe buttons for all thinkable UI access is somehow "primitive".

We actually do the second step before the first. We develop several new applications based on very raw user interface elements. This is dangerous, because ineffective and tends to user interface chaos, I think.
.

Excuse my english, I am not a native englisch speaker.

I'm no MeOS expert, but
REPZ OUTSB
REPZ INSB
will load a palette practicly instantly if there is no white space (zero bytes) in the array. (like a Dword holding 3 bytes does.)
LODSD seems quicker to load the needed 3 RGB bytes, but load to what?
Nothing that uses the palette can use it in that form ?
If it's a file being loaded, "align 4" each RGB doesn't matter.
other than is slows down the load due to the fact that it's 1/4+ bigger.
The nitti gritti of asm coding that uses 4 byte Dwords to hold the 3 RGB bytes
is that it has to shift, inc, mov, loop, or other garbage that REPZ OUTSB doesn't do.

Maybe that's the reason, a RGB color array is best stored in 3 byte chunks.

PS, I'm still looking for a general help.txt file for newbee's, plz.