View Full Version : [c] compilazione a basso livello sistemi operativi
nuovoUtente86
28-07-2007, 00:03
Essendo un sistema operativo un ' entita multistrato con diramazioni a livello molto basso fino alla comunicazione diretta con l' hardware,per quello che si puo dire su un sistema molto complicato oltre al lingiaggio macchina e al c oggi quali altri linguaggi si utilizzo per lo sviluppo di un SO.Quali ambienti di sviluppo si utilizzano e come avviene la compilazione e l' integrazioni di entità molto differenti.Mi incuriosce molto la compilazione di una struttura che poi dovrà essere la primaria sulla macchina.
Dipende da che "livello" parti.
Se hai già un sistema operativo compatibile con quello che vuoi compilare si tratta solo di andare ad utilizzare la libreria precompilata per quel dato sistema operativo.
Se invece crei per la prima volta un sistema operativo, mettiamo di essere a livelli moooolto bassi, cioè sulla macchina non c'è niente, devi far uso di un altro sistema operativo e fare un cross compiling per la macchina ospite.
Prima di tutto non puoi fare uso della libreria standard del C o del C++ per tutte quelle cose che accedono al sistema operativo.
Quindi devi cominciare riscrivendoti delle routine di base che sfruttino inizialmente le routine messe a disposizione dal bios per permetterti di fare un minimo di debug visuale (in particolare output di testo). Quando si è arrivati a mettere la macchina ospite nello stato necessario per avviare il nostro sistema operativo (modalità del processore e della memoria desiderata) bisogna cominciare a scrivere le nostre routine di gestione delle interruzioni. In questo modo si creano le fondamenta sulle quali si baseranno tutte le system call del nostro sistema operativo. Le operazione basilari riguardano principalmente l'allocazione e la deallocazione di memoria e l'output.
In questo modo sarà possibile andare a cominciare a creare un kernel base del sistema operativo.
Successivamente si aggiungeranno man mano le altre routine di gestione delle interruzioni insieme ai rispettivi driver di periferica. Ad esempio la routine di gestione dell'input da tastiera dovrà appoggiarsi al driver della tastiera.
Si va avanti così, ingrandendo sempre più il sistema.
Inizialmente il sistema sarà completamente caricato in memoria in maniera monolitica dal disco di avvio, poi verrà implementato un file system (almeno inizialmente il più semplice possibile, magari mappato in memoria) ed a questo punto sarà possibile implementare una shell.
Essendo un sistema operativo un ' entita multistrato con diramazioni a livello molto basso fino alla comunicazione diretta con l' hardware,per quello che si puo dire su un sistema molto complicato oltre al lingiaggio macchina e al c oggi quali altri linguaggi si utilizzo per lo sviluppo di un SO. nessuno: i linguaggi usati sono quelli. i kernel odierni sono scritti in C con piccole parti di assembly necessarie ad effettuare nelle prime fasi di avvio i settaggi del processore (per esempio per farlo entrare in modalità protetta), nonché per fare I/O diretto sull'hardware. so di un solo kernel scritto in C++, ed era quello di BeOS. dicono che si trattasse di un ottimo sistema operativo e non esito a crederlo, ma purtroppo è fallito.
Quali ambienti di sviluppo si utilizzano e come avviene la compilazione e l' integrazioni di entità molto differenti. come ambiente di sviluppo usi quello che ti pare: puoi usare Blocco Note come puoi usare Visual C++ 2005, ma ti servirà solo come editor di testo perché poi la compilazione avverrà a parte, tipicamente tramite makefiles. conosci l'utility make?
Mi incuriosce molto la compilazione di una struttura che poi dovrà essere la primaria sulla macchina. la compilazione di un sistema operativo consiste semplicemente nella compilazione di tante comunissime immagini eseguibili. Windows per esempio è costituito da normalissimi files .exe e .dll
l'unica piccola eccezione a ciò è la compilazione del bootloader: il bootloader è costituito essenzialmente da due parti, un piccolo pezzo di codice eseguibile in formato binario puro (ci sono le istruzioni di assembly e basta) ed un altro eseguibile più grosso che può essere in vari formati a seconda delle scelte progettuali di chi scrive il bootloader. il primo pezzo altro non è che quello che va a finire direttamente nei primi settori della partizione su cui è installato il sistema operativo, e deve essere in formato binario puro perché la CPU al caricamento lo legge in RAM e lo esegue così com'è. tuttavia programmare in quelle condizioni (cioè in assembly in modalità reale a 16 bit) è estremamente scomodo, e di conseguenza questa prima parte del bootloader deve fare il meno possibile: si occupa di entrare in modalità protetta a 32 bit, di organizzare un memory model decente, di leggere dal disco il resto del bootloader vero e proprio, e di lanciare quello. il resto del bootloader è più comodo da programmare perché a quel punto può essere scritto tranquillamente in C a 32 bit. su Windows il bootloader si trova nel file NTLDR (senza estensione), il quale deve essere localizzato alla radice della partizione in cui è installato il sistema (tipicamente il file è C:\NTLDR, per vederlo in Esplora Risorse devi impostare l'opzione per visualizzare i files nascosti e i files di sistema).
Windows per esempio è costituito da normalissimi files .exe e .dll aggiungo: in effetti non ci sono solo .exe e .dll, come estensioni puoi trovare anche .sys (estensione tipica per i drivers), .ocx (gli ActiveX), ed .scr (gli screensavers). ma il succo del discorso non cambia perché exe, dll, sys e quant'altro sono tutti esattamente la stessa cosa: sono immagini eseguibili, e sono memorizzate nello stesso identico formato (a meno di un unico bit nel'header che dice se quell'eseguibile può essere lanciato in maniera diretta, come gli exe e come gli scr).
Mi incuriosce molto la compilazione di una struttura che poi dovrà essere la primaria sulla macchina.
Se vuoi "toccare con mano" buttati su linux, puoi ricompilarlo, modificarlo, studiarlo come ti pare.
sukoy27k
01-08-2007, 13:21
come ambiente di sviluppo usi quello che ti pare: puoi usare Blocco Note come puoi usare Visual C++ 2005, ma ti servirà solo come editor di testo perché poi la compilazione avverrà a parte, tipicamente tramite makefiles. conosci l'utility make?
uno solo appunto...in Visual Studio....tasto destro sul progetto Configuration Properties->General->Configuration Type->MakeFile...un batch farebbe la stessa cosa ma perchè farlo se già c'è :)
sottovento
02-08-2007, 08:33
Il salto di qualita' e' stato fatto, appunto, introducendo i linguaggi ad alto livello per la scrittura del sistema operativo e riducendo le parti scritte in assembler al minimo indispensabile.
Oltre ai linguaggi gia' citati, discreti successi sono stati ottenuti utilizzando i linguaggi PASCAL e JAVA.
e JAVA.
:mbe:
Per quale sistema operativo ?
sottovento
02-08-2007, 08:38
:mbe:
Per quale sistema operativo ?
So di molti tentativi (riusciti), anche da Apple e Sun stessa. Ho letto diversi articoli in proposito. Se ho tempo, posto una lista di cosa si puo' trovare in giro...
So di molti tentativi (riusciti), anche da Apple e Sun stessa. Ho letto diversi articoli in proposito. Se ho tempo, posto una lista di cosa si puo' trovare in giro...
intendi una roba del genere?
http://www.tuxjournal.net/?p=15
sottovento
02-08-2007, 09:12
intendi una roba del genere?
http://www.tuxjournal.net/?p=15
Non lo conoscevo. Beh, pero' mi permette di giustificare quello che ho scritto :mc: :D .
Comunque posso riportare anche
http://en.wikipedia.org/wiki/Object-oriented_operating_system
che mi fa venire in mente che abbiamo dimenticato di citare, fra i linguaggi, l'Objective-C, che so essere molto usato da un assiduo (e simpatico) frequentatore di questo forum :D
intendi una roba del genere?
http://www.tuxjournal.net/?p=15
Un kernel C/C++ con applicazioni Java a quanto sembra...
Comunque mi sembra che non si riesca in ogni caso ad usare solo Java e assembly, ma serve sempre anche un terzo linguaggio, virtual machine a parte ovviamente (questa deve essere scritta sempre in C o C++).
tomminno
02-08-2007, 11:23
Il salto di qualita' e' stato fatto, appunto, introducendo i linguaggi ad alto livello per la scrittura del sistema operativo e riducendo le parti scritte in assembler al minimo indispensabile.
Oltre ai linguaggi gia' citati, discreti successi sono stati ottenuti utilizzando i linguaggi PASCAL e JAVA.
E come farebbe un codice Java puro a gestire direttamente la memoria?
Mi sono sempre chiesto come si potrebbe fare a scrivere la JVM in Java.
Mi sono sempre chiesto come si potrebbe fare a scrivere la JVM in Java.
Ovviamente non si può ;)
Mi sono sempre chiesto come si potrebbe fare a scrivere la JVM in Java.
beh potresti pure scriverla in Java, ma ti servirebbe un compilatore in grado di generare codice eseguibile su quella macchina, altrimenti avresti bisogno di una VM sulla quale far girare la JVM :D
tomminno
02-08-2007, 15:22
beh potresti pure scriverla in Java, ma ti servirebbe un compilatore in grado di generare codice eseguibile su quella macchina, altrimenti avresti bisogno di una VM sulla quale far girare la JVM :D
Per scrivere la JVM in Java dovresti avere la possibilità all'interno del linguaggio di gestire direttamente la (de)allocazione della memoria, l'algoritmo di GC ad un certo punto dovrà fare una "delete" che non è una operazione contemplata da Java.
Per scrivere la JVM in Java dovresti avere la possibilità all'interno del linguaggio di gestire direttamente la (de)allocazione della memoria, l'algoritmo di GC ad un certo punto dovrà fare una "delete" che non è una operazione contemplata da Java.
eh già sei sempre lì...
ma poi a che pro scrivere una JVM in Java?
come prossimo step propongo un sistema operativo in Perl :D (qualcuno pare ci abbia provato)
Per scrivere la JVM in Java dovresti avere la possibilità all'interno del linguaggio di gestire direttamente la (de)allocazione della memoria, l'algoritmo di GC ad un certo punto dovrà fare una "delete" che non è una operazione contemplata da Java. o per meglio dire, sarebbe un'operazione che verrebbe affidata al garbage collector del linguaggio, il quale di conseguenza dovrebbe essere implementato automaticamente dal compilatore quando genera il codice eseguibile per la macchina. troppo complicato, è molto meglio realizzare una virtual machine in C++ e poi scrivere tutto il resto in Java.
tomminno
02-08-2007, 16:01
eh già sei sempre lì...
ma poi a che pro scrivere una JVM in Java?
come prossimo step propongo un sistema operativo in Perl :D (qualcuno pare ci abbia provato)
Se non puoi scrivere la JVM, non puoi scrivere neanche un sistema operativo in Java.
Tutto perchè era stato postato di sistemi operativi scritti in Java, in realtà sono OS nel cui kernel è integrata una JVM ed esguono programmi Java.
Ho letto una successione di interventi che andrebbero bene per un'epitaffio.
Qui giace la programmazione, arte praticata nell'attesa di essere scoperta.
Un abbraccio a recoil che pare l'unico a conoscere la differenza tra linguaggio e compilatore.
nuovoUtente86
02-08-2007, 16:18
nessuno: i linguaggi usati sono quelli. i kernel odierni sono scritti in C con piccole parti di assembly necessarie ad effettuare nelle prime fasi di avvio i settaggi del processore (per esempio per farlo entrare in modalità protetta), nonché per fare I/O diretto sull'hardware. so di un solo kernel scritto in C++, ed era quello di BeOS. dicono che si trattasse di un ottimo sistema operativo e non esito a crederlo, ma purtroppo è fallito.
come ambiente di sviluppo usi quello che ti pare: puoi usare Blocco Note come puoi usare Visual C++ 2005, ma ti servirà solo come editor di testo perché poi la compilazione avverrà a parte, tipicamente tramite makefiles. conosci l'utility make?
la compilazione di un sistema operativo consiste semplicemente nella compilazione di tante comunissime immagini eseguibili. Windows per esempio è costituito da normalissimi files .exe e .dll
l'unica piccola eccezione a ciò è la compilazione del bootloader: il bootloader è costituito essenzialmente da due parti, un piccolo pezzo di codice eseguibile in formato binario puro (ci sono le istruzioni di assembly e basta) ed un altro eseguibile più grosso che può essere in vari formati a seconda delle scelte progettuali di chi scrive il bootloader. il primo pezzo altro non è che quello che va a finire direttamente nei primi settori della partizione su cui è installato il sistema operativo, e deve essere in formato binario puro perché la CPU al caricamento lo legge in RAM e lo esegue così com'è. tuttavia programmare in quelle condizioni (cioè in assembly in modalità reale a 16 bit) è estremamente scomodo, e di conseguenza questa prima parte del bootloader deve fare il meno possibile: si occupa di entrare in modalità protetta a 32 bit, di organizzare un memory model decente, di leggere dal disco il resto del bootloader vero e proprio, e di lanciare quello. il resto del bootloader è più comodo da programmare perché a quel punto può essere scritto tranquillamente in C a 32 bit. su Windows il bootloader si trova nel file NTLDR (senza estensione), il quale deve essere localizzato alla radice della partizione in cui è installato il sistema (tipicamente il file è C:\NTLDR, per vederlo in Esplora Risorse devi impostare l'opzione per visualizzare i files nascosti e i files di sistema).
quale sarebbe la difficolta' di scrivere il pezzo di codice che va nell' mbr; e si occupa quindi dello stage 1 di boot, in C.Una volta compilato sarebbe cmq eseguibile.
nuovoUtente86
02-08-2007, 16:37
Un kernel C/C++ con applicazioni Java a quanto sembra...
Comunque mi sembra che non si riesca in ogni caso ad usare solo Java e assembly, ma serve sempre anche un terzo linguaggio, virtual machine a parte ovviamente (questa deve essere scritta sempre in C o C++).
Be la cosa sarebbe fattibile se si riuscisse a scrivere una jvm direttamente in assembly,cosa probabilmente fattibile ma alquanto ardua..in tal caso sarebbe ipotizzabile un OS tutto in java e assembly
nuovoUtente86
02-08-2007, 16:43
eh già sei sempre lì...
ma poi a che pro scrivere una JVM in Java?
come prossimo step propongo un sistema operativo in Perl :D (qualcuno pare ci abbia provato)
Appunto che senso avrebbe scrivere una JVm in java quando a livello inferiore dovresti cmq scrivere un' altra macchina virtuale in grado di rendere eseguibile la jvm scritta in java,nel senso...scrivi il tuo programma java e generi il bytecode che finisce sulla jvm,ora se la jvm è scritta in java essa stessa dovrà essere interpretata per poter lavorare e viene da se che sotto deve avere un altro linguaggio eseguibile.Non capisco come mai molti limitavano il problema alla gestione della memoria quando quello di fondo è il fatto che java è un linguaggio interpretato e non compilato o meglio nn del tutto compilato anche se utilizza lo JIT.
Quanto ai sistemi operativi in java la soluzione potrebbe stare appunto nell' integrazione nel kernel di una jvm
Tutto perchè era stato postato di sistemi operativi scritti in Java, in realtà sono OS nel cui kernel è integrata una JVM ed esguono programmi Java. io un sistema operativo scritto in Java lo vedrei più come una virtual machine sulla quale girano il kernel, i drivers, e gli applicativi user mode.
quale sarebbe la difficolta' di scrivere il pezzo di codice che va nell' mbr; e si occupa quindi dello stage 1 di boot, in C.Una volta compilato sarebbe cmq eseguibile. la difficoltà nello scrivere in assembly a 16 bit e con quella schifezza di memoria segmentata della modalità reale degli Intel mi pare ovvia :D
è una cosa difficile di per se', è più facile di quanto viene dopo solamente per il fatto che il disco fisso lo leggi usando i servizi del BIOS (perché dopo invece quando sei entrato in modalità protetta a 32 bit il BIOS non funziona più, e là ti ci voglio con l'I/O diretto sull'hard disk :D).
Per il discorso di os basati su java da:
http://www.arm.com/products/CPUs/architecture.html
ARMv5TEJ
In 2000, the ARMv5TEJ architecture added the Jazelle® technology extension to support Java acceleration technology, which is particularly suited to small memory footprint designs. Jazelle technology’s acceleration of Java bytecodes provides significantly higher performance than a software-only based Java Virtual Machine (JVM), accelerating Java execution by 8x and providing an 80% reduction in power consumption compared to a non Java-accelerated core. This functionality gives platform developers increased freedom to run Java code alongside established operating systems (OS) and applications on an ARM processor.
Ora, non credo che questa architettura implementi completamente una jvm, immagino che sia solo di appoggio. Se un giorno si sviluppasse in toto però, non saremmo poi così distanti da un os java-based.
nessuno: i linguaggi usati sono quelli. i kernel odierni sono scritti in C con piccole parti di assembly necessarie ad effettuare nelle prime fasi di avvio i settaggi del processore (per esempio per farlo entrare in modalità protetta), nonché per fare I/O diretto sull'hardware. so di un solo kernel scritto in C++, ed era quello di BeOS. dicono che si trattasse di un ottimo sistema operativo e non esito a crederlo, ma purtroppo è fallito.
http://haiku-os.org/
Per il discorso di os basati su java da:
http://www.arm.com/products/CPUs/architecture.html
Ora, non credo che questa architettura implementi completamente una jvm, immagino che sia solo di appoggio. Se un giorno si sviluppasse in toto però, non saremmo poi così distanti da un os java-based.
al momento questa Jazelle è una ottimizzazione degli ARM che però necessita di una VM.
serve a rendere la JVM molto più veloce, ma serve sempre la componente software. questo per ora, in futuro chissà...
nuovoUtente86
02-08-2007, 18:07
la difficoltà nello scrivere in assembly a 16 bit e con quella schifezza di memoria segmentata della modalità reale degli Intel mi pare ovvia :D
è una cosa difficile di per se', è più facile di quanto viene dopo solamente per il fatto che il disco fisso lo leggi usando i servizi del BIOS (perché dopo invece quando sei entrato in modalità protetta a 32 bit il BIOS non funziona più, e là ti ci voglio con l'I/O diretto sull'hard disk :D).
forse hai inteso male la mia domanda,dicevo come mai il codice per lo stage 1 va obbligatoriamente in assembly e nn si puo fare direttamente in C?
Hai qualche link sulla segmentazione intel?
forse hai inteso male la mia domanda,dicevo come mai il codice per lo stage 1 va obbligatoriamente in assembly e nn si puo fare direttamente in C? non è cosa da fare in C: nello scrivere il primo settore di una partizione devi scrivere anche un piccolo header che sta verso l'inizio e che è in un formato determinato dal file system. FAT32 per esempio ha il famoso BPB, BIOS Parameter Block. questo header va scritto manualmente, non c'è modo (o sarebbe comunque un macello) di inserirlo manualmente in un programma scritto in C e convertito a binario puro. a questa complicazione aggiungici anche che questi primi settori della partizione contengono codice che deve avere molto a che fare col BIOS e coi settaggi del processore, tutta roba da trattare obbligatoriamente in assembly: non vale proprio la pena di scriverlo in C, ci si complica la vita.
Hai qualche link sulla segmentazione intel? no ma probabilmente in qualche meandro dei manuali ufficiali dell'architettura Intel si trovano ancora tutti i dettagli necessari, se non altro perché tale architettura prevede che all'accensione il processore sia in modalità reale a 16 bit per ovvi motivi di retrocompatibilità, quindi si tratta di informazioni tuttora necessarie.
nuovoUtente86
03-08-2007, 15:17
non è cosa da fare in C: nello scrivere il primo settore di una partizione devi scrivere anche un piccolo header che sta verso l'inizio e che è in un formato determinato dal file system. FAT32 per esempio ha il famoso BPB, BIOS Parameter Block. questo header va scritto manualmente, non c'è modo (o sarebbe comunque un macello) di inserirlo manualmente in un programma scritto in C e convertito a binario puro. a questa complicazione aggiungici anche che questi primi settori della partizione contengono codice che deve avere molto a che fare col BIOS e coi settaggi del processore, tutta roba da trattare obbligatoriamente in assembly: non vale proprio la pena di scriverlo in C, ci si complica la vita.
ma ipotizzando di avere 2 partizioni,C in Ntfs e D in fat32 l' mbr ' header in tal caso sarà scritto per il tipo compatibile NTFS?Overo in altri termini in caso di piu partizioni il settore mbr a quale FS è soggetto?
ma ipotizzando di avere 2 partizioni,C in Ntfs e D in fat32 l' mbr ' header in tal caso sarà scritto per il tipo compatibile NTFS?Overo in altri termini in caso di piu partizioni il settore mbr a quale FS è soggetto?
il MBR sta nel primo settore, non è soggetto ad alcuno dei file system presenti sulle varie partizioni del disco
nuovoUtente86
28-08-2007, 22:44
il MBR sta nel primo settore, non è soggetto ad alcuno dei file system presenti sulle varie partizioni del disco
L' ho chiesto perchè qui si parlava di file system:
non è cosa da fare in C: nello scrivere il primo settore di una partizione devi scrivere anche un piccolo header che sta verso l'inizio e che è in un formato determinato dal file system. FAT32 per esempio ha il famoso BPB, BIOS Parameter Block. questo header va scritto manualmente, non c'è modo (o sarebbe comunque un macello) di inserirlo manualmente in un programma scritto in C e convertito a binario puro.
Allora il primo settore è soggetto al file system oppure no?
Altra domanda che esula in parte dall' argomento.abbiamo parlato di kernel in C ma gli altri moduli di piu alto livello sono scritti in C o anche in c++,mi riferisco a linux soprattutto.
Allora il primo settore è soggetto al file system oppure no? si, il primo settore di una partizione si, ma l'MBR non sta lì: se c'è sta nei primi settori del disco.
Altra domanda che esula in parte dall' argomento.abbiamo parlato di kernel in C ma gli altri moduli di piu alto livello sono scritti in C o anche in c++,mi riferisco a linux soprattutto. dipende da cosa intendi per "moduli", comunque la risposta generale è: si, anche se in un sistema progettato completamente in C il C++ troverebbe ben poco spazio.
in Windows ci sono componenti non strettamente legati al sistema (utilities, applicativi completamente user-mode) scritti in C++, tipicamente con MFC.
nuovoUtente86
28-08-2007, 23:25
si, il primo settore di una partizione si, ma l'MBR non sta lì: se c'è sta nei primi settori del disco.
dipende da cosa intendi per "moduli", comunque la risposta generale è: si, anche se in un sistema progettato completamente in C il C++ troverebbe ben poco spazio.
in Windows ci sono componenti non strettamente legati al sistema (utilities, applicativi completamente user-mode) scritti in C++, tipicamente con MFC.
Ok,l 'mbr sta nel primo settore del disco ma non dovrebbe essere soggetto al fs ok? ma allora cosa volevi dire qui:?
non è cosa da fare in C: nello scrivere il primo settore di una partizione devi scrivere anche un piccolo header che sta verso l'inizio e che è in un formato determinato dal file system. FAT32 per esempio ha il famoso BPB, BIOS Parameter Block. questo header va scritto manualmente, non c'è modo (o sarebbe comunque un macello) di inserirlo manualmente in un programma scritto in C e convertito a binario puro.
-Mi riferivo a moduli importanti del sistemi,quindi alla fine sia linux che windows sono scritti per la parte principale in C e non in C++,ad esempio però in Linux utility di compressione file,ricerca ecc mi sembrano siano(o quantomeno possono essere scritte )in C++
Ok,l 'mbr sta nel primo settore del disco ma non dovrebbe essere soggetto al fs ok? ma allora cosa volevi dire qui:? precisamente quello che ho scritto a meno di errori. dov'è che vedi controsensi?
-Mi riferivo a moduli importanti del sistemi,quindi alla fine sia linux che windows sono scritti per la parte principale in C e non in C++,ad esempio però in Linux utility di compressione file,ricerca ecc mi sembrano siano(o quantomeno possono essere scritte )in C++ e io che ne so :P
comunque non è ancora chiaro cosa intendi per "moduli importanti"; non che m'interessi per la verità, lo dico per la cronaca.
nuovoUtente86
29-08-2007, 12:08
precisamente quello che ho scritto a meno di errori. dov'è che vedi controsensi?
e io che ne so :P
comunque non è ancora chiaro cosa intendi per "moduli importanti"; non che m'interessi per la verità, lo dico per la cronaca.
-Solitamente l' mbr o meglio il bootmanager scritto nell' mbr si occupa dello stage 1 in pratica va a ricercare il bootloader del sistema che poi si occuperà della parteza vera e propria del sistema.Se ho inteso bene è il bootloader che si trova nella partizione ove è il sistema ad essere soggetto al file system?
-Mi riferisco un po a tutto il sistema quindi alle sue funzioni principali..sicurezza,gestione...fino all' implementazione dei comandi base della shell.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.