Názory k článku PC FAND: historie slavné české databáze z 90. let, která nepřežila nástup SQL

PC Fand me nejak minul. Jak moc se to lisi od databazi te doby, jako je DBase nebo FoxPro?

S PC Fandem jsem se setkával pravidelně. Otec byl/je malý živnostník a koupil si na účetnictví Účto tuším 92 (to číslo je pro který účetní rok je daná verze určena). A protože s PC moc neuměl, musel jsem se to nejdříve naučit ovládat já 15tiletý nadšenec do počítačů a pak to naučit tátu.

Byl to mix databáze a uživatelského rozhraní. Dalo se tam velmi snadno vytvořit tabulky, vazby mezi nimi a současně to mělo editor textového rozhraní. Člověk si dosti snadno mohl tvořit jak vypadaly jednotlivé obrazovky - formuláře a jak je vyplňovat. Navíc obrazovka měla fixně 80x25 znaků bez možnosti změny velikosti a poměru. Opravdu na to nemusel být člověk programátor. A dokumentace v češtině, to také byla velká výhoda.

Z dnešního pohledu to byl velmi strohý a vzhledově ošklivý systém. Navíc začínal v době, kdy myš nebyla úplně běžný kus HW, takže tam byl důraz na klávesové zkratky a přeskakování mezi políčky a formuláři tabem a enterem. Na první potkání ne úplně pohodlné, ale na druhou stranu s aplikacemi z PC Fandu pak pracovali většinou lidi dlouhodobě - účetní, skladníci, lékaři, pokladní v ČD... A tam se toto čistě klávesové ovládání naopak ukazuje velkou výhodou. Děláte neustále opakované akce, zápisy do stále stejných formulářů a polí. Za pár dní prostě víte, že z tohohle pole 4x tab jste v poli které potřebujete. A další 2 entery a jste zase jinde kde potřebujete. Myš jen zdržuje a riskujete přehmat do jiné buňky. Takže ve výsledku to možná není tak hezké na první pohled, ale velmi ergonomické pro každodenní profesionální používání.

A bylo to rychlé a nenáročné na zdroje, což ve své době bylo velice důležité. Nevýhodou byly netriviální problémy s tiskárnami a kódováním češtiny - ale to bylo v DOSu obecně normální. To vyřešil až nástup unicode a PS/PDF tisk o mnoho, mnoho a mnoho let později.

Mám za to, že lékař ke keterému chodím má v PC Fandu evidednci pacientů a chorobopis do dnes. Alespoň mi to tak připadá, když mu vidím přes rameno jak vypadá ta obrazovka a jak se tam pohybuje mezi buňkama. A dost možná i ČD mají pokladní systém v PC Fandu, když u okénka kupuji jízdenku, tak ta obrazovka přes kterou pokladní datluje kam chci jet vypadá přesně jak z PC Fandu.

Muze to byt jeste FoxPro. Ve skole jsme pouzivali FoxPro a doma jsem mel PC-Fand. Vypadalo to dost podobne, akorat v PC Fandu jsem mel vzdy vsechno rychleji vytvorene. Nekdy i dvakrat rychleji nez ve FoxPro ...

Problém Windows je, že se mezi políčky přeskakuje pomocí Tab a ne Enter. Kdysi se ženská vzala do levé ruky výkaz a všechny mzdové položky vyťukala pravou rukou na numerické klávesnici.

Myslím že váš lékař by mohl používat poměrně rozšířený AMIS_H od ICZ. Ten používá jako databázi informix a celý je napsán v 4gl.

U pred predosleho zamestnavatela nad tym 4GL+informix pisali nemocnicny system. Ficali na tom fakultne nemocnice na vychode. Kupodivu bol funkcny, ale programatori dost drzkovali ale uz nepametam na co presne :-) V case ked som odchadzal tak sa uvazovalo o portovani na Linux. (Rok 97)

V Informixu bylo minimálně ve státním sektoru 4GL aplikací dost - "datově ex STB" EZO a RAP už u federální BIS někdy v 90-tkách - na PC 386/486 EISA bus serverech Wyse, občanky a registr vozidel u Policie (taky Wyse, něco SCO, evidence obyvatel možná Solaris - nevím jistě, ale v chodu jsem to viděl ještě okolo 2009), pro radnice na SCO a pak Linuxu Vera radnice, určitě nějaké nemocnice (ve fakultce Hradec Králové jsem ten terminál viděl cca před 3 lety) , tuším i Baumax na začátku (90-ky) u nás měl v hobbymarketech terminály a v kukani za vchodem Dell PowerEdge ...

V PC FANDu byly napsány docela rozšířené aplikace pro privátní lékaře, zubaře a lékárny. I když jejich autoři dnes nabízejí jejich win-verze, mnozí uživatelé stále dávají přednost DOS - FAND verzi, provozované třeba pod VDosem. Kde kupodivu docela dobře jde i tisk z FANDu bez nějakých pomocných tiskových manažerů. Pod FANDem jsou vyřešeny i věci kolem EET, . .. .aby staré aplikace jely dál a jedou.

Na první program ve FoxPRo nebo DBase jsi musel mít o těch systémech nějaké znalosti. V PC Fandu jsi mohl začít z nuly a postupně program rozšiřovat. Např. Napsal jsi v tom jejich texťáku strukturu datové tabulky i s klíči a index, zmáčknul F9 a objevil se nějaký automatický, plně funkční formulář, ve kterém jsi mohl editovat, přidávat i mazat. Pak sis mohl ten formulář dodělat pořádně, přidat k tomu nějaký kod atd.

taky jsem se k tomu nejak nedostal ...
nejdriv Redap (relacni databazovy procesor - cca 1984) a pak na PC se uz valilo FoxPro ...
pak jsem zachytil jeste neco izraelskeho (delaly se v tom velice zajimave veci, od ucetnictvi, az po sledovani udrzby techniky), ale nazev si uz nepamatuji, ale bylo to hodne ohebne a univerzalni

Tuším se to jmenovalo Magic. Testovali jsme to v rámci zkoumání možností přechodu z Foxpro na něco lepšího.

Tak tak, ve FANDu a MAGICu jsme dělali pěkné věci...

Magic používal jako úložiště BTree od Nowell. Tenkrát jsem to z demo verze vypreparoval a jel jsem v tom v Turbo Pascalu, protože jinak se k tomu dostat nedalo (nebyl Internet)

Oprava, BTrieve

Jj. Magic byl hezkej. Jen bylo potřeba se u toho naučit trochu jinak myslet a pak šlo udělat velmi rychle a jednoduše dost slušný věci. Dělal jsem v tom diplomku. Chtělo to ale hardwarové klíče pro ostrý provoz. Než mi poslali testovací SW klíč tak utekl téměř všechen čas co jsem na tu práci měl takže jsem téměř vše dělal ve škole namísto na kolejích. Udělali i Windows verzi, ale to nebylo ono :-(

Jo, Redap, ten žije pořád, přeportovaný do win32/64 verze. Dokonce bych řekl, že programovat v tom šlo svižněji než ve Fandu, myšlenka řekni co chceš udělat a nestarej se jak se to dělá.
Příkaz jako třeba: zuz zdroj|cil|jmeno tomas ;|datum=4.5.2018|//
znamenající z tabulky zdroj do tabulky cil překopíruj věty, kde je jmeno tomas a nastav datum na 4.5.2018 oproti tehdejším dostupným jazykům, kde se řešilo otevření souboru, načtení n-té věty, testování, kopie, ukládání, uzavření souboru, bylo něco co práci opravdu urychlilo.
Oproti Fandu měl smůlu v tom, že v něm nevznikla žádná všeobecně známá aplikace jako Účto TichýJežek a také to, že autor je víc programátor než obchodník.
Ale krom portace pod Windows to dnes umí cizí databáze přes ODBC, komunikovat přes ftp(s) http(s), vytvářet PDF, pracovat s JPG, XML, šifrování, podepisování a netuším co ještě dalšího. Přičemž by na tom možná běžely i původní programy z SM-4/20.
Pan autor je už v důchodu, ale pořád se v to, rýpe, koukám na jeho stránky, kde třeba aktuálně řeší nějaké to podepisování a šifrování. http://www.redap.cz

Tento rok to uz snad konecne cele pochovame :). Ak by som neignoroval poziadavky zakaznika a nehrozila prisnejsia legislativa, tak to pobezi este nejaky ten rok.

V REDAPu je uděláno účetnictví EkoSoft, které je stále aktivně vyvíjené a udržováné a stále jej využívá hodně desítek firem. Dále vím ještě o několika menších, stále používaných, projektech v REDAPu, ale ty spíše rychle dožívají.

Jo pánové,
to byla skutečně revoluce. A nezmíněný aspekt - úspora dat na diskovém médiu. Uvědomte si, že se běžně zapisovalo na 8" diskety - kapacita 360KB. (později na 3.5" - tedy kapacita 1.44 MB). A to jste tam museli dostat operační systém + program + data. Konkurence - dBase II - ukecaná a po neočekávaném vypnutí - konzistence dat byla v háji. (tedy nutnost specialisty a reindexace).
Ještě v době SQL jsem hledal, jestli tvůrci nechtějí portovat Fand na Linux. Na ty různé "telefonní seznamy" je to plně postačující. I dneska. Kouzlo uživatelských formulářů a reportů jsem ještě pořád v něčem kompaktním nenašel.

To nevím cos měl za prasečinu, já mam 20 let IS ve FANDU a za těch 20 let se mi nezbořil jedinej soubor :D

8" diskety 128kB nebo 256kB používány u 8-bitových počítačů
5 1/4" disketa kapacita 360kB nebo 1,2MB
3,5" disketa 720kB nebo 1,44MB

Kupodivu se v diskuzi nikde neobjevila zmínka o poněkud svérázné "odrůdě" počítačů značky Robotron. U těch se diskety 8" (u novějšího typu R1715 byly i 5 1/4" a 3,5") používaly a kromě původního OS a programovacího nástroje výrobcem označovaném jako makro-assembler, nadšenci implementovali OS CP/M a pod ním PC Fand fungoval.

Nezbývá mi než souhlasit s jiným příspěvkem v této diskuzi, že programátor v PC Fandu si těžko zvykal na jiná vývojová prostředí, protože jednoduchost a přímočarost řešení ve Fandu jinde neexistovala

rychlá závislost; aboslutní; ... kolem 1991-3 jsem ve FANDu planoval udelat klientske terminaly v nemocnici, pouze takovy rychlejsi frontend (dnes by se reklo mobilni appka/sqlite na rest api), kde terminaly mely ukladat spolecne synchronne do jedne tabulky requesty (ja tomu rikal command) a aplikacni server (delphi 1.0 + interbase; jeste mam doma i krabici) mel vracet kazdemu terminalu do jeho vlastni nesdilene databaze ulozene na sprostem LAN serveru data (messages) na bazi commandu (nic vic, pouze tento pattern, byl rok 1993 a internet jeste nikde ...) - defacto neco jako komplexni rest api response graf. FAND mel deklarativni model s funkcionalnima kalkulovanejma polozkama nad kteryma take automaticky indexoval, pokud mel nadeklarovano - jadro logiky mohlo byt klidne skoro cele v modelech tabulek (F), kde byla take nadeklarovana logika relaci N:1, 1:N atd - sql tam sice nebylo, ale pro zpracovani batch dotazu/updatu se defacto pouzivaly "streamy s eventy", rikalo se tomu "merge" (uz na CP/M kvuli minimalni spotrebe pameti a krmeni hromadou dat z pasek/winchesteru) a tusim az 10 tabulek/streamu mohlo vstupovat podle indexu do procesu s deklarovanymi eventy pri zmenach hodnot, kdy bylo mozne na vystupu generovat nekolik vystupnich temporary tabulek (preddeklarovanych jako modely) a takhle si vytvaret davkove mezivysledky/sta­tistiky/analy­zy resp. jejich normalizovane ci denormalizovane podklady - na modelu bylo bezne pouze par polozek fyzicky ulozenych a vetsina polozek "computed" (vcetne linkovani pres relace do ciselniku) - z puvodne 1.NF relacniho modelu dat v tabulkach tak bylo klidne nekdy primo videt do denormalizovaneho pohledu na celou databazi z mnoha ruznych perpektiv, podle toho jaky model byl vychozi - no a nad tim pak byly primitivni flat formulare/views pro eitaci (defacto fakt primitivni templates spis, bez jakekoliv logiky) a sestavy/reporty, coz byla takova kombinace views/templates a merge streamingu s tim ze vstup byl vetsinou 1 denormalizovany stream a vystup pak event based template (detail, head/foot levels by keys...) Typicke programovani (spis skriptovani spousteni generickych ci templated editoru a generatoru sestav pres menu, tot vse) se delo v interpretovanem omezenem pascalu. Ja jsem si tedy tenkrat udelal takovou strukturu projektu pro ty "chytre/stihle" klienty nemocnicniho IS, ze jsem tam v podstate udelal event/state-based "controllery", prave jeden pro kazdy model, s ruznymi views/reports - ... ale na IS uz nedoslo, rozpadal se OUNZ kolem 1993 a bylo najednou na 2 roky prace az nad hlavu se zavadenim mezd a ucetnictvi (VEMA) a skoleni business crowd :-D ... nicmene ovsem ale jeste snad 10 let se tam pak ve FANDa a Paradoxu delal postprocesing uzaverek pojistoven, analyzy, statistiky, etc ... PROČ? simply easy instant changes ... no jak povida pan Klotzer ... defacto dnes ReactJS a par technologii za tim ... (art.sy stack cca? GraphQL, Apollo, ... jo, ted jsem koukal na videa, vcera se vratil ze skoleni... tak neco to bude konecne podobneho mindsetem.... konecne to ti mladaci spichli poradne mozna :-D ... doufam ze tihle nebudou agresivne namachrovane tlacit nejaky rigidni scientologicky procesy a scrumy a kanbany a tak,. ... u facebooku prej je to jinak, the hacker way (tnx Erik) ... well done, ok! :-)

Zdravím, Fand ve své účetní praxi stále nezastupitelně používám, takže bych přivítal možnost konzultovat některé programátorské oříšky. Rád za pomoc zaplatím. Pokud byste měl zájem, jednadve@post.cz :-)

Mliko po brade?
Levna pecka a pecka v dobe predHDDckove se vyznacovala tim ze mela dve 5.25 mechaniky, pozdeji suprdupr hifi 3.5ku. Tj. OS se natahoval z jedne mechaniky a pracovalo se na druhe. V ruznych kombinacich. Fakt neznam nikoho kdo u PC bez hdd pouzival jen jednu disketu.
8 palcovky udajne pro PC existovaly jako externi zarizeni. Jinak bezne byly k videni u vetsich pocitacu a prvnich 8mi bitu. Velmi brzo se preslo na mensi format protoze vyroba 8 palcovych mechanik byla materialove velmi draha vzhledem k nizke ulozne kapacite a diky pokroku v magnetickem zaznamu(male hlavy a magneticka vrstva) to byl i ekonomicky nesmysl.

Já mel Commodore PC 1, ten mel jen jednu mechaniku,, musel jsem je furt prehazovat.

http://mmm.webz.cz/commodore/cpc1.html

Jo, to je ono. To jsem byl ještě mladý.

Je tam chyba, ta disketová mechanika byla 360 kB

"Tj. OS se natahoval z jedne mechaniky a pracovalo se na druhe. ... Fakt neznam nikoho kdo u PC bez hdd pouzival jen jednu disketu."

Frajeři nabootovali z diskety, přičemž vytvořili RAM disk a do něj nakopírovali COMMAND.COM, případně plus pár "externích příkazů". Pak vystačili i s jednou disketovou mechanikou; pokud měli dvě, pak pro sebe.

Jo a ještě pamatuji nějaké prográmky pro formátování které umožnili naformátovat diskety na větší než standardní velikosti

Dekuji za clanek, vzpominam s nostalgii. Na svou dobu to byl genialni produkt.

je ještě dnes; nic podobně instatního pro adhoc analýzu relativně obrovských dat jsem zatím neviděl; možná nějaký ML editory něco takového umí (a ještě víc), ale prostě ... ono se to ani nedá googlit, není to s ničím srovnatelný, dodnes, vůbec ... (max co se podobalo za ta léta a co jsem v šoku našel bylo "suneido" (objevil jsem nahodou cca 2004, malinkatý, ale bez jakykoliv security a scripty maji pristup na komplet win32, masakr) a MS LightSwitch, (na chvili, cca 2012, nadějný, ale obrovský a rychle pohřbený, byl v tom Silverlight jako UI renderer, MVVM observables etc...)

dneska je FAND možná nejvíc podobný právě kombinaci objektove/fun­kcionalnimu programovani nad velkymi streamy dat/eventů s immutable views, to cele slepene TypeScriptem; opravdu nejblize to vypada na React/GraphQL a tyhle veci, samozrejme vsechno brat s rezervou a obrazne, FAND se vesel na 1 malou disketu a tenkrat se poprve objevly objekty v TurboPascalu 6... mam pocit, ze se v tom tenkrat skutecne daly napsat veci s produktivitou tak 10-20x vetsi nez DBase/FoxPro urcite, vetsinou jednomuzne bez problemu zvladnutelny (prehled na projektem, pouze byznys logika, ostatni veci trivialni), cokoliv kompilovanyho jako C++/Pascal absolutne bez sance pro jednomuznou zivnost (jako "line-of-byznys" aplikace teda), to je jasny

> Produkt tohoto zaměření a rozsahu hodně chybí.
Mozete to rozviest a prezradit mi co konkretna vam chyba? Tak ako je neskor v clanku naznacene dnesne moznosti pre vyvojarov su uplne niekde inde.

Na rychle pisanie aplikacii bol celkom zaujimavy Lotus/IBM Notes/Domino. Dnes sa uz tomu nevenujem, ale pred asi 20 rokmi som parkrat predvadzal nazivo na konferencii (casovy limit asi 1 hodina) vyvoj jednoduchej aplikacie na skladovu evidenciu. Dominino/Notes umoznoval vyvoj len "klikanim" bez nutnosti znalosti programovania (ale dalo sa aj programovat v LotusScripte - nieco ako VisualBasic alebo v Jave) a aplikacia bola pristupna alebo cez Notes klienta alebo s urcitou limitaciu funkcii aj cez web. Na svoju dobu to malo aj celkom slusne riesenu bezpecnost, Lotus databaza sa dala zasifrovat a uzivatel pouzival na pristup subor s klucom zasifrovany heslom.

Tohle ale není žádná historie.. tohle se produkčně pořád jede i ve velkých korporacích :)

Ano viem.
Ja som ale s Domino/Notes skoncil niekde pri verzii 6 :-)

Kvoli Notes IBM kupila firmu Lotus.

A co třeba Kexi?

V grafice je dostupný třeba Kexi nebo OpenOffice Base

Tak ona je otázka, jestli se na jednoduchou tabulku/aplikaci do hodiny musí vyrábět formuláře abych mohl zadávat data, instalovat další soft atd. Na to bohatě stačí tabulkový procesor jako Calc/Excel, viděl jsem v tom i poměrně velké složitosti a pěkně graficky zpracované sestavy. Pokud to bylo složitější, hodně tabulek, relací, dotazů, nutnost formulářů atd, tak od Microsoftu je už 20+ let Access, v kterém doteď má několik menších firem co znám napsaný jejich "SAP".

Ano, na Linuxu je to horší, ale zase kolik firem reálně jede na Linuxu a z těch co jedou kolik jich potřebuje tuto věc, aby se takový produkt vyplatilo dělat. LO Base jsem zkoušel naposledy asi před 1-2 lety a i proti Access 2003 je to veliká slabota. Takže ono vyrobit něco takového asi není úplně jednoduché, případně i u projektu velikosti Libre na to není dost vývojářů, aby se to dotáhlo na 15 let starou verzi konkurence.
Reagoval jsem ale především na první odstavec, na jednoduchou tabulku lze s klidem použít ten Calc, sám v něm vystavuji fa nerozeznatelné od účetnictví s číselníkem klientů, nastavením, deníkem.. Kdykoliv si udělám na další záložce nějaký přehled, vyexportuji co chci kam chci, napojím na se ARES, udělám export pro poštu.. A hlavně s nějakou celkem jistotou, že tento produkt mi nikdo jen tak nezařízne. Kdybych chtěl (vzhledem k povaze dat nechci), mohu to dát ke Google nebo MS a mít to v cloudu bez starostí o zálohování a přístupné odkudkoliv a z čehokoliv (Linux, telefon, ..)

Tak neviem preco by som to mal robit pre textovy rezim ked tu mame webove rozhranie. A len tak pre priklad tu mate nieco v com si mozete obrazovky aj DB nadizajnovat nerobim reklamu ale myslim ze takych nastrojov je habakuk. https://www.smartclient.com/technology/visualbuilder.jsp

vyhoda je, ze ten textovy rezim je integrovany v tom servru, potrebujes jen putty a ssh.

Ten tvuj priklad take podle mne neni spravne, podobnych frameworku pro tlusteho clienta nenajds kopu, podle mne je smartclient ostatnim vzdalen o svetelne roky.

Ten visualbuilder neni free.

Podobně geniální jako PC FAND je Base z OpenOffice. programovat taky nemusíte, jen vhodně navrhnout tabulky. A dnes máte i toto https://www.obvibase.com/

Roky jsem to používal pro vlastní potřebu, koncepce je geniální, máte vše co potřebujete, tabulky a vztahy mezi nimi. A SQL k tomu. A StarBasic či Python.

jj, podle toho co jsem vsechno videl ted na skoleni kolem Reactu, tak by se dnes neco podobneho FANDu mohlo teoreticky nekde vyskytnout prave na bazi JS/TS, Reactu a vubec funkcionalnich veci na tohle navazanych (ale bude to masakr obrovsky veliky toolkit), jak to povida na konci interview ten pan Klotzer, ... kdysi jsem mu psal o lightswitch a suneido, chtel jsem taky udelat nejaky rozhovor, tak to koukam nekdo zvladnul, super, ja pak musel resit jiny veci bohuzel, jako obvykle :-/ snad se mu jeste dari dobre

Slza v oku.
PC FAND měl skvělou nápovědu - celé programování se dalo naučit z nápovědy :-)
Dodnes běhají některé úlohy, které jsem v něm před lety napsal...

Hned bych se k takovému programování vrátil.
q.

Zdravím, Fand ve své účetní praxi stále nezastupitelně používám, takže bych přivítal možnost konzultovat některé programátorské oříšky. Rád za pomoc zaplatím. Pokud byste měl zájem, jednadve@post.cz :-)

No, mrtvý :), vím o minimálně dvou firmách, které na PC FANDu tvoří dodnes aktuální účetnictví pro firmy :)

Účto jelo v 16tibitové emulaci windows a příchod 64bitových win10 přinesl problémy, protože ty nativně emulují jen 32bit, ale s pomocí nějakého klonu freedosu to provozují dál, asi až do skonání světa :)

Jj, chápu ... pokud se tenhle produkt otevře a někdo se toho chopí, mohlo by to být pro tyhle firmy zajímavé.

A navíc by to bylo po dvou tisících let další pěkně zdokumentované zmrtvýchvstání ;)

Znám jedno(typ programu v názvu + rok) a stále mě fascinuje to propracované ovládání klávesnicí. Na to co se tam dá udělat za pár úderů do klávesnice je potřeba* ve windowsovském účetnictví 5x přeběhnout mezi myší a klávesnicí.

*Asi to není nezbytné, ale lidi to k tomu ovládání myší nějak svádí.

Naprostý souhlas. Dosud jsem nenarazil na žádný systém daňové evidence který by účtu aspoň šahal po paty. Bohužel provozovat PC FAND/účto je, v dnešní době, už hodně velká křeč, zejména pokud to chcete ovládat z MAC OS někde na terminal serveru.

Je obrovská škoda že jak PC Fand, tak i s ním souvísející účto pomalu skončí v propadlišti dějin. Zase chápu, že se Alis musel začít věnovat něčemu jinému a PC Fand pohřbít. Navíc ono koketování s ODBC a s Javou bylo myslím totálně mimo, ale dnes je to snadné soudit.

No, mrtvý :), vím o minimálně dvou firmách, které na PC FANDu tvoří dodnes aktuální účetnictví pro firmy :)

No, já vím o dańovém poradci, který v tom dodnes jede prakticky komplet, naprogramoval si to včetně vytváření XML pro daňovou správu. :-)

Zdravím, Fand ve své účetní praxi stále nezastupitelně používám, takže bych přivítal možnost konzultovat některé programátorské oříšky. Nemohl byste mi, prosím poskytnout kontakt na pana daňového poradce? (jednadve@post.cz) :-))

Nejen FAND ale asi i jiné DOS aplikace dnes v pohodě jedou i pod win10 64bit pod tzv. VDOSem, který má celou řadu klonů. Např. z FANDu tam jde překvapivě dobře jedna stará bolest - tisk.

Používám Účto pod Linuxem už cca dvacet let, a běží báječně - konkrétně pod DOSEMU emulátorem.
A před cca třemi roky byla v DOSEMU přidaná podpora běhu v emulovaném virtuálním stroji - takže DOS aplikace pod 64-bit Linuchem (nebo pod 32-bit bez X86_LEGACY_VM86) jedou stejně rychle jako pod 32-bit Linuxem.
Paráda! Problém ovšem je řada widlous aplikací, kterými je Účto/FAND oplácán a jejichž interface je nedokumentovaný...

Super povidani, dekuju. Rozbehli se mi vzpominky na doby davne, lidi, co jsem leta nevidel a projekty, co jsou pryc.

Z nějakého nepochopitelného důvodu je vDosPlus jen pro Windows, takže no-go.

Tuhle vetu by mel nekdo hodne nahlas a casto cist tem autorum kteri v tech letech zamrzli a dodnes prodavaji a aktualizuji hruzy v textovem rezimu (vselijake sklady, jednoducha ucta,...): Navíc bylo čím dál tím víc zjevné, že trend budou udávat SQL servery a aplikace psané v obecných vývojových prostředích.

Neni nad to kdyz uzivatel potrebuje nove pc ale na starem ma v dnesni dobe podobnou aplikaci, kterou jeji autor porad udrzuje. Takze pri nakupu pc musite davat 32 bit windows (podle autora je to naprosto v poradku, protoze nove pc jsou zbytecne vykonne a uzivatele to nepotrebuji), pripadne instalovat dosbox, aplikace bezi v okne a nejde ji uz zvetsit (takze kdo hure vidi ma smulu), primy tisk na tiskarnu neexistuje (tiskne se do souboru a nejaky win program periodicky kontroluje adresar s vystupy a soubory posila na tiskarnu), automaticka komunikace s dalsimi aplikacemi nemozna (maximalne z takove hruzy vypadne html soubor nekam na disk), problemy s diakritikou (protoze dnesni tiskarny fakt neumi kameniky),... Nemluve o vykony file databaze proti jakemukoliv SQL pri pristupu vice jak 5 uzivatelu.

jake je to proti tomu pohoda nainstalovat normalni moderni aplikaci a normalne ji zacit pouzivat bez podobnych vyse popsanych blbosti...

Úplně s Tebou nesouhlasím..
Můj otec je jeden z těch daňových poradců, který v tom dodnes jede pro zákazníky daňovou evidenci.
V dosbox na win 7 64gbit,monitor 16:9 fullscreen sice orizla na 4:3 ale na celou obrazovku a tisk přes emulovany lot port pomocí net use.
Je to chvilka hraní, ale funguje to stabilně.

Ano, funguje to pak stabilne. ale kdyz to srovnam s beznymi sw ktere si sebou netahnou vazby z minulosti tak tam nic takoveho delat a resit nemusim - nainstaluju a vse funguje na prvni dobrou. Navic zakaznik sam zvladne udelat treba aktualizaci na novou verzi coz u tech starych veci zrovna moc neplati

Ono Účto v dosboxu jede taky na první dobrou. A hlavně ty to vidíš ze svého úhlu pohledu. Já jsem zároveň i uživatel a jednoznačně budu 10× rychlejší v účtu než např. v Pohodě. Přesně, jak se píše v článku, znám přesný počet úhozů Enterů, většinu dodavatelů a odběratelů podle kódu, stejně tak všechny kódy účetních případů. Takže doklady 1 firmy za celý rok nabouchám za 2 dny. A tiskové sestavy? Ty, co potřebuju opravdu pěkné, se vyexportují jako PDF, pro elektronickou komunikaci s FÚ a ČSSZ jako xml. A je to. Na tohle by měli vývojáři myslet v první řadě, že účtařina je jen otročina a rutinně se opakující činnost a tam rozhoduje efektivita práce a na krásu GUI se nehraje.

Souhlasim s tim a nechapu prilis, proc v Pohode (a dalsich) neresi u casto pouzivanych formularu aby uzivatel mohl efektivne pracovat pouze z klavesnice. Na druhou stranu aplikace ve FANDu jsou desive neefektivni (=pomale), hlavne kdyz jde o nejaky tisk, exporty, importy. Vyzkousejte si do Sterea naimportovat 20 ISDOC dokladu. Pohoda to ma za par vterin, Stereu to trva pres minutu. Nebo import nejake agendy, vetsi ucetni denik je treba i na 10 minut. Evidentne to vzniklo tou bastlici cestou kdy se na jadro FANDu naroubovaly Windowsi fce formou ruznych externich EXE apod. Dnes se mozna veci zmenily, ale to byl realny stav 4 roky zpet.

"jake je to proti tomu pohoda nainstalovat normalni moderni aplikaci a normalne ji zacit pouzivat bez podobnych vyse popsanych blbosti..."

tak presne takoveto trendy mysleni zenou veskere snahu o prenositelnou a deditelnou funkcnost pres generace HW, ci OS do horoucich pekel.

kamen urazu je v tom slovicku 'normalni'

dnes je 'normalni', ze ke dkejake jednoduche veci potrebuji sileny moloch, co bezi v posadi (hlalvne diky jave)
jde o to, ze se nerozlisuje, k cemu a komu ma aplikace slouzit - hele dame tam nejnovejsi JDK, k tomu nejake virtualy a knihovny od vymyslu sveta ...
pak se divime nad nenazranosti aplikaci, kdyz pomalu kazdy pulrok se musi delat upgrade hw, protoze to prestava stihat.

a pritom se to same dalo udelat do radove kB! ale samozrejme bez frikulinskych ficur
beh aplikaci v textovem rezimu neni zadny oldscool, ale normalni vlastnost. a nekdy je to dokonce preednejsi, nez ty patlafonacke dizajny ...

jenomze prave pro tento 'novatorsky' pristup ma racionalita a zdravy rozum utrum

at zijou frikulini

a jeste dodatek k 'pohoda nainstalovat' - neznam vetsi peklo, nez dohledavat a doladovat vsechny dependency tech 'normalnich modernich' aplikaci - to cycbi to, pak neni podpora ze strany hw, musi se delat upgrade OS, ... doinsalovavat ruzne balicky, dokupovat dalsi podpurny soft, resit zrychleni pripojeni do netu, protoze to, co by se mohlo ukladat lokalne, nebo servisa by mohla bezet jako sluzba na stejnem stroji, tak proste 'moderni' oblacek ...
povolovat na fw dalsi sluzby pro analytiku, ...

z toho mam vyrazky, kdyz slysim 'moderni' a 'normalni'

ne ze bych prodaval tolik softwaru, ale neznam komercni aplikaci (viz treba ta ucetnictvi) kterou bych si koupil a pak musel resit instalaci ruznych balicku, podpurny soft,... Spustim instalacku, nainstaluju a zacnu pouzivat.. Narozdil od nekterych tech hybridu kde nainstaluju sw, nainstaluju dosbox, zacnu mapovat tiskarny nebo tisknu do souboru, resim zobrazeni, problemy s diakritikou,...

No problém bude, že Ty to prodáváš, zatímco jiní lidé v tom musí pracovat. Daňoví poradci a účetní jsou na prášky už jen z neustálých změn v předpisech, jakmile jim překopáš rozhraní, na které jsou zvyklí, tak jde efektivita do kopru. Nehledě na to, že ty moderní aplikace na účetnictví zřejmě programoval sadistický autista stylem čím víc fíčur, tím víc adidas... Rozhodně se nedivím, že se všichni raději drží starých a osvědčených postupů. A vzhledem k tomu, že jsem zažil několik přechodů u ERP systémů, kde většina změn nakonec byla k horšímu, došel jsem k názoru, že ona konzervativnost někdy není úplně na škodu... Aneb neopravuj, co není rozbité.

No zrovna vcera jsem si instaloval ucetnictvi Abra Flexibee v Jawe.
Instalace spozivala v doublekliku na instalak.
Updaty (nove JARka) si to stahuje samo po spusteni, data jsou v cloudu a pristupne krome nativni aplikace i webovka.

Updaty (nove JARka) si to stahuje samo po spusteni

Výtečně!!! Přesně po tom každá účetní prahne, aby se jí při uzávěrce nebo např. v době, kdy se zpracovávají daně, něco samo stáhlo, zaktualizovala a rozbilo.

Nomen omen.

ja taky proti aplikacim v textovem rezimu nic zasadniho nemam. Ale bohuzel obcas neco resim s autory tech aplikaci a opravdu me prekvapi kdyz chci takovou appku presunout z jednoho sitoveho disku na jiny (zmenit jen pismeno jednotky ve windows) - a autor je takove prase ze v databazovych souborech ma natvrdo cestu asi na dvou tisici mistech - slysel takovy clovek neco o relativnich cestach, promennych,..?

Jinak chapu ze takova aplikace muze byt rychla, krasne ovladatelna a hlavne jsou na ni uzivatele nauceni. Problem nastava kdyz se pak pribaluje dalsi komunikace a na vsechno se pridavaji ruzne mustky, exporty (viz muj prvni prispevek).

Ja tem textovym aplikacnim rozhodne fandim a jsem rad, ze se porad jeste drzi, prestoze by jeden z nezasveceneho pohledu mohl ocekavat, ze tomu bude naopak. Mimo to, ze jsem slysel zajimave historky o migraci na "moderni" systemy jako treba MS Dynamics, kde i nejake relativne jednoduche ukony jsou obcas zalezitosti na vypiti kafe, jsem nedavno "migroval" UCTO ze stareho stroje s WinXP (a to i presto, ze se jinak snazim vyhybat windowsum velkym obloukem, ale holt jsem musel udelat vyjimku). Nebylo to sice uplne jednoduche, dalo to nejake koumani pro rozchozeni spravneho zobrazeni pres celou obrazovku, rozchozeni tisku (prakticky jen moje neznalost) a mozna jeste nejake drobnosti. Sice "zbytecna" prace, na druhou stranu pokud bych to delal vic nez jednou za X let, asi by mi to nedelalo zadne potize, takze to nepovazuju za nejakou zasadni nevyhodu. Podstatny je vysledek, a to, ze uzivatel je spokojeny a funguje mu uz 20 let prakticky jedena ten samy program pro spravu ucetnictvi, bez nejakych vnucenych nepotrebnych zmen. Jinak me teda fascinuje, ze to UCTO je takovy pekny slepenec vseho mozneho (rekl bych, ackoliv jsem se v tom do hloubky njiak nevrtal, ze to je asi postupnym historickym vyvojem), na druhou stranu to nakonec dobre funguje i po tech letech.

A vy si neumíte u DOSovské aplikace běžící v okně zvětšit písmo?

ja ano, ale bezny uzivatel editaci vlastnosti zastupce vetsinou fakt ne

TM, běžný uživatel není kokot :D
Zato o vás bych, podle těch kravin co jste tady na mnoha místech diskuse vypotil, asi úspěšně pochyboval :)

Kde se v souborech FANDu skrývá nápověda?

Soubory T00? Nebo H00? už si nevzpomínám, je to 20 let. Ale byly to zase jen databázové soubory s memo položkami.

Vlastně i samotný váš program byl databázový soubor.

Nápověda uživatelského runtime byly soubory UFADHLP.000 a UFADHLP..T00.

Programátorský analogicky FANDHLP..... Byly - jsou to běžné datové soubory FANDu s danou deklarací.

Kompletní evidenci došlých a odeslaných faktur i s úhradami jsem v tom dělal dva dny. (teda dvě směny po 8 hodinách, bez přestávek na kafe a pokec). Pak se to už jen roky v provozu v klidu dopilovávalo.
Dneska mi něco takového na trhu chybí.

Ještě jedn apoznámka... z hlediska našich uživatelů

FAND nám uprvili v "Početce" jak bylo třeba a rychlost ovládání a obsluhy perfektní.
Žádné dnešní lovení polí myší.

Pak přišel DIAMAC.
Způsob ovládání celkem OK, po navyknutí na prostředí Diamacu i velmi rychlé.
Ale naprosto jednobarevný (černobýlý) vzhled a totálně nepřehledné obrazovky.

Pak přišel SAP.
Katastrofa.
Potřebné funkce rozesety různě mezi transakcemi.
Nutnost klikání a trefování se do polí.
Nejednotný způsob ovládání v různých transakcích...
Nic nebylo možné za rozumnou cenu přizpůsobit.

Z mojeho pohledu (začínal jsem na XTčkách programovat ve FANDu a po letech jsem zkončil jako trochu pokročilý uživatel SAPu), bylo obládání ve FANDu geniální - velmi jednoduché.

Vývoj nezastavíš...
Nicméně z pohledu zpět (za víc jak 20 let) je vidět posun k nakupovaným aplikacím velkého (a drahého) formátu. A nevypadá to jako věc pokroku, ale spíš centralizování zisku :-(
a

Jedna věc je efektivní a pohodlné TUI (pokud má správné a dostačující funkce), druhá věc je centrální provoz, centrální DB atd.

Ne vždy je potřeba.

Reagoval jsem na qqq. Pokud byl původní software nahrazen SAPem, zřejmě centrální zpracování potřeba bylo.

SAP se vždycky nasazoval kvůli investorům. Protože když investor viděl, že firma zvládla přejít na SAP a nekrachla, tak měl jistotu, že ustojí k**evský problémy.

Bylo i nebylo.
Koupil nás zahraniční majitel a ten nařídil SAP...
Ale naše i jeho databáze propojena nebyla (až na ojedinělé dávkové převody).

Ale chápu.
Můj dnešní zaměstnavatel má mnoho poboček po světě a jednu centrální bázi.
To by ve FANDu asi nešlo.
Nicméně denní provoz plánování/náku­pu/výroby/skla­dů a prodeje bych si ve FANDu představit dovedl :-)
q.

Je že ty srovnáváš primitivní FAND s možná jedním z velkých ERP systémů a tvrdíš, že "nevypadá to jako věc pokroku, ale spíš centralizování zisku". To je absolutní blud.

Vem si co ERP SAP dokáže. Když nepůjdu daleko a jako uživatel tak napojení sklady a API pro eshopy. Vem si ta obrovská množství dat co to dokáže ovládnout. Vem si jaké to dokáže generovat sestavy ... a to ty srovnáváš s pomalou primitivní souborovou databází která končila když někdo špatně nastavil lannod (primitivní identifikátor v síti).

Jak se říká, méně je někdy více.

Mě se teda zdálo že porovnává hlavně uživatelská rozhraní.

Pro mě největší sranda byla, že k tomu PC Fandu existoval nějaký "disassembler", který uměl převést binární kód programu zpět na velmi dobře použitelný a zpět přeložitelný zdrojový kód. Takže celý slavný Tichý/Ježek se tím dal louskout popř. číst jeho kód pro inspiraci. Využil jsem to kdysi dávno při psaní aplikace, která evidovala zisky z výkupu akcií z kuponové privatizace pro jednoho človíčka, který se tím jednu chvíli živil. Mohlo to být kolem roku 1997.

PC FAND je interpret, takže aplikace FANDu nebyla ani po nenávratném zaheslení v binárním kodu, byla jen "nevratně" zaheslená v tom smyslu, že ani ALIS neposkytoval prostředek pro její dekodování. Ten vzniknul mimo ALIS. Část programátorů na to nadávala a druhá část to použila jako záchranu když zapomněla vlastní hesla. Vyberte si svoji verzi....

No ona existovala komerční aplikace FandOpen (tuším provozovaná a nějak licenčně svázaná s programátorským Fandem 3.x) a ta dokáže otevřít i fand 4.x úlohy a to i ty nevratně zakódované ... akorát že u nich vypadne neodsazený zdroják bez komentářů, ale na pochopení to stačí ... a pak existuje nějaký postup "domanglování" zřejmě té ofiko zakódované úlohy tak, že FandOpen nezíská F deklarace (načte místo nich "vtipný" protipirátský text :) ... jen připomínka pamětníka pro pamětníky ... zdravím Bicmana :)

za rozsirenim PC Fandu vidim zejmena 2 aspekty.

Prvni takovy system jsem videl v roce 1982 na 8-bitovem Commodore8032. Ten 'pan' programator si to ovsem nevymyslel, myslenka nejakeho takoveho frameworku jak v clanku popsano byla znama v IT uz od 1/2 70. let. Ten muj znamy na toto tema napsal diplomku (jeji praktickou cast odevzdal ve forme dernych stitku (pocitac Data General) v krabici od bot :-)).

K tomu , aby se podobne systemy mohly rozsirit na Unixu bylo treba 2 udalosti. Bill Joy napsall prvni termcap library (databaze Escape sekvenci) (1978) a firma Digital impelmentovala ty sekvence do legendarniho terminalu VT100 (1979). Jeste nez byl znam IBM PC vzniklo tedy nespocetne mnozstvi aplikaci s textovym uzivatelskym rozhranim. Jednu takovou aplikaci pouzivane dodnes. Ale take jako admin dodnes znam nazpamet vsechny esc-sekvence funkcnich klaves pro xterm, ansi a vt100/220. Jedna vec je totiz norma, a to druhe, ze to nekdo musi aplikovat. To je jak u tech prohlizecu.
Podobne trable vyvojari Fandu nemeli - to je ta vyhoda monopolu.

Druhy, podle mne mnohem dulezitejsi je ta absence SQL.
V systemu jako Fand je sprava dat rizena velice jednoduse. Zalozit record, smazat, zmenit a nebo precist dalsi nebo predchozi. To je vse. To se da schovat do nekolika funkci. Zadne normalni formy, m:n vztahy, datbazovi konzultanti, provadeci plany a nekompatibilni SQL verze. (vyjmenujte databaze, u kterych je pri update stejneho obsahu radky affected_rows 1 a u kterych je 0).

Jednoduche frameworky, tak je autor popsal nejsou s SQL prakticky realizovatelne, ORM je toho prikladem.

Systém PC-FAND byl, je a bude ještě dlouho jedním z nepřekonaných systému databází. Jediné co na něj mělo byl ve svojí době BTRIEVE system, ale ani ten nebyl tak flexibilní. Svojí koncepcí efektivního provázání souboru přes sdílené klíče, vícenásobné primární klíče, automatické aktualizace souvisejících záznamu a journalingu, včetně zamykání záznamu po větách při aktualizaci v sdíleném síťovém prostředí do dnešní doby nic tak flexibilního a přitom jednoduchého nenajdete. Měli jsme na něm udělán v 90-tých létech systém spracování receptu z celé spádové oblasti Oravy (cca 150000 záznamu měsíčně)na PC-MOS a počítačích PC386, evidenci rentgenových snímku, vlastní systémy jednoduchého a podvojného účetnictví a mezd (jelikož po rozpadu federace se finanční zákony obou republik natolik rozešly, že nebylo možné použít puvodní UČTO a STEREO. A taky spoustu jiných programu na spracování výsledku závodu v motocrosu, střelbě a jiných.
Účetnictví na něm provozujem dodnes cca pro 70 firem i na platformě win_64 (XP a Win7) v emulaci přes vDOSplus, a taky ma počítačích Apple přes to samé a Parallels emulátor pro provoz woken na MAC OS-X, včetně propojení na on-line systémy finanční správy v SR, protože pořizování dat je cca o 50% rychlejší než přes dostupné nativní windowsové okénkové programy :-))
Jediné co autorum vyčítáme je, že se po náběhu linuxových systému na trh nedokázali dohodnou a překlopit system nativně pod linuxové prostředí, protože něco tak efektivního, jednoduchého, provozně nekomplikovaného s obrovským výkonem a flexibilního na se zatím nevyskytuje.

Zdravím, Fand ve své účetní praxi stále nezastupitelně používám, takže bych přivítal možnost konzultovat některé programátorské oříšky. Rád za pomoc zaplatím. Pokud byste měl zájem, jednadve@post.cz :-)

A největší sranda je, že reálně používá dnes FAND víc lidí než linux na desktopu ... .

Článek je docela rozsáhlý, ovšem některá tvrzení mi přijdou sporná. Např. že PC FAND nepřežil nástup SQL databází. Nevím jestli pro FAND byl SQL nějaká konkurence - tak to asi nebylo nikdy chápáno , FAND byl spíše doplněk k velkým systémům. Že je občas trochu přerostl je již jiná věc. Navíc i dnes, v roce 2018 ty aplikace stále žijí a existují opravy některých starých omezení FANDu, kdy se omezení na rok 2020 prodlužuje na rok 2030, 2050 . . . .
A dále např. . .. SQL (PC FAND je jím nedotčený). No tomu moc nerozumím, FAND je postavený na stejném relačním DB modelu jako SQL, má analogické datové typy a některé další vlastnosti, kupříkladu implicitní hodnoty, integritní omezení, vypočtené hodnoty.... Konec konců byl ve vývoji i SQL - FAND, client pro SQL databáze. Ten vývoj skončil spíše na tom, že byl drahý - otázka obchodního modelu. Ale technicky pro aplikaci FANDu bylo jedno jestli má tabulku vlastní nebo je na SQL serveru. Což něco napovídá o příbuznosti datového modelu FANDu a SQL. ALIS by asi ještě dnes mohl najít originál příručku SQL FAND. Obávám se, že FAND je mnohem méně smrtelný než mnoho programátorů co v něm programovali.

(býval hotline FANDu v ALISu) Již si nepamatuju detaily z SQL FANDu, ale myslím že tam byl nějaký komunikační server, který překládal FANDovské příkazy do jazyka SQL. V úloze FANDu - zdrojáku - stačilo označit určité tabulky příznakem .SQL (podobně jako indexové soubory .X) a s nějakými omezeními byly tyto tabulky místo dat. souborů FANDu uloženy na SQL serveru. Implementace komunikačního serveru byla tuším pro Informix. Byl k tomu i spec. překlad FANDu - vlastně z důvodů úspory paměti u standardních variant runtime. Komunikační server psal stejný autor jako ODBC driver, Tom Havelka. Dnes již pan důchodce stejně jako G.K. Bylo tam uděláno spousta práce ale na dotažení technické i obchodní by byly zřejmě potřeba kapacity které ALIS neměl, resp. měl další oblasti činnosti které dostaly prioritu.

Myslim ze to mel byt Sybase

Informix,
Na tom byla uložena data IS DIAMAC :-)

No chtěli jsme DIAMAC, ale peníze nebyly.
Koupili jsme DEC server s Unixem a Informixem a koketovali jsme s převodem námi napsaného IS ve FANDu na tento server. Právě dle výše popsaného...

Nakonec peníze byly a přešli jsme na DIAMAC (taky TUI, zprvu uživatelsky nepříjemné, ale uživatelé si zvykli a IS jsme běhěm asi tří let kompletně rozjeli). A stejně jako FAND bylo TUI DIAMACu schopné pracovat na i tehdy úplných šrotech 286...

....FAND je postavený na stejném relačním DB modelu jako SQL ...

ta veta je nejaka divna nebo ji nerozumim.

SQL je dotazovaci jazyk pomoci ktereho lze vytahnout data z jakehokoliv systemu - i takoveho, kde vyvojar nemel o relacnim modelu nejmensi potuchy. Je potreba pouze napsat ten spravny driver (parser, provadeci program). To, ze se pouzije SQL jeste tedy neznamena, ze nejaky system je relacni.

.... má analogické datové typy a některé další vlastnosti, kupříkladu implicitní hodnoty, integritní omezení, vypočtené hodnoty....

Tyto vlastnosti maji vsechny databazove systemy, hierarchicke i sittove. To by take neprokazovalo pritomnost relacniho systemu.

Co je tedy nejaky relacni sytem. Takovy, kde je zakladem tabulka. Ale v uzivatelske prirucce FANDu je rec pouze o souborech. Slovo tabulka ve smyslu SQL se vyskytuje pouze jednou. '*.SQL -- soubor urceny k emulaci tabulky SQL servru diskovym souborem'.

Rekl bych, ze formulace pana Stehuleho (nedotcen SQL) neni naprosto spravna. Vyvojari se podle mne skutecne v posledni chvili snazili naroubovat na souborovy system FANDU SQL pristup. ODBC driver je takova klasika, kazda ISAM-databaze ma takovy, aby se k tem souborovym datum dalo pristoupit pres SQL.

Ale take to zaroven vlastne potvrzuje tvrzeni pana Stehuleho, neb vyvojari sami videli absenci SQL jako nedostatek.

To je nějaké intro, po kterém bude opravdový článek, nebo to je jako všechno?

Dobry den pan Stehule. Nenapisali by ste nieco aj o vyssie spomenutom REDAPe? Ten mal dokonca aj UNIXovu variantu, tam bol potencial ho preklopit aj pod Linux, podla autora tomu zabranila roztriestenost distribucii. A je to domaci produkt s dlhou historiou. Pekny den.

K Redapu by asi jediným skutečně autoritativním zdrojem byl autor pan Šantl, kontakt na webu redap.cz nebo whois domény, patrně obdivuhodný zvídavý programátor důchodce (viz. jeho changelogy na webu, třeba k EET implementaci). Rozhovor s ním by mohl být velmi zajímavý. Co osobně vím, historie Redapu je hodně dávná, jeho skriptovací jazyk "ATP procesor" je defakto rozšíření cli operačního systému RSX-11M ze strojů PDP-11 resp. jejich SMEP ekvivalentů z doby socialismu a ty jednotlivé instrukce (zuz, inf, ded ...) byly původně exáče (cli stdin/stdout, cli filein/fileout nebo TUI) pro ten RSX. No a později zřejmě přes Dec VAX VMS, Unix (minimálně odsud to už musí implementovat i ten ATP "shell") do DOSu (určitě byla verze po roce 2000), Windows 3.x, mezitím odbočka k Linuxu a zakotvení u 32 bit Windows, nyní i 64 bit Windows ... Z hlediska skromného porovnání Fand/Redap - definice obsluhy formulářů a tiskových sestav v Redapu byla v porovnání s Fandem kryptičtější, 2znakové proměnné se speciálním významem ... Fand byl (aspoň pro mne příležitostného programátora dolaďovače) výrazně srozumitelnější ...

V PC FANDu se snadno vyvíjí a aktualizuje. Zeptejte se u Ježka, jaký je poměr práce vynaložené na roční aktualizaci "Windowsovského" Duelu a FANDovského Sterea, jinak co do funkce srovnatelných účetních programů. Odhaduji, že PC FAND potřebuje 3× až 10× méně námahy.
Tichého & spol. Účto funguje už 27 let a má nějakých 20.000 legálních*) uživatelů.
*) PC FANDovské programy se snadno (a hodně) kradou.

jak "nepřežila nástup SQL".. já znám jednu firmu kde na PCFANDU jedou nějakou agendu i dneska.. dosbox a frčí to, nikdo nemá sílu to zrušit. To samý dosová Foxka, to vídám dokonce v několika účetních firmách.

Je zde zmíněn FoxPro resp. VFP. Také udržuji několik takových projektů a vzhledem k více jak desetileté smrti vývoje je to těžší a těžší. Jaké jsou možnosti, které byste doporučili? Jde o prostředí pro rychlý vývoj velkých databázových aplikací s příslušným UI. Důležitá je ovladatelnost klávesnicí (nezvládá většina řešení postavených na webovém rozhraní), rychlost práce s velkými databázemi, efektivita provozu, levný a rychlý vývoj.

Těžko říct, situace je tristní. Po VFP následoval MS Lightswitch, ale ten je už odstavený na slepé koleji. Takže nejlepší bude počkat, až se vyloupne jiné nové uzavřené databázové vývojové prostředí od MS a přepsat si do něj veškerý kód, jen tak pro srandu králikům.

Těžko říct, situace je tristní. Po VFP následoval MS Lightswitch, ale ten je už odstavený na slepé koleji. Takže nejlepší bude počkat, až se vyloupne jiné nové uzavřené databázové vývojové prostředí od MS a hned do něj přepsat veškerý kód, jen tak pro srandu králikům.

Díky za článek!:)
Jen je trochu škoda té češtiny...lehce tupých obratů, jako "...se překonvertoval" či nepřirozených větných konstrukcí a zjevných chyb při přestrukturovávání textu - např. "licenční (cenová politika)".

Jak se u PC FANDu řešilo zálohování a obnovování dat (řekněme, že bych chtěl vytvářet úplnou kopii dat každý týden)?
Staral se o to PC FAND samotný, nebo se používaly nějaké obecné programy pro zálohování?

Resilo se to primo, nastavovalo se v katalogu, ale vic si nevzpominam.

PC Fand jsem od jiste doby nenavidel a od jiste doby obdivoval pro jednoduchost ( a jako bezny cesky malomestsky balik ktery nebyl z prahee ani z blavE! jsem samozrejme mel mizernou anglictinu). Love - hate relationship.
PC Fand pritahoval tyhle jazykove poklesle lidi protoze byl v nasi divne reci a byl skutecne jednoduchy. To je to co modernim SW produktum chybi

Hlavni muj hate spocival nutnosti resit v real modu (ano real mod nejen na zacatku ale i na konci 90tek), vyhazet nepouzivany rezidenty, extra pamet, emm386,buffery a hlavne disk caching kterej zas nemohl uzrat moc pameti jinak se ten software uchroupal k smrti na velkych projektech. Sam caching na databazove urovni vubec neresil - to tehdy moc nebyvalo ani v jinych systemech.

Docela by jste se divil, počet vět je limitován longint počítadlem (2na31) a velikost file obecnou možností MS-Dos filesystému, takže 2GB. V síti pokud to programátor zvládl dobře indexovat nebyl vážnější problém.
Dodnes ještě běhají některé aplikace pod NTVDM v 32-bit verzích Windowsů, z nouze lze provozovat i v 64-bit windowsech pomocí emulátorů, ale rychlost v tom případě letí silně dolů. Výhodnější je virtualizace a spuštění 32-bitového systému a pod ním běh PC-Fandovské aplikace.

FAND:
Provozoval jsem na siti bezdiskovych 386ek, Novell 3
X

Kusovnikovy rozpad polozky byl asi 10x rychlejsi nez v K2 na 8mi procesoro em serveru na MS SQL.

Nebo treba sdilena editace tabulek se zamykanim vet - FAND delal automaticky sam.
.Netreba licenci na Db server, klienty ...

V posledni verzi padlo omezeni valikosti index.souboru na 32MB, takze omezeni je je max.velikost souboru DOSu.

Nejen ze zadavni dat do formularu je nejrychlejsi,
Textovy rezim tez ucelne omezuje tez jejich progrqmovani
automaticky navrh s pripadnou minimalni upravou, protoze jinak se to tam proste naskladat neda :-)
Formulare v grafice, to je jen neustale presouvani poli/prvku, aby to pasovalo ...
Ve FANDu proste nejsou, ani potreba :-)

Jednoduchost, s jakou se ve FANDu yyvyji, ma bohuzel trvale nasledky na programatorovi:
Nenasell jsem nic novejsiho, obdobne snadno pouzitelneho.
Mozna kdysi Access, ale ten s poctem zaznamu sel do ...

Bohuzel, muzete nesouhlasit/ale to je vse.

paradox QBE bylo moc fajn, bezpečně nejlepší adhoc query system jaky jsem kdy videl, ale pokud jde o relacni databazi a jeji moznosti, tak FAND se spise podobal velkym SQL serverum, bohuzel to byl lokalni monolit, bez jakekoliv moznosti spustit se na serveru a poskytovat logiku stanicim/termi­nalum, takhle to v DOSu nefungovalo jako na Linuxu, ale to vy vite... DEKLARATIVNI popis konceptualniho schematu databaze v RELACNIM datovem modelu (ano pane "backup", ano), protoze slo o mnoziny zaznamu tedy relace, provazane cizimi klici, indexovanim i podle vypocitanych polozek, triggery (akce provadene pri CRUD operacich, nektere deklarativni i pres cely model) - tohle NIKDE jinde neexistovalo a dosud neexistuje ... MNOHOKRAT jsem to za celou dobuexistence internetu hledal jako "Svaty gral" a nenasel, nikde ... protoze ano, FAND omezene komunikuje s okolim, okolim, to je psycho, uz nekompatibilita editoru s cimkoliv, copy/paste treba, pouze primitivni export/import csv/fix/dbf, primitivni a asi nespolehlivy linkna SQL servery pres ODBC (nikdy jsem nezkusil, nebylo proc, v roce 1993 jsem navrhoval request/response smart klienty aplikacniho serveru, kde klienti/features byli vicemene temer "generovatelni z datoveho modelu response", unifikovany pristup ke kazde tabulce/relaci ala rest/crud, dost otravna prace pomerne s tim ze v lokalni databazi s nekolika "otevrenymi pripady" (treba komplet chorobopisy pacientu) je mozne pracovat lokalne/offline od appserveru a na konci provest finalni commit vsech zmen najednou; tenkrat byl chvili cas premyslet poradne nad takovymi vecmi, ale pak prestala veskera legrace s nastupem byznysmenu ve fialovych kvadrech s bilejma ponozkama a zlatejma retezama ......

Zdravím, Fand ve své účetní praxi stále nezastupitelně používám, takže bych přivítal možnost konzultovat některé programátorské oříšky. Rád za pomoc zaplatím. Pokud byste měl zájem, jednadve@post.cz :-)

Sám jsem jako lékař používal řadu let v ordinaci skvělý program "Ordinace rodinného lékaře" autorů ze Cvikova, vytvořený ve FANDu, a nedám proto na FAND dopustit. A tak jsem se stal i majitelem licence na programátorskou verzi, ale sám jsem neprogramoval, spíše "poučeně" využíval možností, které mi FANDovské programy dávaly.
Můj syn, IT inženýr, mi před lety, během svých studií, ve FANDu napsal několik dalších programů (domácí účetnictví, různé databáze - disket, knih, gramodesek, CD, jednoduchý textový editor, telefonní seznam...). Pod Windows 10 64 bit však nelze FAND jednoduše provozovat. Jen díky dobrým přátelským vztahům s jedním z autorů Ordinace, který pomocí DOS BOXu tento problém v rámci možností vyřešil, mohu Ordinaci rodinného lékaře pro své rodinné příslušníky a synovy programy používat, teď už v důchodu, i nadále.
Je velká škoda, že FAND je již historíí, že nepokračoval dál.

Od roku 1990 používám stále PC Fand a stále nevidím důvod pro pokrytí mnoha, dokonce bych řekl většiny, běžných agend k jeho nepoužívání. K jeho nepoužívání vás nutí více nutnost obměny HW a ruku v ruce s tím i nové operační systémy, které vědomě nepodporují SW, který vám spolehlivě chodí a ani ho nechcete inovovat. Nejde o to, že byste ustrnuli či nešli z dobou, Jde o smysl inovace, toho samého na to samé.
Pokud budete mít ve firmě "provozáka" (typu Ferda Mravenec - práce všeho druhu) nejen na správu SW i HW, ale i na jiné potřebné činnosti, tak jako vlastníci firmy nebudete mít pocit, že když mu SW a HW bezchybně šlape, že se fláká.
Asi vám může připadat zvláštní až extrémní, ale když dnes v roce 2018 máte funkční PC s Windows 98 (a umíte ho udržet funkční), tak tím, že ho nemusíte chránit "antvirákem", běží svižněji než "tehdá" a dokonce předvídatelněji, a to, co je neefektivní zde zpracovat, si zpracujete v soudobých PC pod soudobým OS a v potřebném SW. Chápu, že dnešní "nervní doba", potřebuje pro "nervní" uživatele odolnější "werky", aby mohli mít na liště "1000 + jednu" aplikaci v "pohotovostním" režimu...
Je to fakt jako s auty: pokud jedete přes Česko 70...90...130 a více km/h můžete mínutový čaový profit, který "využijete" na koukání TV místo "kochání" se při jízdě :o))

PC Fand běží prostřednictvím programu vDosPlus (http://http://vdosplus.org/) i na 64bitových OS Windows.