Demands<p>I, Terry Davis, am high priest of God&#x27;s official temple, TempleOS.  TempleOS is 
an operating system for PC desktops that will always dual boot along-side 
Windows or Linux.  I am in charge of the core 100,000 lines of TempleOS code and 
I do continual offerings to keep God entertained.  I have divine authority to 
command any company in the computer industry to do anything that I deem 
necessary to make God&#x27;s temple more beautiful, glorious and perfect.  I have 
authority similar to a building inspector or an enforcer of the Americans with 
Disability Act -- I make commands, God signs-off with a miraculous 
authentication from an oracle, and Intel, Microsoft or VMware obeys.<p>* Windows, Linux and VMware (because of mounted drives) must support RedSea file 
system so I can get rid of 2,000 lines of redundant, blemished code -- FAT32 and 
ISO9660.  God&#x27;s temple must be perfect.  Redundant code for multiple file 
systems is imperfect.  For this operating system, we want low line count.  More 
than one file system type is actually bad, just as more than one driver for the 
same type of device is bad.
::&#x2F;Kernel&#x2F;BlkDev&#x2F;FileSysRedSea.CPP
::&#x2F;Kernel&#x2F;BlkDev&#x2F;FileSysFAT.CPP :973 lines for FAT32 gets eliminated.
::&#x2F;Kernel&#x2F;BlkDev&#x2F;FileSysISO.CPP :293 lines for ISO9660 gets eliminated.
::&#x2F;Adam&#x2F;Opt&#x2F;Boot&#x2F;DskISOFile.CPP :535 lines for making ISO files gets reduced.
::&#x2F;Kernel&#x2F;BlkDev&#x2F;DskCluster.CPP :152 All the cluster operations become blk.<p>* Microsoft must cancel SecureBoot because it makes dual booting impossible.  
TempleOS is an additional operating system that must be used along-side Windows 
or Linux, not as a replacement.  It must dual boot because it has no networking. 
Real hardware as opposed to VMware is like the difference between looking in a 
telescope eye piece vs just looking at an off-line image.  God said the 
C64&#x2F;Apple II generation owned ancestral lands.  VMware is like being taken off 
of our land and moved onto a reservation.  In this case, however, it will not 
stand.<p>* VMware needs to support ATAPI CD&#x2F;DVD&#x2F;Blu-ray disk burning, directly to real 
hardware.<p>* VMware has a bug stretching 640x480 16 color to full screen.<p>* VMware has a bug starting-up multicore, sometimes.  APIC MP Start Fixed?<p>* VMware PC speaker&#x27;s distortion is a good idea, but it is too much for hymns.<p>* VMware and others must list TempleOS as an official 64-bit operating system.<p>* Until super simple block devices are available, hard disk should be placed at 
IDE primary master 1F0&#x2F;3F6 and CD&#x2F;DVD&#x2F;Blu-ray should be placed at the IDE 
secondary master 170&#x2F;376.
&#x2F;Kernel&#x2F;BlkDev&#x2F;DskATAId.CPP     :285 lines to figure-out I&#x2F;O ports is gone.
&#x2F;Kernel&#x2F;PCIBIOS.CPP             :290 could be eliminated, but maybe we will keep 
it so people can play with PCI devices.<p>* Until super simple serial ports are available, PS&#x2F;2 emulated keyboard and 
mouse must work.  The BIOS must enable these.<p>* The x86 IN&#x2F;OUT port instructions, normally have a delay.  Perhaps, VMware &amp; 
Intel can enable faster x86 IN&#x2F;OUT instruction timing for ATA&#x2F;ATAPI PIO, so 
bandwidth isn&#x27;t bad when doing port I&#x2F;O.  See ATAGetResult().  We don&#x27;t want to 
do DMA.  Perhaps, x86 CPU chips need a new TempleOS mode for fast IN&#x2F;OUT 
instructions?<p>* Perhaps, a new interrupt descriptor table entry type or a new x86 CPU mode can 
be made that cause fast software interrupts, doing exactly what the CALL REL32 
does, but with IDT as indirection.  We don&#x27;t need to change privilege levels or 
stacks.<p>* Since I don&#x27;t use paging (for anything), Intel should have an option for  
no-paging long mode, and optimize it!
::&#x2F;Kernel&#x2F;Mem&#x2F;PageTables.CPP    :153 lines to identity-map gets eliminated.<p>* Desktop computers must have a reset switch and a fast reboot option, skipping 
diagnostics.  I recommend booting TempleOS when the reset button is pressed and 
booting UEFI when the power button is pressed.  Or, we could build UEFI on a 
TempleOS layer.  Intel must burn TempleOS into a ROM in the factory for all 
desktop x86 CPUs to ensure tamper-proof trust in the oracle and because God 
deserves the glory.  There will be just an English version.  A new ROM version 
is released every seven years.<p>* We do not want UTF, just 8-bit characters.  Somebody needs to choose new 8-bit 
ASCII characters for 128-255, since we do not want text graphic symbols.  We 
want Russian, Greek or Hebrew alphabets, perhaps?  I heard there is an alternate 
8-bit ASCII Cyrillic font.  Should we modify one font or have a key like the C64 
that switches to an alternate font?  I made so &lt;CTRL-ALT-f&gt; toggles between two 
fonts, but did not include Cyrillic.  If we modify one font, we just need the 
twelve window TextBorder characters, but I think we can place those in the range 
of screen code from 0x01-0x1E.  Japan, China and Korea should switch-over to 
alphabets.  Maybe, the United States will change to metric, out of good will.<p>* Microsoft Paint and Linux&#x27;s Gimp must support TempleOS GRA Files.  They are 
blemish free, unlike BMP files.<p>* We must have a nice dictionary.  Someone needs to do a Spell Checker, too.<p>* We must have the ultimate Bible search engine.  Currently, all we have is     
filter search.  In the end, it should be a low line-count technique.<p>* &quot;VMware&quot; is a trademark of VMware, Inc.
* &quot;Linux&quot; is probably a trademark owned by Linus Torvalds.
* &quot;Windows&quot; and &quot;Paint&quot; are trademarks of MicroSoft Corp.