RD Future 2017 Media Player Blog Photo Show Scripts

Media Player - HTML Applications
Media player introduces an idea from lightweight applications.
Applications are written with Java or Visual Basic scripts

Basics for the HTML scripting

HTML script is compiled when you load the page / script file. After that the scripts are compiled by demand. It is possible to generate new script with a script.

Scripts uses variant fields and arrays. They are defined as objects. Length is detected with len property. There are global and local variables. Variable definitions follows common rule : variable outside function is global, variable inside function is local. Variable definition can have default value and dedicated type. Dedicated types are sometimes needed, when you make calculations from the on-screen field-values. Global variables are unit level variables, which can be accessed from other units.

DHTML array is always one dimensional, but an array element can point to another array. You create multidimensional arrays by creating arrays into array.

Script can be embedded into tag or in separate Java script block in Head section. When writing bigger and longer scripts, they are always written to script section in the header. It is possible to write scripts into separate files. It is possible to embed scripts into body. Things you add / change with scripts are temporal on-screen systems. Print or view to HTML source never shows the changes you have done with script.

All HTML tags can be converted into programmable DHTML objects. All tags have ID attribute. ID attribute is the name of the tag. When set, it must be unique throughout the document. In scripts you use IDs just like object names in common programming. Ids can overlap with each other. <p id="ProgrammableTag">Text<b id="BoldSection">Bold text </b>text continues</p> 

When you embed documents and Active X controls into document, you give them names with ID attribute. These names are used like parents in common programs. HTML documents are embedded with tags, which has hyperlink to the embedded document. In script you use the tag name, with tag-id. 

Both Java and VB uses dots for separating.

Basic caller of the script is hyperlink definition. You replace literal hyperlink, with script function and parameters. <a href="javascript:ScriptName(Parameters);">
The events for each tag varies. Event handlers are added into tags by adding the event and script call into tag. <p onclick="javascript:clicker" onenter="javascript:entering">

All table elements can have IDs. Table is collection of tags. Tags can be accessed with Row and Column numbers, too. When you add x-number of rows or columns into table, usage of IDs is difficult, row-column number system ( without IDs ) is usually easier. DHTML do not have a command, with what you can convert generated, literal ID name into a pointer value, which refers to the ID.

MS Script editor help has full documentation for DHTML-4.

Media player will get DHTML-4 plus scripting. In 4-Plus IMG element has original picture and video sizes. Then there is media player element, which defines basic functions for playing music, videos and photos. HTML does not have sound element, there is only BgSound, with you can play background music.

Also possible that 4-plus will get a strip attribute. With strip you could drop "decorative" elements from the screen, when it is shown on small handheld player's screen.

Besides dedicated viewports, 1k, 2k and 4k system  gets a screen resizer system. OS can increase and decrease the screen size with picture editing system. In good picture editor you always increase / decrease size with even number of pixels : one pixel is enlarged to two, three, four, etc pixels. The size is downgraded so, that one pixel has two, three, four, etc. pixels. Free, random scaling always messes the screen layouts. After you come back from another scaling, controls do not keep their places, they start to move on the screen. ( in picture editor, the picture gets messy, because pixel values changes ).

4-plus will not support dangerous Java-applets and embedded objects ( they are hardly ever used / enabled ). New ActiveX controls ( possible also Fonts ) must be installed to computer. When you try to install these things via web, the execution stops, you have to install new objects into computer. The browser can use rather freely installed Plus-4 compatible programs / objects.

DHTML-4 and DHTML 4-plus are safe systems. They do not allow manipulation of the computer via uploaded page. Fucking hacking 6T jerk always comes and makes messes via underlying TCP-IP network, web-browser's hidden features and installed add-on programs for web browser.

DHTML-5 grants access to the essentials of the computer. Then it violates your privacy / human rights. It has nothing, which would improve / ease the page creation. DHTML-5 misses DHTML-4's widely used automated frame system. In DHTML-5 you must always position and resize embedded pages manually with scripts. DHTML-4 frames are needed on certain sophisticated pages. On ATS site Fairy Tales and Maxwell Thunderbird stories / players are in DHTML-4 frames. You need D4 frames, when you have sidebar-header-footer, with what you load contents for the main page. Not possible with D5. DHTML-5 pages and browsers seems to be very slow.

Localization in 4-plus goes with flags and new permanent browser storage. All pages can have small ini-file formatted local text files. You can store and read the selected flags into it. HTML page has free access to these files. Files are additions / replacements for cookies ( when you access these files, browser will not restrict access / prompt confirmation ). Simple text files, which cannot be activated / converted into executables or macros.

Media Player will get two networks. Private and open. Destiny of the open network is open. Web browsers and other port 80 systems uses open network. By default open network has write access to the uploaded file and email  storages. Read-write access to cookie-settings storage. Local eMail program takes care of the final filing, the communication line does not need such. 

Communications are always file based, right to write files is always needed. Open network communication line do not have rights to create ( at least executable ) memory blocks. FTP protocol has indirect write access to hard disks ( user chooses the directory, etc. ), it can query the contents of the currently open file. Executables in the storages are not processed automatically. A macro in attached file cannot be controlled. Attached HTML file follows the common browsing rules.

Local eMail program can use special restricted hard disk space. Whole or a part from special restricted eMail space can be encrypted, it is accessible via eMail program, but not via network. eMail program is read only executable, you got to certify the program. Rules and laws for mails delivery-privacy-secrecy are very tight. Mail robberies / blockings are the second biggest crimes, after bank robberies. Eavesdropping phone or opening letters / hacking eMails are crimes which matches to burglary : Penetration to someone's home and privacy, without permission. Cops and others needs court order for doing such. Idea of braking the rules for national interest requires that your parliament / government makes a decision, that this thing / reason has national interest. You need a document from decision and voting results. Not possible for you and the supporting midgets to do such decisions. When you play your bold games with things, which are close to national interest, you are in danger to get a conviction from terrorism to yourselves.

Active desktop, option for downloading and running program directly from the web and others will be scrapped.

Open network does not prevent creation of the honestly made email / ftp-programs and web browsers.

Private network is like the current network.

Sample

From the below you find basics for using dHtml-4 interface with Delphi ( 5 ). Web browser component has document interface. You take it use by declaring variable for HTMLDocument. After you assign the document property into this variable, you get access to Document rooted DHTML-4 features. ( the most from the document ). Web browser is closed unit. You can never send any data from the component to the program and manipulate program flow with component. ( it comes from the safety ). It possible that in DHTML-4+ you can get script events to program. Events never allows the caller to manipulate the target. A chance for external event handler is never a security risk. You need external event handlers with custom browsers. In for example database application. Player program is another, which needs information / events from the DHTML-4+ component. You need for example resize events.

Help for WebBrowser misses the requirement for declaring the variable for the Document property. Document property is a useless pointer.

Upgrade to newer browser version, needs that you re-generate enormous MsHtml unit. All DHTML-4 functions and properties are declared there. In principle re-generation happens with only one-click. In practice more is usually needed.

unit Car07;
interface
uses
 Windows, Messages, Classes,  MsHtml, OleCtrls, SHDocVw;

type

TCar007 = class(TForm)
  wHtml: TWebBrowser;
Public
  wbDocument : HTMLDocument;
  Procedure ToHtml(HtmlFile : String);
End;

var
Car007: TCar007;

implementation

Procedure TCar007.ToHtml(HtmlFile : String);
Var
  wS : TStringList;
Begin
  wbDocument := HTMLDocument(wHtml.Document);
  If wbDocument <> nil Then Begin
    wbDocument.close;
    wbDocument.clear;
   End;
  wS := TStringList.Create;
  wS.LoadFromFile(HtmlFile);
  wbDocument.write(wS.Text); 
  wbDocument.title := 'Loaded via DHTML com-interface'; 
  wS.Free; wS := nil;
End;
End.

HTML size support for executables

Media player will get a support for scaling the screens. When you design screen for 1280x720 ( or corresponding ) screen resolution you design the screen for 96 DPI scaling system. 96 DPI is set to equal HTML's normal screen size. Below this there are 84 DPI and 72 DPI scales.  With 72 DPI font size 8 falls to 6, with 84 DPI it falls to 7. Actual DPI for 8 to 6 scaling is 69.82. For 8 to 7 DPI is 75.55.

Basic problem with scaling are floating controls. In order avoid floating, you should follow the tables below. When you shrink data, you run out of unique numbers, in order to provide all sizes unique shrink values you must not use certain sizes in native screen design. The forbidden sizes are 3, 7, 11, 13 and 17.  These 20 number ranges are in force to the end.

In the next range forbidden numbers are 23, 27, 31, 33 and 37.  In tables yellow-box numbers are rounded up, red-box are rounded down. White boxes are rounded with common up-down rule. From the grayed columns, you see how the resize function calculates forbidden values.

DPI - 72

Size  0 1 2 3 4 5 6 7 8 9
  Scale                     
Exact Down  0,75 0,00 0,75 1,50 2,25 3,00 3,75 4,50 5,25 6,00 6,75
Rounded Down 0,75 0 1 2 2 3 4 5 5 6 7
Exact up 0,75 0,00 1,33 2,67 2,67 4,00 5,33 6,67 6,67 8,00 9,33
 Rounded up   0 1 2 2 4 5 6 6 8 9
                     
  Scale  10 11 12 13 14 15 16 17 18 19
Exact Down 0,75 7,50 8,25 9,00 9,75 10,50 11,25 12,00 12,75 13,50 14,25
Rounded Down 0,75 8 8 9 10 10 11 12 13 13 14
Exact up 0,75 10,67 10,67 12,00 13,33 13,33 14,67 16,00 17,33 17,33 18,67
  Rounded up   10 10 12 14 14 15 16 18 18 19

 

DPI- 84   0 1 2 3 4 5 6 7 8 9
                       
Exact Down  0,88 0,00 0,88 1,75 2,63 3,50 4,38 5,25 6,13 7,00 7,88
Rounded Down 0,88 0 1 2 3 3 4 5 6 7 8
Exact up 0,88 0,00 1,14 2,29 3,43 3,43 4,57 5,71 6,86 8,00 9,14
 Rounded up 10th 0 1 2 4 4 5 6 7 8 9
.                        
    10 11 12 13 14 15 16 17 18 19
Exact Down  0,88 8,75 9,63 10,50 11,38 12,25 13,13 14,00 14,88 15,75 16,63
Rounded Down 0,88 9 10 11 11 12 13 14 15 16 17
Exact up 0,88 10,29 11,43 12,57 12,57 13,71 14,86 16,00 17,14 18,29 19,43
  Rounded up   10 11 12 12 14 15 16 17 18 19

DPI for common screens goes so that 1600x900 = 120 DPI, 1920x1080 / 2k = 144 DPI, 3k - 288 DPI, 4k - 384 DPI. These enlarged DPI's do not have rounding and spacing problems. 1k - 2k conversion multiplier is 1.5. Conversion does not create exact matches from the screens, it creates non-floating screens only. Number one and two remains unchanged quite a long times.

Scaling is twisted so, that you can use numbers 5 and 15 in your screen designs. Scaling can be attached to the old programs, by operating system. Downsizing to 84-72 should be disabled for non native media player programs.

Biggest screens are already 70 inch screens. In cars screen size falls to 10 inches or less. Media player needs the scaling system. Car player uses often "too high" screen resolution. 1920 * 1080 resolution is not rare in car player.

Player needs small control screen. Separate small screen, which can be embedded to remote control, computer's main screen, etc. Control screen needs it's own contents and resolution settings.

4k screen has rather tight demand for display manufacturers. 384 DPI means that the dot size must be 0.06615 millimeters or less. In traditional LED display each dot has three bulbs. Each bulb must be 0.03 mm or less. New tech has only one bulb per dot.

Not very clear how the 1k, 2k, 3k and 4k are calculated. 1280*720 is rather far from 1920 * 1080. 1k size for 1920*1080 resolution is 960 * 540 pixels. Such size has never used or existed. Pixel counts do not match either. 1920*1080 has 2 073 600 pixels, 1280 * 720 has 921 600.


In this picture you basic problem with various picture sizes. And also the power of BrResize function
On left there is original scan from King of graveyards. In the middle and right the king is shrank to 10% from the scan size.
The result from the best smart resizer I had, is in the middle. BrResize is on the right. BrResize managed to keep the king's face 
When you go upwards, it is much the same. BrResize is the only function, which allowed to use and scale old 4-bit 96x71 cards in ATS solitaires.

I have tested CBS colors with RGB pictures. CBS based picture enhancers are much like BrResize ( already with RGB data ).

Before resize the scan was pre-processed with color flattener. Scanned 16-color picture had around 70 000 colors. Flattener dropped the count to 800.

ATS Games

All new ATS games have resolution independent main screens. In solitaires you got to position slots, decks and others. The solitaire's main screens are designed with logical units. Horizontal base unit 100 is width of the card, vertical base unit 100 is height of card. When you open the game, these design time logical units are converted to pixels. Conversion is made with current view port size. Converter is in display engine, actual game programming and board designing is easier and faster than with physical units. Resolution independent system is sub system in the system, which allows the same game to have multiple board-variants.

The resolution independent screening system is over 20 years old already. Still unique to R&D / ATS games. In for example 3D game design, you use physical units.

Addition and usage of the resolution independent controls and areas is quite a lot easier than in 3D system. Resolution independent system uses self-made object arrays. With array index, you can manipulate, add and delete objects in the display engine. Array has object like methods and properties. In solitaires the display engine array holds also the game-play data. Simple solitaire games have only around 500 lines in Pascal source and around 400 lines in DFM file. The game engine unit is not very big either, currently around 2000 lines.

Elliptical Line

Media player will present an idea from elliptical line. Elliptical line is 3 point line. It is given with two connection points. 3rd is intersection of the tangents from the connected lines. In 2d-3d systems you can create curved meshes with  elliptical lines. Not possible to use arcs, because arc does not form simple closed regions. Elliptical line is always guaranteed to form a shape which is easy to fill with manipulated textures. With elliptical lines and curved meshes you can get smooth rounded shapes into games and others.

When you connect curved lines you use tangents for the endpoints. System is fully supported by existing hardware. Bezier curves are usually set so, that the curve forms an elliptical line. Elliptical line does not need Bezier points. Bezier-arc has free extension points for both ends of the curve. In self made elliptical line you set both points to the tangential intersection.

When you change end point positions, elliptical line does not need programmed calculations. Automated elliptical line is the only way to make curved meshes and shapes. No matter how you twist the mesh, the curved boxed area remains simple ... relatively simple. Simple enough for stretching the texture.

These elliptical curves and meshes are only 15 years old by now. Grabbed them to media player from the old game prototypes.

- - Height maps - -

Media player implements also the old height map system. Height map is gray scaled bitmap. The ground level for the height map is the underlying shape. The height map has detailed z-positions for the pixels in the shape ( rectangle-circle-polygon-ellipse ). You can use height map for carving molds for the designed items. Height map has details for shape.

In games and other 3d systems, you use height maps for creating shadows and shadow maps. Shadow map is another gray scaled bitmap. Shadow maps are used for Alpha blending. In one Alpha-blend form you set lightness for the pixels  Alpha blending is also used for setting transparency of the object. In video editing you use alpha blending for setting speed for transitions. In picture editing you use blend-maps for creating predefined shapes.

- - Angled shapes - -

For animation media player will introduce angled points, lines and shapes.  Angled line has start point. The end point is calculated from length and angle. When you change the key-points position position ( angle or length ), the whole shape and all overlying bounded shapes moves accordingly. You can for example easily build a system, which simulates planetary rotations. Planetary rotation system is almost impossible without angled shapes.

In games angled system makes animations simple and fast.

In angled system you cannot change underlying system from overlying system. When you do so, changes to underlying animation system ends easily into eternal loop. You must always consider and prevent looping in your program.

4k support

Media player is also getting screening components and functions which has run time scaling systems. Most important is hosted object called ThGlyph. ThGlyph is a general usage sub-object which holds text and icon for outlines, listboxes, grids, treeviews, listviews, etc. Hosted object is an object, you can add into any control-object or windowed-object. ThGlyph resizes both text and graphic. ThGlyph will also get limited HTML formatted text display capabilities. When HtmlText is checked in options, html tags are skipped, part of the commands will be processed. Processed commands are naturally text formatting tags and CSS-styles. ThGlyph supports various inplace editors : comboxes, checkboxes, multiline edits, common edits, etc.

If you are too young or distant to remember, on the right you see reason for the support to multiple simultaneous screen resolutions. The screen shot is from old DOS based Yatzhee game from the year 1993. The game is still playable, also in window.

 It uses the given very low resolutions, when you play it.

In 4k you increase the resolution for big pictures. Without change in viewport's resolution, DPI for the picture remains unchanged. When you show the uncompressed picture / frame, the area it takes grows. When you resample picture for view, you drop pixels from the picture : You adjust picture's DPI so that it fits into view port. Shrinking downgrades the quality of the picture.

BrResize keeps the dropped values better than other resizerss. Like I said in 2010, it is so slow, that you have to add it to graphic card's CPU. It dies when you resize big 4k or better pictures. 4k needs CPU support for MPEG-JPEG compression and decompression, too. 

All new cameras takes pictures in 4k / 300 DPI or better. In order to get proper benefit from the high capture quality, you must use high resolution windows. Possible that such chance would be added to DHTML 4+ image-video component. Like I said, DHTML 5 gives benefit to control freaks and a-likes, only.

All computer programs can have software and hardware implementations. In for example cars, you usually write and test the code as common software. After the program is finished, it is burned to CPU.  Chip makers, who rejected Deca-tech do not do these chips. The last home analog audio systems  from early 1990's had very complicated electric programs, electric program is a computer program, which is made with small transistors, resistors, capacitors, relays and others. Electric programs were common in automated machines, which were used in manufacturing.

One possible option for media player is a chance to write programs directly to additional CPU units.  You could write programs for graphic cards CPU, MPEG encoder-decoder and so on. All modern graphic cards have a standard set of commands for windows drivers. GDI, OpenGL and Direct X commands are executed in Graphic cards CPU. Program which is written for additional CPU does not use main CPU for passing the commands. For programs you need RAM memory for storing variables and others. When you block the reserved memory from primary CPU, there are aren't any conflicts.

Major different in Graphic GPU and common CPU is in smallest data size. GPU plays with bits, CPU with bytes. In double programming, you build the screen and response to paint event in GPU program. With CPU you modify data. Traditional additional CPU-system has a burned program in ROM memory. Motherboard's bios ( which controls chipset ) was usually burned to small ROM block. Nowadays they use programmable ROM blocks. Creative's EMU and later Sound chips uses common RAM. Sound Blaster - AWE had memory for MIDI banks, etc on board.

Textbase support

Typical for textbase file is that, there are missing fields and fileds with more than one value. There will be a data storage object for meeting these demands. Two proto types are special editions from Delphi's TStrings object. Besides TB demands, there is support for all common list types : Tabular grid, directory tree and common list. Storage object is ThGlyph like all-in-one system.

Return to ini-files

In media player you return back to ini files. Ini files were abandoned in mid 1990's. Reason was inexperienced users. Accidental changes to essential settings are rather common amongst inexperienced. When inexperienced user does so, it is a catastrophe. He-she has to ask help or take computer to repairs. Nowadays common users / people knows computers so well, that accidental changes to settings are rare. Even when you do so, you are not completely helpless, like you were in 1990's. Another reasons were slow processing speed and memory consumption, computers were very slow then. Windows 3.1 consumed over half from the installed memory.

On the left you see route creation maintenance for ATS games. On the left there is list from entered points. As you can see it is in ini-file format. It is also maintained with the in-out functions for ini-files. In this program system is very good for searching reason to the points and tracks, which are not - as you can see - in the intended shape and positions.  In the end  the functions you write for debugging, comes into good usage. You get excellent save-load setting systems. DOS had even more difficulties with memory. By default DOS program can use 640 kB memory Usage of high memory needs / needed changes to programs. No matter how much memory you have in your computer, old DOS game uses 640 kB memory block. Run out of memory errors  are common in old games ... programs. Usualy they work in new computer.  But were often made so that, they use computers maximum operating speed. Such system speeds up the game, nowadays often too much.

Debug screen on the right is general usage text box. Contents is always written and read with the program, which opens and uses the debug / error log window.

? Delphi has ready-made ini-file object, with what you can maintain ini-formatted TStrings objects. As you can see, the screen on the right is maintained with self-made ini-handlers. Formats are not the same.

Media player File Explorers

Media player File explorer has built in support for playlist behavior. File explorer has two parts, there is display system, then there is underlying file name search / read system. HD unit brings you text-file like lists from file names. You ask parameters, filters and sort order to HD component on file explorer screen. Then you call the component with given parameters. In return you get a list from files. Alternatively you can get events during iterations.

The picture presents text explorer proto. In media player default drag-drop option is filename dragging and dropping. In file menu there is an option for saving and creating file / playlists from the files on the right. There will be converters for various playlist and file list formats, you can choose the converter from the save as dialog.

Thumbnail explorer uses the same HD reader than basic explorer. In File menu there is an additional option for saving generated thumbnails to disk.  You can use BmResize for creating good quality thumbs from your photos.

OLE explorer has file list at the bottom ( by default ). The work area can have COM-OLE or self made file viewing / editing component[s]. This explorer shows generated HTML for the photo show. They were still blanks, when I took the screenshot. The file list can also be a list from the ripped DVD-BD directories. The explorer shows the root directory, but the actual directory is VIDEO_TS sub directory.

Explorers have color sets. You can set different colors to different explorer. Alternatively you can set same shades to the explorers, which are synchronized together. There is sync menu with what you can create co-operative groups from opened explorers and forms.

Media players OS concentrates into file processing ... reliable processing of the files. The HD unit makes most from the work, it provides lists or events from the HDD iterations. The display components have properties, methods and settings, which makes it easy to add them into forms.

This shot shows you the textbase explorer and maintenance for photo show. With the list on the left you can search cars from the base. You can search, move, copy and delete blocks from the base. You can drag-n-drop file names from all three explorers to the text area.

Text  base can have multiple blocks with the same key. All fields inside the  block are optional. There is utility which scrolls  the base and creates a list from used field names. Pic is needed for getting the photo into slide show. Other fields are more or less informative for the photo show. The names of header, disk-file and description fields are given in settings.

In car show blocks are made so, that each blocks has all photos from one model / year. The first listed file comes to general show, others come to secondary thumbnail line. Secondary line changes every time you choose new photo for the display. The new entry begins with either Hdr-field or null line. Null line entry inherits entries from previous entry.

Header have make and model names in computer compatible format, Hdr field has the name in user format. Computer format needs special marker chars for separating makes, models and years. In header you usually separate variant names with comma. 

In 2011 there was lots of marginal cars available. The total number of marginal models often exceeds the number of best selling models. SUV and Space car is expensive to buy ... must admit that ... but the overall sales numbers are modest. Competition from the buyers is tough. Reasonably priced 4 door family cars are the most popular cars in the world.

Spell checker needs field names. Spell checker checks the field names. Hdr can have car make-model list which is used for checking the line. Dsc goes with common text check. Skeleton for file name can be checked for the exiting files, and so on.

COMMENTS

JPEG files comment system turned out to be very messy. You can embed textBase data into files' comment sections ( if format supports comment sections ). Entries are stored just like they are in the base. Property sheet reads the comment section, processes line breakers + tabs and shows the comment.

The comment header record has
- 32 bit size.
- 16 bit code page.  Standard code pages misses UTF-8,  Unicode is 1200, UTF-8 could be 1210. The code pages ends to 10081. There are room for two attributes. Attribute 16 384 goes to reversed byte order. Attribute 32 768 adds UTF+ feature into ansi, etc. code pages.
- 8-bit-attribute :  64 = HTML tags, 128 = HTML chars. HTML chars attribute checks and converts &euro; and others into characters. HTML tags attribute skips over <> areas. Processing of the format commands is optional. Scripts and others are ignored.
- 5 char ( 40 bit ) html-language code : en-us, de, etc.

After this 96 bit / 12 byte header comes the the data. The file data does not need block header and file name.

UTF+

Media player gets UTF+ system, my old development from the year X :
- UTF+ indicator is Char-215. When string processor discovers chr-215, the next two bytes defines the char. The last two bytes are mapped as unpacked 16-bit wide chars. The other chars are processed with current code page. UTF+ allows you to add random wide chars into your document.
- Code page indicator is character 247. When string processor discovers chr-247, the next byte defines new code page for the text. There are less than 64 code pages, they are clamped down with constants. Reversed byte order attribute is 64. All three encoding systems keeps the first 7-bits unchanged.

- Control chars for UTF+ are subject to change. In Control chars, characters 14 and 15 are code page related. Nowadays chars 0, 8,9,10, 12, 13 and 27  are used. Chars 28-31 has no usage. They can be used as unique list separators and brackets. 

- You can embed 8-bit, UTF-8 and Unicode chars and sections into your documents.
- In UTF-8 and Unicode you make page change with the same chars, not the numbers. The system keeps the char / code page markers in blind charter conversions. Blind conversion will alter characters.

In mixed usage, you have to waste one char for indicating the change. There aren't any unused bits, you could use as indicator. Chr-215 is "never used / processed" multiply sign. Chr 247 is "never used / processed" division sign. In complete implementation these two chars always need a special handler. With these indicators common text is almost 100% compatible with UTF+ formatted text.

Possible that there would be slower UTF-h system, where you use characters and end marker for special chars and code pages. System which is almost equal to HTML system. "&" with what you begin HTML definition would be replaced with special char. Could for example use ctrl or alt for entering new chars from keyboard

UTF+ needs a simple loop for calculating character lengths. Windows character conversion routines have flags for UTF-7 and UTF-8 conversion. Code page is missing.

Media player will get a keyboard interface, which sends the current layout to keyboard. Electric or touch screen keyboard can change the displayed key values so, that they match to current layout. Handy feature when you have special fonts, with non-standard glyphs. There are many nice / useful fonts, which are not used, because you cannot see the glyphs. There are many fonts to for example writing mathematical formulas. Quite a many from math symbols are already hidden into common font definitions. They do not have keys in keyboards.

Wide and multibyte characters in Asian sign languages

Asian languages have also 8 bit code pages. Asian writing goes so, that caret moves only with selected keys. The keyboards have signs, with what you draw the words. After you are finished with the word, you move the caret and start to build the next word. Sign languages have simplified scripts, which were made for type writers, and are nowadays used in computers. Type writer was a dummy machine, you could change the chars and keep the writer in one place. If you take a look at the Asian fonts, the available chars fits into 8 bit extra space.

The caret movement is embedded into font files and keyboard layouts.

In sign languages vertical text goes from right to left, horizontal from left to right.

- - - -

Unicode didn't give much for the Asian sign languages. The signs got new unique numbers, just like with other chars. Asian sign script is not very different from others. Glyphs with what you form syllables and words are like alphabet in western world. The number of glyphs with what you form the signs, is at the same levels with character scripts. In sign language you enter more than one characters into same character cell. Chinese, Japanese, Korean languages has  as many words as western languages. It means, that signs for whole language exceed wide-chars capacity. 

When you use packed DBCS character sets, you have to enter the signs in predefined order. Keyboard handlers does not sort entered dead-chars. In MBCS, where each sign has it's own char, the order is free. Media player can add dead char sort routines to keyboard drivers. When you sort the chars in byte order, common search functions - like InStrS - works with sign language. MBSC is easier to user. MBSC allows you to use non forwarding chars, which triggers key events, but the char has non-forwarding bit set.

Can use the same system with general usage western signs, so that you can see the non-forwarding character right after key press. The dead key handler gets messed rather easily. After few copies and deletes around entered dead key, which misses the second key, the handler does not know a thing from the intended character-key value.

HD unit output

When you take the output from HD as events, you get variant record to your event handler. Hybrid can contain files, directories, volumes and network drives. There are variants for 8 bit Ansi and 16 Unicode names.

The record on the right is the one you get into custom handler for FilesToStrings function. It is compatible with  Windows FindNextFile record. FilesToStrings uses the record in FindNextFile calls.

A call to FindVol fills the record with Volume data. It sets drive attribute on ( 8 in Att variable )

The network inquiry is not yet ready. But the volume variants have enough space for holding longer network drive names and definitions. Network drive name can be 80 characters long.

After Fat data there are variables which are used by integrated display components. At position 578 you find holder for Data-Itemdata-Pointer-Object variable in common listbox, treeview and listview components. Treeview component in the pictures above is powered with my old HD-unit, which uses rec32fnd record. Grids uses new unit.

You can enlarge the small picture with a click.

FilesToStrings only searches and selects files. Files come in the order they are on the disk.

From HD unit you get sorted lists. HD unit uses files to strings with event handler. SortU32 for sort.

In handler it moves and converts rec32fnd record into recU32 variant record. In media player, you usually play and program with U32. U32 uses variable length strings for storing the names. Empty U32 record reserves little over 100 bytes. Used around 200 bytes. Empty rec32fnd reserves almost 600 bytes. Fixed length char array belongs to history.

HD opens files and fills the contents of U32 structure by demand. There are / will be variants for pictures, sounds, videos, directories, etc.  U32 is also the base structure for the new file packs. The current U32 record is under development, it has basics for photos and packer.

Variant part begins with fixed sector. Fixed sector has data which is common to all variants. In alternative variants, the fixed part is covered with dummy filler arrays. In variants there are variables for files / volumes. Few variables for converted values. Few alternative data type definitions for the variable. In the sample picture constant u32_Fixed = 80.

You can get the file type from Exe or Ext variables. Fixed part has thumbnail data. Sounds and books use cover pictures in thumbnails.

HD unit uses indexed sorts. It uses arrays, which refers to U32 array. Sorting does not change the contents or physical locations of the U32 array. New filter or sort order does not require iteration of the hard disks. When you request a new sort order, the system uses the old order as base order for new sort. When files are in alphabetical order, after a request to sort files with archive attribute, files keeps the alphabetical order within both groups.

U32 array and index are declared as public. You have direct access to the array from anywhere. If you mess them, you have to clean your programs from the bugs.

Index is declared as pointer, which has an array mask for making indexed access possible. Masked pointer is common in Delphi / Pascal. It allows you to access the array with common Do and For loops. Then it allows you to insert and delete entries with only one move command. When array has variable length strings, masked pointer array is usually the only one, which does not crash.

Record variants are handled by compiler, in executables their usage never results into performance penalty.

FAT-32

FAT-32 file name uses always 260 characters. Media player could strip the name into standard 256 characters, use one character for the remaining for defining the file type. S - Sound, V - Video, P - Picture, D - Document, T - Text. Then there could be characters for executables, dll libraries, application files, text formatted setting files, temporal files. Another could be used for back up cycling. There are three base types of back ups, system back up is made after installation of the new program. New content back ups are made every now and then.  Creative-business backup is made on daily basis.

You can never use the last characters from the FAT-32 name. C-language programs - like Windows - uses 260 character long memory blocks for the filename with full path. The maximum safe file name length is always 260 - path length. When you try rename file with my computer, you get an error message, if the total length exceeds 260 chars.

Einstein and computers

If you do not know or remember around 15 years ago, at around 2005, fiber networks boomed. Due to Einstein, fiber cables were believed to an awful lot faster than electric cable. Companies and various institutes spent billions into fiber / light wave networks. Recommended then, that you should stay with cheaper copper cables. Reason was that they cost a lot and  conversions from electricity to light and back takes too much time. You can build A/C networks, whose data transfer capacity per second is at ten least times bigger than with current D/C network. You can for example feed all 32-bits to 32 bit CPU with one wire and one "pulse". You can build systems, whose external speed raises to over 1 GHz.

When media player gets upgrades, you use hard-disk network like system. You build small tech-detectors behind standard connectors. New tech must support old tech. Current USB connector, which supports old com devices, like mouse, keyboard and printer, must always have support for variable connection speeds. Not very clear why they created new connector for USB-3. Cannot see much sense in such.

Installation of the applications

In media player, you make installations under one root folder. Idea is that you can simply drop and delete applications. You do not use system for installation. If you for example use DLL's, you put them into same directory with exe-file. Shared DLL's are from the time, when computers were short on hard disk space. Media player applications are small, when compared to sound, video and picture files. You can use shared settings just like before. File extension lists and shortcuts for launching the application are the only required system level things. Media Player obviously uses simple ini files for these two. In multi user environment you can use [shared] and [username] sections for custom launch systems. 

Physical desktop directory could be OS volumes root directory, in desktop view you do not show startup files. My documents should be capable of floating over volumes. Media player has almost always more than one physical hard disk.

Media Player file explorer will get cross volume views. They are made with compiled file lists. File explorer can build the view with file list. The file list can contain files, directories, and other file lists. The lines can have wildcards. You can for example have a DVD view, which is constructed from multiple volumes. The contents of the view is dependent on the hard disks which are currently present. Explorer has also a chance to display contents from the volumes which are not present. These lists are built when disk is attached to player. The contents is iterated and stored onto local disk.  You can build these lists also from the back ups, you have burned to CD.

If you have for example Romantic Comedies on multiple volumes, the explorer can collect files with same directory / root directory together. So that all your Romantic Comedies are under the same Romantic Comedies root in the view. Path is always stored with shown files, it does not matter where the shown file is.

Basic demand for simple creation of the shared view is that, you have some kind of standard for naming directories. By default root is the first subdirectory after the path definition. Without standard all directories must be listed independently, with root parameter. Root uses the last given subdirectory as root. 

E:\Movies\Romantic Comedies
E:\Movies\Action Scifi

F:\Romantic Comedies
F:\Action Scifi

Will do :

E:\Movies\
F:\

E:\Movies\Romantic Comedies
E:\Movies\Action Scifi

F:\Romantic Comedies
F:\My Movies \ Action Scifi

Will fail. / Is not simple :

E:\Movies\
F:\Romantic Comedies\ /r
F:\My Movies\Action Scifi\ /r

Memory management needs a chance to reserve shared memory. So that you can make the application from multiple exe-files. Use the executables much like units. Currently chance to synchronize applications is exclusive to Microsoft / OS manufacturer. Both offered ways - File Mapping and DDE - are slow, clumsy and they do not work very well. Memory manager can check and prevent calls to the same segment at the same time. In applications you can use the shared memory without troubles. 

In Media Player the basic need for shared memory comes from hardware. Video and music player usually needs to check running copies from the application and lead the opening to the running executable. In a shift you got to pass new filename and command line parameters to running copy. Difficult thing to do without shared memory and with existing operating systems. Hardware is shared resource, in principle you can run one hardware oriented program copy at the time. Communication with hardware takes place with global functions, it sets the one-copy at the time demand for the player programs. 3D games have also similar kind of "one-copy-at-the-time" demand. When you limit the number of copies to one, the program and programming job are quite a lot simpler.

Drag drop should be extended to multiple executables, to a clipboard like system. In photo show maintenance you can already drag and drop text from one window to another. Maintenance has clipboard like format system for dragging. In media player users drags file names into playlists. Playlist editors / maintenances need standards for dragging and dropping.

- - HTML bills - -

With TWebBrowser component it is easy to build custom HTML bills. First you build layout for bill with HTML. Then you add id's for receiver, sender, date, etc. Then you update the ids with program. Finally you copy the document from browser and save it to file. Easy to add comments, special terms, etc to selected bills. You can see the bill all the time. Handy system, when you for example write bills at the same time with purchase. Quite a lot easier than R&D billing. R&D billing uses ID-extractor and less flexible writing system. 

DHTML-4 plus obviously gets a chance to print the modified document and copy the document as whole.

HTML bill-vouchers needs standard names for the ids. So that you can handle the bills programmatically. When you get a bill from vendor, you can add the bill automatically into system with ids. You can use vendor name/id and vendors bill number for searching the match from existing bills and vendor base.

Then you can create electric acceptance system for the vendor bills. The person who accepts / rejects vendor bills reviews the bill on screen, accepts / rejects it after reviewing the bill. He-she can also write the reason for the rejection and instructions for actions to the bill. The reason and instructions follows the bill ever since. Kids play with HTML bills.

With HTML bills you can get orders, bills, payments, deals, for one delivery onto one screen / display. Everything around the delivery can be brought to your screen with one request-click. Currently such needs paper works and usage of the printer ... request to secretary / financial department.

Then you can create electric graphs and statistics with HTML. Presentations from monthly, quarterly and yearly reports are easy and easy to access. You can add a spreadsheet calculation to HTML document with copy and paste. Same goes to dataBase tables and queries. Graph comes usually as image. Think that Ms Front Page is still the only proper HTML authoring program. In electric usage HTML is always better than other formats. It is designed for screening, not for printing like others. It supports events, animations, positioning, run-time font-color-content changes, scaling, etc. If it does not have the required feature, you can almost always make it with scripts. Supports also paper prints. Collection routines for the reports can be executed and reviewed at anytime.

You can make custom browsers for viewing html bills and documents. You can for example add database search system onto same screen with html viewer. Drop web related menus and panels from the form. Possible to create ( remote controlled ) full screen viewer, without scrollbars, borders and others. ATS games will get a help system, with custom web-browser form.

HTML bill replaces paper copies, you archive all printed HTML bills and vouchers from payments. When customer for example calls and complains, you can get the copy from the sent bill to your screen. When you send electric bills, it seems, that you do not usually have copies from the sent bills. The current status of the bill changes all the time. Paper copies must be searched from the archives. Optical archive from HTML bills saves space, you do not need big storages for the bills. You can store the copies from bills into fireproof safety deposit boxes. You can keep more than one copy from the bills and other essential documents. If you do not remember, there is nowadays a way to literally sign the electric documents. The signature stored and saved as bitmap. You can never alter the contents of an optical disc.

HTML bill allows you to print the bill or send it via network. For your own system the delivery method is insignificant.

Real time and collection systems for financial-business dataBases get usually popular amongst users. Although they didn't know to ask the features. With Queries and HTML forms such things are relatively easy to construct. Difficulty and time it takes to construct the screen and layout, does not prevent you from making special presentations. 

Next generation web will make all these things possible. It is an A/C network, capacity-speed is at least 10 times bigger than now. Then there will be safe channels for mail and money related things. On the main page there are talks about closely related personal finance system.

- - Closing statement - -

Most from the most popular Windows programs are nowadays written with Delphi and Pascal. All Windows API functions have Delphi declaration units, which are freely available. Delphi is 2nd native Object Oriented programming language. Visual Basic was first. These two dominates Windows programming. 

Most DHTML scripts are written with Java Script. Java Script is supported by Linux-Unix and bigger computers. Basic script is quarantined to work with Windows browsers only. MS DHTML-4 implementation supports almost everything from DHTML-4 definitions. When you write scripts for media player, you got to have a ms-dhtml-4 based browser. After script gets more complicated, others start to fail. The documentation for Ms-Dhtml-4 is not a 100% match for the implementation. There are things which works in wider than documented scale. Then there are things which are said to work, but they don't-

With Delphi and others you can build your own Windows browser for MS-DHTML-4 interface. Most from Ms-internet explorer is made over MS-DHTML-4 interface. WebBrowser component in Delphi does not do a thing without programming. It provides methods and properties for building the actual browser. If I do not remember wrong MS got the DHTML-4 interface from US universities. Also the reason why you can never ask money from web-browser. There will be limitations for accessing web with self made browser, by default it is forbidden. You need some kind of permission to build actual browsers to media player.

When all media player apparatuses have browsers with the same Ms-Dhtml-4 interface, you do not have pay attention to compatibility issues. All scripts and elements have one standard behavior. In media player album, book and DVD covers are expensive artworks. Covers and digital boxes are made with HTML, they must have the same, intended looks in all apparatuses.

If media player gets web, you are never allowed to break the general rules with your programs. Basic demand is that the source for the application is freely available, your Chormes and Firefoxes will be compiled every now and then. Checked for perfect match.  Then there will be some other communication and file usage tests, your executables must pass. Not very interested in web. It has turned out be a commercial failure, a place where copyright violations, frauds, spying, extortion and terrorism belong to "legalized" things and everyday stuff.