perlos2 - Online nel Cloud

PROGRAMMA:

NOME

perlos2 - Perl sotto OS/2, DOS, Win0.3*, Win0.95 e WinNT.

SINOSSI

Si può leggere questo documento nei seguenti formati:

uomo perlos2
visualizza perl perlos2
esploratore perlos2.html
informazioni perlos2

per elencarne alcuni (non tutti potrebbero essere disponibili contemporaneamente), oppure potrebbe essere letto as is: entrambi come
LEGGIMI.os2, o pod/perlos2.pod.

Per leggere il INF versione della documentazione (molto consigliato) al di fuori di OS/2, è necessario un file
Lettore IBM (potrebbe essere disponibile sui siti ftp IBM (?) (URL qualcuno?)) o fornito con PC DOS
7.0 e Visual Age C++ 3.5 di IBM.

Una copia di un visualizzatore Win* è contenuta nel pacchetto "Basta aggiungere OS/2 Warp".

ftp://ftp.software.ibm.com/ps/products/os2/tools/jaow/jaow.zip

in ?:\JUST_ADD\view.exe. Questo dà accesso a EMX INF anche documenti (il formato testo è
disponibile in /emx/doc nella distribuzione di EMX). C'è anche un visualizzatore diverso chiamato
xview.

Tieni presente che se lo hai lynx.exe or netscape.exe installato, puoi seguire i collegamenti WWW da
questo documento dentro INF formato. Se i documenti EMX sono installati correttamente, puoi seguire
collegamenti alla libreria (è necessario che "view emxbook" funzioni impostando l'ambiente "EMXBOOK".
variabile come descritto nei documenti EMX).

DESCRIZIONE

Target
L'obiettivo è rendere OS/2 una delle piattaforme meglio supportate per
utilizzare/costruire/sviluppare Perl e Perl applicazioni, oltre a rendere Perl il migliore
lingua da utilizzare in OS/2. L'obiettivo secondario è provare a farlo funzionare sotto DOS e
Anche Win* (ma no pure difficile).

Lo stato attuale è abbastanza vicino a questo obiettivo. Limitazioni note:

· Alcuni programmi *nix utilizzano forchetta() molto; con le versioni più utili di Perl per OS/2
(ce ne sono diversi creati contemporaneamente) questo è supportato; ma alcuni gusti no
supportano questo (ad esempio, quando Perl viene chiamato dall'interno del REXX). Utilizzando forchetta() dopo usoING
il caricamento dinamico delle estensioni non funzionerebbe molto vecchie versioni di EMX.

· È necessario un eseguibile Perl separato perl__.exe (vedi "perl__.exe") se vuoi usarlo
PM nella tua applicazione (come fanno i moduli Perl/Tk o OpenGL Perl) senza avere un file
finestra in modalità testo presente.

Durante l'utilizzo dello standard perl.exe è possibile anche da una finestra in modalità testo, l'ho fatto
visto casi in cui ciò provoca il degrado della stabilità del sistema. Utilizzando perl__.exe
evita un simile degrado.

· Non esiste un modo semplice per accedere agli oggetti WPS. L'unico modo che conosco è tramite "OS2::REXX"
e le estensioni "SOM" (vedi OS2::REXX, SOM). Tuttavia, non abbiamo accesso a
metodi convenienti di Object-REXX. (È possibile? Non conosco alcun Object-REXX
API.) L'estensione "SOM" (attualmente in testo alfa) potrebbe eventualmente rimuoverlo
discordanza; tuttavia, poiché DII non è supportato dal modulo "SOM",
usare "SOM" non è così conveniente come si vorrebbe.

Si prega di mantenere aggiornato questo elenco informandomi su altri elementi.

Altri OS
Poiché il port OS/2 di perl utilizza un notevole ambiente EMX, può eseguire (e compilare
estensioni e, possibilmente, essere costruito da solo) in qualsiasi ambiente che possa eseguire EMX. IL
l'elenco corrente è DOS, DOS-inside-OS/2, Win0.3*, Win0.95 e WinNT. Tra tanti perl
sapori, solo uno funziona, vedi "perl_.exe".

Tieni presente che non tutte le funzionalità di Perl sono disponibili in questi ambienti. Questo dipende da
le caratteristiche il estendere - molto probabilmente RSX - ha deciso di implementare.

Cfr. "Prerequisiti".

Prerequisiti
EMX È richiesto il runtime EMX (può essere sostituito da RSX). Tieni presente che è possibile
make perl_.exe per funzionare sotto DOS senza alcun supporto esterno tramite associazione
emx.exe/rsx.exe ad esso, vedere "emxbind". Si noti che sotto DOS per ottenere i migliori risultati uno
dovrebbe usare il runtime RSX, che ha molte più funzioni funzionanti (come "fork", "popen"
e così via). Infatti RSX è richiesto se non è presente VCPI. Nota l'RSX
richiede DPMI. Molte implementazioni di DPMI sono note per essere molto difettose, attenzione!

È supportato solo il runtime più recente, attualmente "0.9d fix 03". Perl potrebbe funzionare male
versioni precedenti di EMX, ma questo non è stato testato.

Si possono ottenere diverse parti di EMX, ad esempio

ftp://crydee.sai.msu.ru/pub/comp/os/os2/leo/gnu/emx+gcc/
http://hobbes.nmsu.edu/h-browse.php?dir=/pub/os2/dev/emx/v0.9d/

Il componente runtime dovrebbe avere il nome emxrt.zip.

NOTA. Quando si usa emx.exe/rsx.exe, basta averli sul tuo cammino. Uno lo fa
non è necessario specificarli esplicitamente (anche se this

emx perl_.exe -de 0

funzionerà lo stesso.)

RSX Per eseguire Perl su piattaforme DPMI è necessario il runtime RSX. Questo è necessario sotto
DOS-inside-OS/2, Win0.3*, Win0.95 e WinNT (vedi "Altri sistemi operativi"). RSX non funzionerebbe
solo con VCPI, come farebbe EMX, richiede DMPI.

Avere RSX e l'ultimo sh.exe si ottiene un completamente funzionale * nix-ambiente simile
sotto DOS, ad esempio, "fork", "``" e pipe-"open" funzionano. In effetti, MakeMaker funziona (per
build statica), quindi è possibile avere un ambiente di sviluppo Perl sotto DOS.

Si può ottenere RSX, per esempio

http://cd.textfiles.com/hobbesos29804/disk1/EMX09C/
ftp://crydee.sai.msu.ru/pub/comp/os/os2/leo/gnu/emx+gcc/contributo/

Contatta l'autore su "[email protected]".

L'ultima sh.exe con hook DOS è disponibile in

http://www.ilyaz.org/software/os2/

as sh_dos.zip o con nomi simili che iniziano con "sh", "pdksh" ecc.

HPFS Perl non si preoccupa dei file system, ma la libreria perl contiene molti file con
nomi lunghi, quindi per installarlo intatto è necessario un file system che supporti file lunghi
nomi.

Tieni presente che se non intendi creare il perl stesso, potrebbe essere possibile ingannarsi
EMX per troncare i nomi dei file. Questo non è supportato, leggi i documenti EMX per vedere come fare
esso.

pdksh Per avviare programmi esterni con righe di comando complicate (come con pipe in
tra e/o virgolette di argomenti), Perl utilizza una shell esterna. Con porta EMX
tale shell dovrebbe avere un nome sh.exee situato nel file wired-in-during-compile
luoghi (normalmente F:/bidone) o in una posizione configurabile (vedere "PERL_SH_DIR").

Per ottenere i migliori risultati utilizzare EMX pdksh. Il binario standard (5.2.14 o successivo) funziona sotto DOS
(con "RSX"), vedi

http://www.ilyaz.org/software/os2/

Partenza Perl programmi per OS / 2 (E DOS E...)
Avvia il tuo programma Perl foo.pl con argomenti "arg1 arg2 arg3" allo stesso modo di any
altra piattaforma, di

perl foo.pl arg1 arg2 arg3

Se vuoi specificare le opzioni perl "-my_opts" per il perl stesso (al contrario di your
programma), utilizzare

perl -my_opts foo.pl arg1 arg2 arg3

In alternativa, se usi una shell simile a OS/2, come CMD o 4os2, inserisci quanto segue all'inizio
del tuo script Perl:

extproc perl -S -my_opts

rinomina il tuo programma in pippo.cmde avvialo digitando

pippo arg1 arg2 arg3

Si noti che a causa di stupide limitazioni di OS/2, il percorso completo dello script Perl non lo è
disponibile quando usi "extproc", quindi sei costretto a usare l'opzione perl "-S" e il tuo
lo script dovrebbe trovarsi sul "PERCORSO". Come lato positivo, se conosci il percorso completo del tuo script,
puoi ancora iniziare con

perl ../../blah/foo.cmd arg1 arg2 arg3

(nota che l'argomento "-my_opts" è gestito dalla riga "extproc" nel tuo script,
vedere ""extproc" nella prima riga").

Per capire quanto sopra magia lo fa, leggi i documenti Perl sull'opzione "-S" - vedi perlrun,
e cmdref su "extproc":

visualizza perl perlrun
amico, perlrun
visualizza cmdref extproc
aiuto extproc

o qualunque metodo tu preferisca.

Ci sono anche infinite possibilità di utilizzo eseguibile estensioni di 4os2, associazioni of
WPS e così via... Tuttavia, se usi una shell *nixish (come sh.exe fornito in formato binario
distribuzione), è necessario seguire la sintassi specificata in "Interruttori di comando" in perlrun.

Si noti che -S switch supporta script con estensioni aggiuntive .cmd, .btm, bat, .pl as
bene.

Partenza OS / 2 (E DOS) programmi per Perl
Questo è ciò sistema() (vedi "system" in perlfunc), "``" (vedi "Operatori I/O" in perlop),
e aprire tubo (vedi "open" in perlfunc) servono. (Evitare exec () (vedi "exec" in perlfunc)
a meno che tu non sappia cosa fare).

Tieni presente tuttavia che per utilizzare alcuni di questi operatori è necessario disporre di una shell con sintassi sh
installato (vedi "Pdksh", "Domande frequenti") e perl dovrebbe essere in grado di trovarlo
(vedi "PERL_SH_DIR").

I casi in cui viene utilizzata la shell sono:

1. Un argomento sistema() (vedi "sistema" in perlfunc), exec () (vedi "exec" in perlfunc) con
reindirizzamento o metacaratteri della shell;

2. Pipe-open (vedi "open" in perlfunc) con il comando che contiene il reindirizzamento o
metacaratteri della shell;

3. Backtick "``" (vedi "Operatori I/O" in perlop) con il comando che contiene
reindirizzamento o metacaratteri della shell;

4. Se l'eseguibile chiamato da sistema()/exec ()/tubo-Aperto()/"``" è uno script con l'estensione
"Magia" "#!" linea o linea "extproc" che specifica la shell;

5. Se l'eseguibile chiamato da sistema()/exec ()/tubo-Aperto()/"``" è uno script senza
linea "magica" e $ENV{EXECSHELL} è impostato su shell;

6. Se l'eseguibile chiamato da sistema()/exec ()/tubo-Aperto()/"``" non è stato trovato (non è questo
commento obsoleto?);

7. Per il globbing (vedi "glob" in perlfunc, "Operatori I/O" in perlop) (obsoleto? Perl usa
globbing integrato al giorno d'oggi...).

Per ragioni di velocità in un caso comune, negli algoritmi di cui sopra le barre rovesciate nel file
i nomi dei comandi non sono considerati metacaratteri della shell.

Perl avvia script che iniziano con i cookie "extproc" o "#!" direttamente, senza un
intervento della shell. Perl utilizza lo stesso algoritmo per trovare l'eseguibile di pdsh: Se
il percorso su "#!" la linea non funziona e contiene "/", quindi la parte della directory del file
l'eseguibile viene ignorato e l'eseguibile viene cercato . e su "PERCORSO". Trovare
argomenti per questi script Perl utilizza un algoritmo diverso da pdsh: fino a 3 argomenti
vengono riconosciuti e gli spazi bianchi finali vengono rimossi.

Se uno script non contiene tale cookie, evitare di chiamare sh.exe, Perl utilizza il file
stesso algoritmo di pdsh: se è impostato $ENV{EXECSHELL}, lo script viene fornito per primo
argomento di questo comando, se non impostato, viene utilizzato "$ENV{COMSPEC} /c" (o un
indovina se $ENV{COMSPEC} non è impostato).

Quando si avviano direttamente gli script, Perl utilizza esattamente lo stesso algoritmo utilizzato per la ricerca di
sceneggiatura data da -S opzione della riga di comando: cercherà nella directory corrente, quindi avanti
componenti di $ENV{PATH} utilizzando il seguente ordine di estensioni aggiunte: nessuna estensione,
.cmd, .btm, bat, .pl.

Tieni presente che Perl inizierà a cercare gli script solo se OS/2 non può avviare il file specificato
applicazione, quindi "system 'blah'" non cercherà uno script se è presente un eseguibile
filetto blah.exe ovunque sul "PERCORSO". In altre parole, "PATH" viene essenzialmente cercato due volte:
una volta dal sistema operativo per un eseguibile, quindi da Perl per gli script.

Si noti inoltre che i file eseguibili su OS/2 possono avere un'estensione arbitraria, ma .exe sarà
aggiunto automaticamente se nel nome non è presente alcun punto. La soluzione alternativa è semplice come
quello: da allora bla. e bla denotano lo stesso file (nell'elenco sui file system FAT e HPFS),
per avviare un eseguibile residente nel file n:/bin/bla (nessuna estensione) fornire un argomento
"n:/bin/bla." (punto aggiunto) a sistema().

Perl avvierà i programmi PM dal processo Perl VIO (=modalità testo) in una sessione PM separata;
non è vero il contrario: quando si avvia un programma non PM da un processo PM Perl, Perl
non lo eseguirei in una sessione separata. Se si desidera una sessione separata, assicurarsi
verrà utilizzata quella shell, come in "system 'cmd /c myprog'", oppure avviarla utilizzando optional
argomenti a sistema() documentato nel modulo "OS2::Process". Questo è considerato un
caratteristica.

Frequentemente chiesto

"E ' effettua non è un lavoro"
Le distribuzioni binarie Perl vengono fornite con a testperl.cmd script che tenta di rilevare common
problemi con installazioni errate. C'è una grande possibilità che lo faccia
scopri quale passaggio dell'installazione sei riuscito a sbagliare. ";-)"

I non può eseguire il esterno programmi
· Hai eseguito i programmi con l'opzione "-w"? Vedere "Avvio dei programmi OS/2 (e DOS).
sotto Perl".

· Provi a scappare interno comandi di shell, come "`copia a b`" (interno per cmd.exe),
o "`glob a*b`" (interno per ksh)? Devi specificare la tua shell in modo esplicito, come
"`cmd /c copy a b`", poiché Perl non è in grado di dedurre quali comandi siano interni al file your
conchiglia.

I non può incastrare perl ai miglioramenti my programma, or uso perl.dll da my .
Il tuo programma è compilato EMX con "-Zmt -Zcrtdll"?
Bene, al giorno d'oggi Perl DLL dovrebbe essere utilizzabile anche da un programma compilato diversamente...
Se puoi eseguire codice Perl da script REXX (vedi OS2::REXX), allora ce ne sono altri
aspetto dell'interazione che viene trascurato dall'attuale codice hacker da supportare
programmi principali compilati in modo diverso.

Se tutto il resto fallisce, devi creare una DLL autonoma per perl. Contattami, io
lo ha fatto una volta. Le prese non funzionerebbero, come molte altre cose.

Hai usato ExtUtils::Embed?
Qualche tempo fa ho ricevuto segnalazioni che non funziona. Al giorno d'oggi viene controllato nel test Perl
suite, quindi grep ./T sottodirectory dell'albero di compilazione (così come *.T file in ./ lib
sottodirectory) per scoprire come dovrebbe essere fatto "correttamente".

"``" e tubo-"aperto" do non è un lavoro per DUE.
Potrebbe trattarsi semplicemente di una variante di "Non riesco a eseguire programmi esterni" o di un problema più profondo.
Fondamentalmente: tu bisogno RSX (vedi "Prerequisiti") affinché questi comandi funzionino e potrebbero essere necessari
un porto di sh.exe che comprende gli argomenti del comando. Uno di questi porti è elencato in
"Prerequisiti" in RSX. Non dimenticare di impostare anche la variabile "PERL_SH_DIR".

DPMI è richiesto per RSX.

Impossibile inizia a "trova.exe "modello" file"
L'idea stessa dell'"API C standard per avviare le applicazioni" è che i moduli "foo" e
"foo" degli argomenti del programma sono completamente intercambiabili. Find rompe questo paradigma;

trova il file "modello".
trova il file del modello

non sono equivalenti; Find non può essere avviato direttamente utilizzando l'API precedente. C'è bisogno di un modo
per racchiudere le virgolette doppie in qualche altra costruzione di virgolette, che abbia necessariamente un
shell extra non Unix nel mezzo.

Usa uno di

sistema 'cmd', '/c', 'trova file "modello"';
`cmd /c 'trova il file "modello"'`

Inizierebbe questo Find.exe via cmd.exe tramite "sh.exe" tramite "perl.exe", ma questo è un prezzo da pagare
paga se vuoi utilizzare un programma non conforme.

MONTAGGIO

Automatico binario installazione
Il modo più conveniente per installare una distribuzione binaria di perl è tramite il programma di installazione di perl
install.exe. Basta seguire le istruzioni e il 99% della tristezza dell'installazione scomparirà
lontano.

Tieni presente, tuttavia, che devi avere decomprimere.exe sul tuo percorso e nell'ambiente EMX running.
Quest'ultimo significa che se hai appena installato EMX e apportato tutte le modifiche necessarie
Config.sys, potrebbe essere necessario riavviare nel frattempo. Controlla il runtime di EMX eseguendo

emxrev

Il programma di installazione binario crea anche una cartella sul desktop con alcuni oggetti utili. Se tu
è necessario modificare alcuni aspetti del lavoro del programma di installazione binario, sentiti libero di modificare il file
filetto Perl.pkg. Ciò può essere utile, ad esempio, se è necessario eseguire il programma di installazione più volte e
non voglio apportare molte modifiche interattive alla GUI.

Cose non è un preso che of by automaticamente in Sistemi binario installazione:

"PERL_BADLANG" potrebbe essere necessario se cambi la codepage dopo installazione di perl e il
il nuovo valore non è supportato da EMX. Vedi "PERL_BADLANG".

"PERL_BADFREE" vedere "PERL_BADFREE".

Configurazione.pm Questo file risiede da qualche parte nella posizione in cui hai installato il tuo perl
biblioteca, scoprilo tramite

perl -MConfig -le "print $INC{'Config.pm'}"

Mentre i valori più importanti in questo file sono aggiornato dal binario
programma di installazione, alcuni di essi potrebbero dover essere modificati manualmente. Non conosco tali dati,
per favore tienimi informato se ne trovi uno. Inoltre, le modifiche manuali al file
potrebbe essere necessario accompagnare la versione installata con una modifica di questo file.

NOTA. A causa di un errore di battitura, il programma di installazione binario di 5.00305 installerebbe una variabile
"PERL_SHPATH" in Config.sys. Rimuovi questa variabile e inserisci invece "PERL_SH_DIR".

Manuale binario installazione
A partire dalla versione 5.00305, la distribuzione binaria perl OS/2 è divisa in 11 componenti.
Sfortunatamente, per consentire l'installazione binaria configurabile, i percorsi dei file nei file zip
non sono assoluti, ma relativi ad alcune directory.

Da notare che l'estrazione con i percorsi memorizzati è ancora necessaria (default con unzip,
specificare "-d" per pkunzip). Tuttavia, è necessario sapere dove estrarre i file. Hai bisogno
anche per modificare manualmente le voci in Config.sys per riflettere dove hai messo i file. Nota
che se hai qualche unzipper primitivo (come "pkunzip"), potresti ottenerne molti
avvisi/errori durante la decompressione. Aggiorna a "(w)unzip".

Di seguito è riportato un esempio di cosa fare per riprodurre la configurazione sulla mia macchina. In
VISUALIZZA.EXE puoi premere "Ctrl-Ins" ora e tagliare e incollare dal file risultante -
creato nella directory che hai avviato VISUALIZZA.EXE da.

Per ciascun componente menzioniamo le variabili di ambiente relative a ciascuna installazione
directory. Scegli le directory in modo che corrispondano ai tuoi valori delle variabili, oppure
creare/aggiungere variabili per tenere conto delle directory.

Eseguibili Perl VIO e PM (collegati dinamicamente)
decomprimere perl_exc.zip *.exe *.ico -d f:/emx.add/bin
decomprimere perl_exc.zip *.dll -d f:/emx.add/dll

(hanno le directory con "*.exe" su PATH e "*.dll" su LIBPATH);

Eseguibile Perl_ VIO (collegato staticamente)
decomprimere perl_aou.zip -d f:/emx.add/bin

(avere la directory su PATH);

Eseguibili per le utilità Perl
decomprimere perl_utl.zip -d f:/emx.add/bin

(avere la directory su PATH);

Libreria Perl principale
decomprimere perl_mlb.zip -d f:/perllib/lib

Se questa directory è esattamente uguale al prefisso in cui è stato compilato perl.exe,
non è necessario modificare nulla. Tuttavia, affinché Perl trovi la libreria se usi a
percorso diverso, è necessario "impostare PERLLIB_PREFIX" in Config.sys, vedere "PERLLIB_PREFIX".

Moduli Perl aggiuntivi
decomprimere perl_ste.zip -d f:/perllib/lib/site_perl/5.22.1/

Vale la stessa osservazione di cui sopra. Inoltre, se questa directory non è una di
directory su @INC (e @INC è influenzato da "PERLLIB_PREFIX"), devi inserire questo
directory e sottodirectory ./os2 nella variabile "PERLLIB" o "PERL5LIB". Non usare
"PERL5LIB" a meno che non lo abbia già impostato. Vedi "AMBIENTE" in perl.

[Dai un'occhiata se questo estrazione elenco is ancora applicabile con , il nuovi elenco
La struttura disposizione!]

Strumenti per compilare moduli Perl
decomprimere perl_blb.zip -d f:/perllib/lib

Stessa osservazione di perl_ste.zip.

Manpage per Perl e utilità
decomprimere perl_man.zip -d f:/perllib/man

È meglio che questa directory sia su "MANPATH". Devi avere un lavoro uomo accedere
questi file.

Manpage per i moduli Perl
decomprimere perl_mam.zip -d f:/perllib/man

È meglio che questa directory sia su "MANPATH". È necessario avere un lavoratore per accedere
questi file.

Fonte per la documentazione Perl
decomprimere perl_pod.zip -d f:/perllib/lib

Viene utilizzato dal programma "perldoc" (vedi perldoc) e può essere utilizzato per generare HTML
documentazione utilizzabile dai browser WWW e documentazione in milioni di altri formati:
"info", "LaTeX", "Acrobat", "FrameMaker" e così via. [Utilizzare programmi come pod2latex
eccetera.]

Manuale Perl in INF formato
decomprimere perl_inf.zip -d d:/os2/book

Questa directory dovrebbe essere meglio su "BOOKSHELF".

Pdksh
decomprimere perl_sh.zip -d f:/bidone

Viene utilizzato da perl per eseguire comandi esterni che richiedono esplicitamente la shell, come il
comandi usando reindirizzamento e conchiglia metacaratteri. Viene utilizzato anche al posto di
esplicito /bin/sh.

Imposta "PERL_SH_DIR" (vedi "PERL_SH_DIR") se ti sposti sh.exe dalla posizione di cui sopra.

Nota. Potrebbe essere possibile utilizzare qualche altra shell compatibile con sh (non testata).

Dopo aver installato i componenti necessari e aggiornato il file Config.sys corrispondentemente,
devi modificare manualmente Configurazione.pm. Questo file risiede da qualche parte nel profondo della posizione in cui ti trovi
installato la tua libreria Perl, scoprilo tramite

perl -MConfig -le "print $INC{'Config.pm'}"

È necessario correggere tutte le voci che sembrano percorsi di file (attualmente iniziano con
"F:/").

Avvertenza
L'installazione automatica e manuale del perl lasciano percorsi precompilati all'interno del perl
eseguibili. Sebbene questi percorsi siano sovrascrivibili (vedi "PERLLIB_PREFIX", "PERL_SH_DIR"),
alcune persone potrebbero preferire la modifica binaria dei percorsi all'interno degli eseguibili/DLL.

Accesso documentazione

A seconda di come hai creato/installato Perl potresti avere Perl (altrimenti identico).
documentazione nei seguenti formati:

OS / 2 INF filetto
Molto probabilmente la forma più conveniente. In OS/2 visualizzalo come

visualizza perl
visualizza perl perlfunc
visualizza perl meno
visualizza perl ExtUtils::MakeMaker

(al momento gli ultimi due potrebbero colpire una posizione sbagliata, ma la situazione potrebbe migliorare presto). Sotto Vittoria*
vedi "SINOSSI".

Se vuoi creare i documenti da solo e avere OS / 2 toolkit, correre

pod2ipf > perl.ipf

in /perllib/lib/pod rubrica, quindi

ipfc /inf perl.ipf

(Aspettatevi molti errori durante entrambi i passaggi.) Ora spostatelo sul percorso BOOKSHELF.

pianura testo
Se hai la documentazione Perl nel modulo sorgente, le utilità Perl installate e GNU groff
installato, è possibile utilizzare

perldoc perlfunz
perldoc meno
perldoc ExtUtils::MakeMaker

per accedere alla documentazione di Perl in formato testo (nota che potresti ottenere risultati migliori
utilizzando le manpage Perl).

In alternativa, prova a eseguire pod2text su .sotto File.

Le pagine di manuale
Se ancora non avete partecipato uomo installato sul tuo sistema e hai installato le manpage Perl, usa qualcosa
come questo:

l'uomo funziona
uomo 3 in meno
man ExtUtils.MakeMaker

per accedere alla documentazione per i diversi componenti di Perl. Iniziare con

uomo perl

Nota che il punto (.) viene utilizzato come separatore di pacchetti per la documentazione per i pacchetti e come
al solito, a volte è necessario fornire la sezione - 3 sopra - per evitare l'ombra da parte del
meno(1) pagina man.

Assicurati che la directory sopra la directory con le pagine man è sul nostro "MANPATH", come
questo

impostare MANPATH=c:/man;f:/perllib/man

per le pagine man Perl in "f:/perllib/man/man1/" ecc.

HTML
Se hai qualche browser WWW disponibile, installa la documentazione Perl nel sorgente
form e le utilità Perl, puoi creare documenti HTML. Cd nella directory con .sotto file e farlo
in questo modo

cdf:/perllib/lib/pod
pod2html

Dopodiché puoi indirizzare il file al tuo browser perl.html in questa directory e vai avanti
con la lettura di documenti, come questo:

esplora file:///f:/perllib/lib/pod/perl.html

In alternativa potresti essere in grado di ottenere questi documenti precompilati da CPAN.

GNU "Informazioni" file
Gli utenti di Emacs lo apprezzerebbero molto, soprattutto con la modalità "CPerl" caricata. Voi
è necessario ottenere l'ultimo "pod2texi" da "CPAN" o, in alternativa, le pagine informative predefinite.

PDF file
per "Acrobat" sono disponibili su CPAN (potrebbe essere per una versione leggermente precedente di Perl).

"LaTeX" docs
può essere costruito usando "pod2latex".

COSTRUIRE

Qui discuteremo come compilare Perl sotto OS/2.

. corto storia
Supponiamo che tu sia un facchino esperto, quindi assicurati di avere tutti gli strumenti necessari
già presente sul tuo sistema e sai come ottenere la distribuzione dei sorgenti Perl.
Scompattatelo, passate alla directory di estrazione e

gnupatch -p0 < os2\diff.configure
sh Configura -des -D prefisso=f:/perllib
make
fare il test
make install
fai aout_test
crea aout_install

Questo inserisce gli eseguibili in f:/perllib/bin. Spostarli manualmente nel "PERCORSO", manualmente
spostare il costruito perl*.dll in "LIBPATH" (qui per Perl DLL * è un esagono non molto significativo
checksum) ed esegui

make installcmd INSTALLCMDDIR=d:/ir/on/percorso

Supponendo che i file "man" siano stati inseriti in una posizione appropriata, questo completa il file
installazione del sistema Perl minimo. (La distribuzione binaria ne contiene anche molti
moduli aggiuntivi e la documentazione in formato INF.)

Quella che segue è una guida dettagliata attraverso questi passaggi.

Prerequisiti
È necessario disporre dell'ambiente di sviluppo EMX più recente, della suite completa di strumenti GNU (gawk
rinominato in awk e GNU Find.exe prima sul percorso rispetto a OS/2 Find.exe, Lo stesso con
sort.exe, per verificarne l'utilizzo

trova --version
sort --version

). Hai bisogno dell'ultima versione di pdsh installato come sh.exe.

Controlla di averlo fatto BSD librerie e intestazioni installate e, facoltativamente, Berkeley DB
intestazioni e librerie e cripta.

Possibili posizioni per ottenere i file:

ftp://ftp.uni-heidelberg.de/pub/os2/unix/
http://hobbes.nmsu.edu/h-browse.php?dir=/pub/os2
http://cd.textfiles.com/hobbesos29804/disk1/DEV32/
http://cd.textfiles.com/hobbesos29804/disk1/EMX09C/

È stato riportato che i seguenti archivi contengono abbastanza utilità per compilare Perl:
gnufutil.zip, gnusutil.zip, gnututil.zip, gnused.zip, gnupatch.zip, gnuawk.zip,
gnumake.zip, gnugrep.zip, bsddev.zip e ksh527rt.zip (o una versione successiva). Nota che tutto
queste utilità sono disponibili presso LEO:

ftp://crydee.sai.msu.ru/pub/comp/os/os2/leo/gnu/

Nota anche che il db.lib e db.a della distribuzione EMX non sono adatti per multi-
compilazione threaded (anche la versione a thread singolo di Perl utilizza C RTL multi-thread, per
compatibilità con XFree86-OS/2). Ottienine uno corretto da

http://www.ilyaz.org/software/os2/db_mt.zip

Se ancora non avete partecipato di preciso , il stesso versione of Perl già installato, assicurarsi che non siano presenti copie
o perl sono attualmente in esecuzione. I passaggi successivi della build potrebbero non riuscire a partire da una versione precedente
of perl.dll caricati in memoria potrebbero essere trovati. L'esecuzione di "make test" diventa priva di significato,
poiché il test sta verificando una build precedente di Perl (questa situazione viene rilevata e
riportato da lib/os2_base.t test). Non dimenticare di disattivare "PERL_EMXLOAD_SEC" in
ambiente.

Assicurati anche di averlo / Tmp directory sull'unità corrente e . directory nella tua
"LIBPATH". Si può provare a correggere quest'ultima condizione

imposta BEGINLIBPATH .\.

se usi qualcosa del genere CMD.EXE o le ultime versioni di 4os2.exe. (Impostazione BEGINLIBPATH
solo per "." viene ignorato dal kernel OS/2.)

Assicurati che il tuo gcc sia valido per il collegamento "-Zomf": esegui lo script "omflibs". /emx/lib
directory.

Verifica di aver installato link386. Viene fornito di serie con OS/2, ma potrebbe non esserlo
installato a causa della personalizzazione. Se si digita

link386

mostra che non ce l'hai, fallo Selettivo installe scegli "Collega moduli oggetto" in
Opzionale sistema utilità/Altro. Se accedi ai prompt di link386, premi "Ctrl-C" per uscire.

ottenere perl source
Devi recuperare l'ultima fonte Perl (incluse le versioni degli sviluppatori). Con qualche
probabilità in cui si trova

http://www.cpan.org/src/
http://www.cpan.org/src/unsupported

In caso contrario, potrebbe essere necessario scavare negli indici per trovarlo nella directory corrente
manutentore.

Il ciclo rapido di rilascio degli sviluppatori potrebbe interrompere di tanto in tanto la build di OS/2, esaminando

http://www.cpan.org/ports/os2/

può indicare l'ultima versione rilasciata pubblicamente dal manutentore. Notare che
il rilascio potrebbe includere alcune patch aggiuntive da applicare all'attuale sorgente di perl.

Estrailo così

tar vzxf perl5.00409.tar.gz

Potresti visualizzare un messaggio relativo agli errori durante l'estrazione Configurazione. Questo perché esiste un
conflitto con un file con nome simile configure.

Passare alla directory di estrazione.

Applicazioni of , il patch
È necessario applicare le patch ./os2/diff.* come questo:

gnupatch -p0 < os2\diff.configure

Potrebbe anche essere necessario applicare le patch fornite con la distribuzione binaria di perl. Esso
ha senso anche consultare la mailing list di perl5-porters per le ultime novità relative a OS/2
patch (vedi <http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/>). Tali patch
di solito contengono le stringhe "/os2/" e "patch", quindi ha senso cercare queste stringhe.

Modifica manuale
Potresti esaminare il file ./hints/os2.sh e correggi qualsiasi cosa sbagliata che trovi lì. Io faccio
non aspettarti che sia necessario da nessuna parte.

Fare
sh Configura -des -D prefisso=f:/perllib

"prefisso" significa: dove installare la libreria perl risultante. Fornendo il prefisso corretto puoi
evitare la necessità di specificare "PERLLIB_PREFIX", vedere "PERLLIB_PREFIX".

ignorare , il messaggio informazioni mancante "ln", e informazioni "-C" opzione a tr. Quest'ultimo è il massimo
probabilmente già risolto, se lo vedi e riesci a rintracciare dove quest'ultimo avviso spurio
proviene, per favore informami.

Ora

make

Ad un certo punto il costruito potrebbe morire, riportando a versione mancata corrispondenza or incapace a eseguire il perl.
Ciò significa che non ce l'hai . nel tuo LIBPATH, quindi perl.exe non riesce a trovare il necessario
perl67B2.dll (trattare queste cifre esadecimali come rumore di linea). Dopo che questo è stato risolto, la build dovrebbe
finire senza troppe storie.

Testing
Ora corri

fare il test

Tutti i test dovrebbero avere esito positivo (alcuni saltati). Se hai la stessa versione di
Perl installato, è fondamentale che tu abbia "." all'inizio del tuo LIBPATH (o in
BEGINLIBPATH), altrimenti i vostri test molto probabilmente testeranno la versione sbagliata di Perl.

Alcuni test potrebbero generare messaggi aggiuntivi simili a

Un sacco di "cattivi gratuiti"
nei test del database relativi a Berkeley DB. Questo dovrebbero be fisso già. Se
persiste, puoi disabilitare questi avvisi, vedi "PERL_BADFREE".

Processo terminato da SIGTERM/SIGINT
Questo è un messaggio standard emesso dalle applicazioni OS/2. Le applicazioni *nix muoiono
silenzio. È considerata una caratteristica. Si può facilmente disabilitarlo in modo appropriato
segnalatori.

Tuttavia, il motore di test visualizza questi messaggi sullo schermo in momenti inaspettati. Due
messaggi di questo genere dovrebbero essere presente durante le prove.

Per ottenere rapporti di prova più dettagliati, chiamare

perl t/imbracatura

Il rapporto con io/tubo.t il fallimento potrebbe assomigliare a questo:

Stato test non riuscito Wstat Totale Fail Failed Elenco dei test non riusciti
-------------------------------------------------- ----------
io/tubo.t 12 1 8.33% 9
7 test saltati, più 56 sottotest saltati.
Script di test 1/195 non riusciti, 99.49% ok. 1/6542 sottotest falliti, 99.98% ok.

I motivi dei test saltati più importanti sono:

op/fs.t
18 Controlla "atime" e "mtime" di "stat()" - sfortunatamente, HPFS fornisce solo
Granularità temporale di 2 secondi (per compatibilità con FAT?).

25 Controlla "truncate()" su un filehandle appena aperto in scrittura - non so perché
questo dovrebbe o non dovrebbe funzionare.

op/stat.t
Controlla "stat()". Test:

4 Controlla "atime" e "mtime" di "stat()" - sfortunatamente, HPFS fornisce solo
Granularità temporale di 2 secondi (per compatibilità con FAT?).

Installazione , il costruito perl
Se non hai ancora spostato "perl*.dll" su LIBPATH, fallo adesso.

Correre

make install

Metterebbe i file generati nelle posizioni necessarie. Inserito manualmente perl.exe, perl__.exe
e perl___.exe in una posizione sul tuo PERCORSO, perl.dll in una posizione sul tuo LIBPATH.

Correre

make installcmd INSTALLCMDDIR=d:/ir/on/percorso

in cui convertire le utilità Perl .cmd file e metterli su PATH. Devi mettere
. EXE-utilità sul percorso manualmente. Sono installati in "$prefix/bin", qui $prefix è cosa
hai dato a Configurazione, vedere "Realizzazione".

Se usi "man", sposta il file installato */Uomo/ directory nel tuo "MANPATH", o
modificare "MANPATH" in modo che corrisponda alla posizione. (Si sarebbe potuto evitare questo fornendo a
correggere l'opzione "manpath" su . / Configureo modifica ./config.sh tra la configurazione e
fare dei passi.)

in stile "a.out". costruire
Procedi come sopra, ma fai perl_.exe (vedi "perl_.exe") di

crea perl_

testare e installare tramite

fai aout_test
crea aout_install

Inserito manualmente perl_.exe in una posizione sul tuo PERCORSO.

Nota. Il processo di compilazione per "perl_" effettua non è un sapere su tutte le dipendenze, quindi tu
dovrebbe assicurarsi che tutto sia aggiornato, ad esempio, facendo

crea perl_dll

prima.

Costruzione a binario distribuzione

[Questa sezione fornisce solo una breve panoramica...]

La compilazione dovrebbe procedere diversamente a seconda della versione di Perl installata
è già presente e utilizzato sul tuo sistema oppure è una nuova versione non ancora utilizzata. IL
la descrizione seguente presuppone che la versione sia nuova, quindi installando le sue DLL e .pm file
non interromperà il funzionamento del tuo sistema anche se non sono ancora presenti alcuni passaggi intermedi
completamente funzionante.

Gli altri casi richiedono procedure un po’ più contorte. Di seguito suppongo che il
la versione attuale di Perl è la 5.8.2, quindi gli eseguibili sono chiamati di conseguenza.

1. Costruisci e testa completamente la distribuzione Perl. Assicurati che nessun test abbia esito negativo
obiettivi "test" e "aout_test"; correggere i bug rilevati in Perl e nella suite di test Perl
da questi test. Assicurati che "all_test" renda il target eseguito il più pulito possibile.
Controllare che os2/perlrexx.cmd funziona bene.

2. Installa completamente Perl, incluso il target "installcmd". Copia le DLL generate in
"LIBPATH"; copiare gli eseguibili Perl numerati (come in perl5.8.2.exe) a "PERCORSO"; copia
"perl_.exe" in "PERCORSO" come "perl_5.8.2.exe". Pensa se hai bisogno di indietro-
DLL di compatibilità. Nella maggior parte dei casi non è ancora necessario installarli; ma qualche volta
questo potrebbe semplificare i passaggi successivi.

3. Assicurarsi che "CPAN.pm" possa scaricare file da CPAN. In caso contrario, potrebbe essere necessario
installare manualmente "Net::FTP".

4. Installa il pacchetto "Bundle::OS2_default"

perl5.8.2 -MCPAN -e "installa bundle::OS2_default" < nul |& tee 00cpan_i_1

L'operazione potrebbe richiedere un paio d'ore con un processore da 1 GHz (quando eseguito per la prima volta). E questo
non dovrebbe essere necessariamente una procedura agevole. Alcuni moduli potrebbero non specificare obbligatorio
dipendenze, quindi potrebbe essere necessario ripetere questa procedura più volte fino a quando non vengono visualizzati i risultati
stabilizzare.

perl5.8.2 -MCPAN -e "installa bundle::OS2_default" < nul |& tee 00cpan_i_2
perl5.8.2 -MCPAN -e "installa bundle::OS2_default" < nul |& tee 00cpan_i_3

Anche dopo essersi stabilizzati, alcuni test potrebbero fallire.

Correggi il maggior numero possibile di bug scoperti. Documentare tutti i bug che non sono stati risolti,
e tutti i fallimenti con ragioni sconosciute. Ispezionare i registri prodotti 00cpan_i_1 a
trovare test saltati in modo sospetto e altri eventi sospetti.

Tieni presente che installazione anche alcuni moduli potrebbero fallire: ad esempio, le DLL a
l'aggiornamento potrebbe essere già caricato da CPAN.pm. Ispezionare i log di "installazione" (nell'esempio
sopra 00cpan_i_1 ecc.) per errori e installare le cose manualmente, come in

cd $CPANHOME/.cpan/build/Digest-MD5-2.31
make install

Alcune distribuzioni potrebbero fallire alcuni test, ma potresti voler installarle comunque (come
sopra o tramite il comando "forza installazione" della modalità shell "CPAN.pm").

Poiché il completamento di questa procedura potrebbe richiedere molto tempo, è opportuno farlo
"congelare" la configurazione del CPAN disabilitando gli aggiornamenti periodici della copia locale di
Indice CPAN: imposta "index_expire" su un valore elevato (io uso 365), quindi salva le impostazioni

CPAN> o conf indice_scadenza 365
CPAN> o conf commit

Ripristina il valore predefinito 1 al termine.

5. Una volta soddisfatti dei risultati, eseguire nuovamente il target "installcmd". Ora puoi copiare
"perl5.8.2.exe" in "perl.exe" e installa gli altri eseguibili di OMF-build:
"perl__.exe" ecc. Sono pronti per essere utilizzati.

6. Passa alla directory "./pod" dell'albero di compilazione, scarica il logo Perl
CamelGrayBig.BMP, e corri

( perl2ipf > perl.ipf ) |& tee 00ipf
ipfc /INF perl.ipf |& tee 00inf

Questo produce il libro online della documentazione Perl "perl.INF". Installa nel percorso "BOOKSHELF".

7. Ora è il momento di creare un eseguibile collegato staticamente perl_.exe che include recentemente-
installato tramite i moduli "Bundle::OS2_default". Fare test tramite "CPAN.pm" lo farà
essere dolorosamente lento, poiché collega staticamente un nuovo eseguibile per estensione XS.

Ecco una possibile soluzione alternativa: creare un file toplevel Makefile.PL in $CPANHOME/.cpan/build/
con i contenuti (confrontare con "Creazione di eseguibili con una raccolta personalizzata di
estensioni caricate staticamente")

usa ExtUtils::MakeMaker;
WriteMakefile NOME => 'fittizio';

esegui questo come

perl_5.8.2.exe Makefile.PL
make -k tutto prova

Ancora una volta, questa procedura non dovrebbe essere assolutamente fluida. Sono presenti alcuni "Makefile.PL".
le sottodirectory potrebbero contenere bug e non verranno eseguite come script "figli". IL
l'interdipendenza dei moduli può colpirti; tuttavia, poiché i moduli non XS lo sono già
installato, i prerequisiti della maggior parte dei moduli hanno ottime probabilità di essere presenti.

Se scopri alcuni problemi, sposta le directory dei moduli problematici in una diversa
posizione; se questi moduli non sono moduli XS, puoi semplicemente ignorarli: lo sono
già installato; i restanti moduli XS devono essere installati manualmente uno per uno.

Dopo ciascuna di queste rimozioni è necessario eseguire nuovamente il processo "Makefile.PL"/"make"; Generalmente
questa procedura converge presto. (Ma assicurati di convertire tutti i file C
biblioteche da lib formatta a .a formato: esegui uno dei

emxaout foo.lib
emximp -o foo.a foo.lib

a seconda di quale sia appropriato.) Inoltre, assicurati che le DLL per le librerie esterne lo siano
utilizzabile con eseguibili compilati senza opzioni "-Zmtd".

Quando sei sicuro che solo poche sottodirectory portano a errori, potresti voler aggiungere
Opzione "-j4" per "make" per accelerare il salto delle sottodirectory con già finito
costruire.

Quando sei soddisfatto dei risultati dei test, installa le librerie build C per
estensioni:

make install |& tee 00aout_i

Ora puoi rinominare il file ./perl.exe generato durante l'ultima fase a
perl_5.8.2.exe; posizionarlo su "PERCORSO"; se esiste un'interdipendenza tra alcuni XS
moduli, potrebbe essere necessario ripetere il ciclo "test"/"installa" con questo nuovo eseguibile e
alcuni moduli esclusi - finché la procedura non converge.

Ora hai tutto il necessario .a librerie per questi moduli Perl nei luoghi in cui
Il costruttore Perl può trovarlo. Usa il builder perl: passa a una directory vuota, crea
un "manichino" Makefile.PL ancora una volta e scappa

perl_5.8.2.exe Makefile.PL |& tee 00c
make perl |& tee 00p

Questo dovrebbe creare un eseguibile ./perl.exe con tutte le estensioni caricate staticamente
integrato. Confronta il generato perlmain.c file per assicurarsi che durante il
iterazioni il numero di estensioni caricate non fa altro che aumentare. Rinominare ./perl.exe a
perl_5.8.2.exe sul "PERCORSO".

Quando converge, ottieni una variante funzionale di perl_5.8.2.exe; copialo in
"perl_.exe". La generazione dell'installazione Perl locale è terminata.

8. Assicurarsi che i moduli installati siano effettivamente installati nella posizione del nuovo
Perl, e non sono ereditati dalle voci di @INC date in eredità dal precedente
versioni di Perl: imposta "PERLLIB_582_PREFIX" per reindirizzare la nuova versione di Perl a
nuova posizione e copiare i file installati in questa nuova posizione. Rifare i test a
assicurati che le versioni dei moduli ereditate dalle versioni precedenti di Perl non lo siano
necessario.

In realtà, l'output del registro di pod2ipf(1) durante il passaggio 6 fornisce informazioni molto dettagliate
su quali moduli vengono caricati da quale luogo; quindi puoi usarlo come aggiuntivo
strumento di verifica.

Controlla che alcuni file temporanei non siano stati inseriti nell'albero di installazione di Perl. Correre
qualcosa del genere

ptrova . -f "!(/\.(pm|pl|ix|al|h|a|lib|txt|pod|imp|bs|dll|ld|bs|inc|xbm|yml|cgi|uu|e2x|salta |packlist|eg|cfg|html|pub|enc|all|ini|po|pot)$/i o /^\w+$/") | meno

nell'albero di installazione (sia quello superiore che quello sitelib uno).

Comprimi tutte le DLL con lxlite. Il minuscolo .exe può essere compresso con "/c:max" (il
il bug appare solo quando c'è una correzione negli ultimi 6 byte di una pagina (?); dal
piccoli eseguibili sono molto più piccoli di una pagina, il bug non verrà colpito). Non comprimere
"perl_.exe" - non funzionerebbe sotto DOS.

9. Ora puoi generare la distribuzione binaria. Questo viene fatto eseguendo il test di
Distribuzione CPAN "OS2::SoftInstaller". Ottimizza il file prova.pl per adattarsi al layout
prima della versione attuale di Perl. Non dimenticare di comprimere le DLL esterne necessarie
di conseguenza. Potresti includere la descrizione dei bug e degli errori della suite di test
non aggiustare. Include le versioni small-stack degli eseguibili Perl da Perl build
directory.

Includere perl5.def in modo che le persone possano ricollegare la DLL perl preservando il binario
compatibilità o può creare DLL di compatibilità. Includere i file diff ("diff -pu
vecchio nuovo") delle correzioni apportate in modo che le persone possano ricostruire la tua versione. Include perl5.map
in modo da poter utilizzare il debug remoto.

10. Condividi ciò che hai fatto con le altre persone. Relax. Goditi i frutti del tuo lavoro.

11. Preparati per ringraziamenti, segnalazioni di bug, messaggi di odio e spam che arriveranno come risultato del
passo precedente. Nessuna buona azione deve restare impunita!

Costruzione costume . EXE file

Gli eseguibili Perl possono essere facilmente ricostruiti in qualsiasi momento. Inoltre, è possibile utilizzare il file
incorporamento (vedi perlembed) per realizzare eseguibili molto personalizzati.

Fare eseguibili con a costume collezione of staticamente caricato estensioni
È un po' più facile farlo mentre decrescente l'elenco dei caricati staticamente
estensioni. Discutiamo questo caso solo qui.

1. Passare a una directory vuota e creare un segnaposto :

usa ExtUtils::MakeMaker;
WriteMakefile NOME => 'fittizio';

2. Eseguilo con il sapore di Perl (perl.exe or perl_.exe) che vuoi ricostruire.

perl_ Makefile.PL

3. Chiedigli di creare un nuovo eseguibile Perl:

fare perl

(potrebbe essere necessario aggiungere manualmente "PERLTYPE=-DPERL_CORE" a questa riga di comando su alcuni
versioni di Perl; il sintomo è che il globbing della riga di comando non funziona
Shell OS/2 con l'eseguibile appena compilato; controllare con

.\perl.exe -wle "stampa per @ARGV" *

).

4. Il passaggio precedente creato perlmain.c che contiene un elenco di nuovoXS() chiama vicino al
FINE. Rimozione delle chiamate non necessarie e riesecuzione

fare perl

produrrà un eseguibile personalizzato.

Fare eseguibili con a costume percorsi di ricerca
L'eseguibile perl predefinito è sufficientemente flessibile da supportare la maggior parte degli utilizzi. Tuttavia, si può
vuoi qualcosa di ancora più flessibile; ad esempio, potresti voler trovare la DLL Perl relativa a
la posizione del file EXE; oppure si potrebbe voler ignorare l'ambiente quando si imposta il file
Patch di ricerca della libreria Perl, ecc.

Se ti senti a tuo agio con incorporamento interfaccia (vedi perlembed), queste cose sono facili da
ripetere i passaggi descritti in "Creazione di eseguibili con una raccolta personalizzata di
estensioni caricate staticamente" e apportando modifiche più complete ai file principale() of perlmain.c.
Le persone con poca voglia di capire Perl possono semplicemente rinominarlo principale()e fare il necessario
modifica in un'abitudine principale() che chiama la funzione rinominata al momento opportuno.

Tuttavia, esiste un terzo modo: la DLL perl esporta il file principale() funzione e diversi callback
per personalizzare il percorso di ricerca. Di seguito è riportato un esempio completo di un "caricatore Perl" che

1. Cerca la DLL Perl nella directory "$exedir/../dll";

2. Antepone la directory precedente a "BEGINLIBPATH";

3. Fallisce se la DLL Perl trovata tramite "BEGINLIBPATH" è diversa da quella caricata su
passo 1; ad esempio, un altro processo potrebbe averlo caricato da "LIBPATH" o da un altro
valore di "BEGINLIBPATH". In questi casi è necessario modificare le impostazioni del sistema
in modo che quest'altro processo non venga eseguito o carichi la DLL da "BEGINLIBPATH"
con "LIBPATHSTRICT=T" (disponibile con i kernel dopo settembre 2000).

4. Carica la libreria Perl da "$exedir/../dll/lib/".

5. Utilizza la Bourne shell da "$exedir/../dll/sh/ksh.exe".

Per ottenere i migliori risultati, compila il file C seguente con le stesse opzioni della DLL Perl. Tuttavia,
molte funzionalità funzioneranno anche se l'eseguibile non è un'applicazione EMX, ad esempio,
se compilato con

gcc -Wall -DDOSISH -DOS2=1 -O2 -s -Zomf -Zsys perl-starter.c \
-DPERL_DLL_BASENAME=\"perl312F\" -Zstack 8192 -Zlinker /PM:VIO

Ecco il file C di esempio:

#definire INCL_DOS
#definire INCL_NOPM
/* Sono necessari per la compilazione se os2.h include os2tk.h, non os2emx.h */
#define INCL_DOSPROCESS
#include

#include "EXTERN.h"
#definisce PERL_IN_MINIPERLMAIN_C
#include "perl.h"

carattere statico *me;
Maniglia HMODULE;

vuoto statico
die_with(char *msg1, char *msg2, char *msg3, char *msg4)
{
ULONG c;
char *s = "errore:";

DosWrite(2, io, strlen(io), ecc);
DosWrite(2, s, strlen(s), &c);
DosWrite(2, msg1, strlen(msg1), ecc);
DosWrite(2, msg2, strlen(msg2), ecc);
DosWrite(2, msg3, strlen(msg3), ecc);
DosWrite(2, msg4, strlen(msg4), ecc);
DosWrite(2, "\r\n", 2, &c);
exit(255);
}

typedef ULONG (*fill_extLibpath_t)(int tipo, char *pre, char *post, int sostituisci, char *msg);
typedef int (*main_t)(int tipo, char *argv[], char *env[]);
typedef int (*handler_t)(void* dati, int which);

#ifndef PERL_DLL_BASENAME
# definisce PERL_DLL_BASENAME "perl"
#endif

MODULO H statico
caricamento_perl_dll(char *nomebase)
{
char buf[300], fail[260];
STRLEN lo, dirl;
fill_extLibpath_t f;
ULONG rc_nome completo;
Maniglia HMODULE, maniglia1;

if (_execname(buf, sizeof(buf) - 13) != 0)
die_with("Impossibile trovare il percorso completo: ", strerror(errno), "", "");
/* XXXX Compila 'me' con il nuovo valore */
l = strlen(buf);
while (l && buf[l-1] != '/' && buf[l-1] != '\\')
l--;
dirl = l - 1;
strcpy(buf + l, nomebase);
l += strlen(nomebase);
strcpy(buf + l, ".dll");
if ( (rc_fullname = DosLoadModule(fail, sizeof fail, buf, &handle)) != 0
&& DosLoadModule(fail, sizeof fail, basename, &handle) != 0 )
die_with("Impossibile caricare la DLL ", buf, "", "");
se (rc_nome completo)
maniglia di ritorno; /* è stato caricato con un nome breve; va tutto bene */
if (DosQueryProcAddr(handle, 0, "fill_extLibpath", (PFN*)&f))
die_with(buf, ": la DLL non esporta simboli", "fill_extLibpath", "");
bu[dir] = 0;
if (f(0 /*BEGINLIBPATH*/, buf /* anteponi */, NULL /* aggiungi */,
0 /* mantiene il vecchio valore */, io))
die_with(me, ": anteponendo BEGINLIBPATH", "", "");
if (DosLoadModule(fail, sizeof fail, basename, &handle1) != 0)
die_with(me, ": ricerca di nuovo della DLL perl tramite BEGINLIBPATH", "", "");
buf[dirl] = '\\';
se (maniglia1!= maniglia) {
if (DosQueryModuleName(handle1, sizeof(fail), fail))
strcpy(fallire, "???");
die_with(buf, ":\n\tperl DLL tramite BEGINLIBPATH è diverso: \n\t",
fallire,
"\n\tPotrebbe essere necessario manipolare BEGINLIBPATH e LIBPATHSTRICT globali"
"\n\tin modo che l'altra copia venga caricata tramite BEGINLIBPATH.");
}
maniglia di ritorno;
}

int
main(int argc, char **argv, char **env)
{
main_t f;
gestore_t h;

io = argv[0];
/ ** /
handle = load_perl_dll(PERL_DLL_BASENAME);

if (DosQueryProcAddr(handle, 0, "Perl_OS2_handler_install", (PFN*)&h))
die_with(PERL_DLL_BASENAME, ": La DLL non esporta simboli", "Perl_OS2_handler_install", "");
if ( !h((void *)"~installprefix", Perlos2_handler_perllib_from)
|| !h((void *)"~dll", Perlos2_handler_perllib_to)
|| !h((void *)"~dll/sh/ksh.exe", Perlos2_handler_perl_sh) )
die_with(PERL_DLL_BASENAME, ": Impossibile installare i manipolatori @INC", "", "");

if (DosQueryProcAddr(handle, 0, "dll_perlmain", (PFN*)&f))
die_with(PERL_DLL_BASENAME, ": La DLL non esporta simboli", "dll_perlmain", "");
return f(argc, argv, env);
}

Silhouette FAQ

Alcuni "/" è diventato "\" in pdksh.
Hai un pdksh molto vecchio. Vedere "Prerequisiti".

'errno' - irrisolto esterno
Non hai MT-safe db.lib. Vedere "Prerequisiti".

Problematica con tr or sete
segnalato con una versione molto vecchia di tr e sed.

Alcuni problema (dimenticare quale ;-)
Hai una versione precedente di perl.dll sul tuo LIBPATH, che ha interrotto la creazione di
estensioni.

Biblioteca ... non è un essere trovato
Non hai eseguito "omflibs". Vedere "Prerequisiti".

Segfault in make
Utilizzi una vecchia versione di GNU make. Vedere "Prerequisiti".

op/sprintf test fallimento
Ciò può derivare da un bug in emx sprintf che è stato corretto nella correzione 0.9d 03.

Specifica (dis)caratteristiche of OS / 2 porto

"imposta priorità", "prendi priorità"
Da notare che queste funzioni sono compatibili con *nix, non con i port più vecchi del '94 - 95.
Le priorità sono assolute, vanno da 32 a -95, più bassa è più veloce. 0 è l'impostazione predefinita
priorità.

AVVERTIMENTO. Chiamare "getpriority" su un processo inesistente potrebbe bloccare il sistema in precedenza
Pacchetto di correzione Warp3. A partire da Warp22, Perl utilizzerà una soluzione alternativa: interrompe ottieni priorità()
se il processo non è presente. Ciò non è possibile nelle versioni precedenti "2.*" e ha a
comunque condizioni di gara.

"sistema()"
La forma con più argomenti di "system()" consente un argomento numerico aggiuntivo. Il significato di
questo argomento è descritto in OS2::Process.

Quando trova un programma da eseguire, Perl chiede innanzitutto al sistema operativo di cercare gli eseguibili su "PATH"
(OS/2 aggiunge l'estensione .exe se non è presente alcuna estensione). Se non lo trova, cerca a
script con possibili estensioni aggiunte in questo ordine: nessuna estensione, .cmd, .btm, bat, .pl.
Se trovato, Perl controlla l'inizio del file per le stringhe magiche "#!" e "extproc". Se
trovato, Perl utilizza il resto della prima riga come inizio della riga di comando da eseguire
questa sceneggiatura. L'unica alterazione apportata alla prima riga è l'estrazione degli argomenti
(attualmente fino a 3) e ignorando la parte del percorso del nome "interprete" se non può
essere trovato utilizzando il percorso completo.

Ad esempio, "system 'foo', 'bar', 'baz'" può portare Perl a trovare C:/emx/bin/foo.cmd con la
essere la prima linea

extproc / bin / bash -x -c

If /bin/bash.exe non viene trovato, Perl cerca un eseguibile bash.exe sul "PERCORSO". Se
trovato in C:/emx.add/bin/bash.exe, quindi quanto sopra sistema() è tradotto in

sistema qw(C:/emx.add/bin/bash.exe -x -c C:/emx/bin/foo.cmd bar baz)

Viene eseguita un'ulteriore traduzione: invece di /bin/sh Perl utilizza il metodo cablato o
shell personalizzata (vedi "PERL_SH_DIR").

La ricerca di cui sopra per "interprete" è ricorsiva: if bash l'eseguibile non è stato trovato, ma
bash.btm viene trovato, Perl esaminerà la sua prima riga, ecc. L'unico limite cablato su
la profondità di ricorsione è implicita: c'è un limite 4 al numero di argomenti aggiuntivi
inserito prima degli argomenti effettivi forniti sistema(). In particolare, se non aggiuntivo
gli argomenti sono specificati nelle prime righe "magiche", quindi il limite di profondità è 4.

Se Perl rileva che l'eseguibile trovato è di tipo PM mentre la sessione corrente non lo è, lo fa
avvierà il nuovo processo in una sessione separata di tipo necessario. Chiama tramite
"OS2::Process" per disabilitare questa magia.

AVVERTIMENTO. A causa della logica descritta, è necessario specificarlo esplicitamente .com estensione se
necessario. Inoltre, se l'eseguibile perl5.6.1 è richiesto, Perl non lo cercherà
perl5.6.1.exe. [Questo potrebbe cambiare in futuro.]

"extproc" on , il prima di tutto linea
Se i primi caratteri di uno script Perl sono "extproc ", questa riga viene trattata come riga "#!",
quindi tutte le opzioni su questa riga vengono elaborate (due volte se lo script è stato avviato tramite
cmd.exe). Vedi "DESCRIZIONE" in perlrun.

aggiuntivo moduli:
OS2::Process, OS2::DLL, OS2::REXX, OS2::PrfDB, OS2::ExtAttr. Questi moduli forniscono l'accesso
all'argomento numerico aggiuntivo per "sistema" e alle informazioni sull'esecuzione
processo, alle DLL aventi funzioni con firma REXX e al runtime REXX, a OS/2
database in ini formato e agli attributi estesi.

Due estensioni aggiuntive di Andreas Kaiser, "OS2::UPM" e "OS2::FTP", sono incluse in
Directory "ILYAZ", rispecchiata su CPAN. Sono disponibili anche altre estensioni relative a OS/2.

Sale montate metodi:
"File::Copia::syscopy"
utilizzato da "File::Copia::copia", vedere File::Copia.

"DynaLoader::mod2fnome"
utilizzato da "DynaLoader" per la modifica dei nomi DLL.

"Cwd::current_drive()"
Autoesplicativo.

"Cwd::sys_chdir(nome)"
lascia la guida così com'è.

"Cwd::change_drive(nome)"
cambia l'unità "corrente".

"Cwd::sys_is_absolute(nome)"
significa che ha una lettera di unità ed è_rooted.

"Cwd::sys_is_rooted(nome)"
significa che ha all'inizio "[/\\]" (forse dopo una lettera di unità:).

"Cwd::sys_is_relative(nome)"
significa cambiamenti con la directory corrente.

"Cwd::sys_cwd(nome)"
Interfaccia per cwd da EMX. Utilizzato da "Cwd::cwd".

"Cwd::sys_abspath(nome, dir)"
Funzione davvero davvero odiosa da implementare. Restituisce il nome assoluto del file che sarebbe
avere "nome" se CWD fosse "dir". Per impostazione predefinita "Dir" è la directory corrente.

"Cwd::extLibpath([tipo])"
Ottieni il valore corrente del percorso di ricerca della libreria estesa. Se "tipo" è presente e positivo,
funziona con "END_LIBPATH", se negativo, funziona con "LIBPATHSTRICT", altrimenti con
"BEGIN_LIBPATH".

"Cwd::extLibpath_set( percorso [, tipo ] )"
Imposta il valore corrente del percorso di ricerca della libreria estesa. Se "tipo" è presente e positivo,
funziona con , se negativo, funziona con "LIBPATHSTRICT", altrimenti con
"BEGIN_LIBPATH".

"OS2::Errore(esegui_errore_hard, esegui_eccezione)"
Restituisce "undef" se non è stato ancora chiamato, altrimenti viene impostato il bit 1 se sul precedente
la chiamata do_harderror era abilitata, il bit 2 è impostato se nella chiamata precedente lo era do_exception
abilitato.

Questa funzione abilita/disabilita i popup di errore associati agli errori hardware (Disco no
ready ecc.) ed eccezioni software.

Non conosco alcun modo per scoprire lo stato dei popup prima la prima chiamata a questo
funzione.

"OS2::Errors2Drive(unità)"
Restituisce "undef" se non è stato ancora chiamato, altrimenti restituisce false se non ci sono stati errori
richiesto che venga scritto su un disco rigido o sulla lettera dell'unità, se richiesto.

Questa funzione potrebbe reindirizzare i popup di errore associati a errori hardware (Disco no
ready ecc.) ed eccezioni software nel file POPUPLOG.OS2 nella directory principale di
l'unità specificata. Sostituisce OS2::Errore() specificati dai singoli programmi. Dato
l'argomento undef disabiliterà il reindirizzamento.

Ha un effetto globale e persiste dopo la chiusura dell'applicazione.

Non conosco alcun modo per scoprire lo stato del reindirizzamento dei popup sul disco prima , il
prima chiamata a questa funzione.

OS2::SysInfo()
Restituisce un hash con le informazioni di sistema. Le chiavi dell'hash sono

MAX_PATH_LENGTH, MAX_TEXT_SESSIONS, MAX_PM_SESSIONS,
MAX_VDM_SESSIONS, BOOT_DRIVE, DYN_PRI_VARIATION,
MAX_WAIT, MIN_SLICE, MAX_SLICE, PAGE_SIZE,
VERSIONE_MAJOR, VERSIONE_MINOR, VERSIONE_REVISION,
MS_COUNT, TIME_LOW, TIME_HIGH, TOTPHYSMEM, TOTRESMEM,
TOTAVAILMEM, MAXPRMEM, MAXSHMEM, TIMER_INTERVAL,
MAX_COMP_LENGTH, FOREGROUND_FS_SESSION,
FOREGROUND_PROCESS

OS2::BootDrive()
Restituisce una lettera senza due punti.

"OS2::MorphPM(serve)", "OS2::UnMorphPM(serve)"
Trasforma l'applicazione corrente in un'applicazione PM e viceversa. L'argomento è vero
significa che verrà servito un vero e proprio ciclo di messaggi. OS2::MorphPM() risponde il PM
gestire la coda dei messaggi come numero intero.

Per ulteriori dettagli vedere "Gestione centralizzata delle risorse".

"OS2::Serve_Messages(forza)"
Falso recupero su richiesta di messaggi PM in sospeso. Se "forza" è falsa, non lo farà
inviare messaggi se è noto che è presente un vero ciclo di messaggi. Restituisce il numero di
messaggi recuperati.

Muore con "QUITing..." se viene ottenuto il messaggio WM_QUIT.

"OS2::Process_Messages(forza [, cnt])"
Recupero dei messaggi PM fino alla creazione/distruzione della finestra. Se "forza" è falsa, volontà
non inviare messaggi se è noto che è presente un vero ciclo di messaggi.

Restituisce la variazione del numero di finestre. Se viene fornito "cnt", viene incrementato dal
numero di messaggi recuperati.

Muore con "QUITing..." se viene ottenuto il messaggio WM_QUIT.

"OS2::_control87(nuovo,maschera)"
lo stesso di _control87(3) dell'EMX. Prende numeri interi come argomenti, restituisce il precedente
parola di controllo del coprocessore come numero intero. Solo i bit in "nuovo" che sono presenti in
"maschera" vengono modificate nella parola di controllo.

OS2::get_control87()
ottiene la parola di controllo del coprocessore come numero intero.

"OS2::set_control87_em(nuovo=MCW_EM,maschera=MCW_EM)"
La variante di OS2::_control87() con valori predefiniti utili per gestire la maschera delle eccezioni:
se non c'è "maschera", usa solo la maschera di eccezione parte di "nuovo". Se non c'è "nuovo", disabilita tutti i file
eccezioni in virgola mobile.

Per i dettagli vedere "Caratteristiche errate".

"OS2::nomeDLL([come [, \&xsub]])"
Fornisce le informazioni sulla DLL Perl o sulla DLL contenente la funzione C associata
di &xsub. Il significato di "come" è: default (2): nome completo; 0: maniglia; 1: nome del modulo.

(Nota che alcuni di questi potrebbero essere spostati in librerie diverse, prima o poi).

Sale montate variabili:
$OS2::emx_rev
il valore numerico è uguale a _emx_rev di EMX, un valore stringa uguale a _emx_vprt
(simile a "0.9c").

$OS2::emx_env
uguale a _emx_env di EMX, un numero simile a 0x8001.

$OS2::os_ver
un numero "OS_MAJOR + 0.001 * OS_MINOR".

$OS2::is_aout
true se la libreria Perl è stata compilata in formato AOUT.

$OS2::can_fork
true se l'eseguibile corrente è un eseguibile AOUT EMX, quindi Perl può eseguire il fork. Non
usa questo, usa il controllo portatile per $Config::Config{dfork}.

$OS2::nerrore di sistema
Questa variabile (il valore predefinito è 1) controlla se applicare il contenuto di $^E per iniziare
con ID simile a "SYS0003". Se impostato su 0, il valore della stringa $^E è ciò che è
disponibile dal file di messaggi OS/2. (Alcuni messaggi in questo file hanno un file
ID simile a "SYS0003" anteposto, altri no.)

difetti
· Da gregge(3) è presente in EMX, ma non è funzionale, è emulato da perl. A
disabilitare le emulazioni, impostare la variabile d'ambiente "USE_PERL_FLOCK=0".

· Ecco l'elenco delle cose che potrebbero essere "rotte" su EMX (dai documenti EMX):

· Le funzioni recvmsg(3), invia msg(3), e coppia di prese(3) non sono implementati.

· calzino_init(3) non è richiesto e non è implementato.

· gregge(3) non è ancora implementato (funzione fittizia). (Perl ha una soluzione alternativa.)

· kill(3): Il trattamento speciale di PID=0, PID=1 e PID=-1 non è implementato.

· aspetta(3)

WUNTRACED
Non implementato.
waitpid() non è implementato per valori negativi di PID.

Tieni presente che "kill -9" non funziona con la versione corrente di EMX.

· Vedere "Filehandle in modalità testo".

· I socket del dominio Unix su OS/2 risiedono in uno pseudo-file system "/sockets/...". Per evitare a
mancata creazione di un socket con un nome di forma diversa, a cui viene anteposto "/socket/".
il nome del socket (a meno che non inizi già con questo).

Ciò potrebbe portare a problemi in seguito nel caso in cui si acceda al socket tramite il "solito" file-
chiamate di sistema utilizzando il nome "iniziale".

· A quanto pare, IBM ha utilizzato un compilatore (per un certo periodo di tempo intorno al '95?) che modifica FP
maschera destra e sinistra. Questo non è che male per i programmi IBM, ma lo stesso compilatore
è stato utilizzato per DLL utilizzate con applicazioni generiche. Quando queste DLL
vengono utilizzati, lo stato dei flag a virgola mobile nell'applicazione non è prevedibile.

Ciò che è molto peggio, alcune DLL modificano i flag in virgola mobile quando sono in _DLLInitTerm()
(per esempio, TCP32IP). Ciò significa che anche se non lo fai chiamata qualsiasi funzione nella DLL,
solo l'atto di caricare questa DLL ripristinerà i tuoi flag. Ciò che è peggio, lo stesso
il compilatore è stato utilizzato per compilare alcune DLL HOOK. Dato che le dll HOOK vengono eseguite nel file
contesto di contro tutti i le applicazioni nel sistema, ciò significa una completa imprevedibilità
di flag in virgola mobile sui sistemi che utilizzano tali DLL HOOK. Per esempio, GAMESRVR.DLL of TUFFO
origin modifica i flag in virgola mobile su ogni scrittura sul TTY di un VIO (windowed
applicazioni in modalità testo).

Alcune altre situazioni (non completamente sottoposte a debug) in cui i flag FP cambiano ne includono alcune
driver video (?), ed alcune operazioni legate alla creazione delle finestre. Persone che
codice OpenGL potrebbe avere più esperienza in merito.

Perl viene generalmente utilizzato nella situazione in cui sono presenti tutte le eccezioni in virgola mobile
ignorato, come è l'impostazione predefinita in EMX. Se non vengono ignorati, qualche Perl benigno
i programmi otterrebbero un "SIGFPE" e morirebbero di una morte orribile.

Per aggirare questo problema, Perl utilizza due hack. Aiutano contro prima solo tipo di danno:
I flag FP sono cambiati durante il caricamento di una DLL.

Uno degli hack è disabilitare le eccezioni in virgola mobile all'avvio di Perl (come è il file
predefinito con EMX). Questo aiuta solo con le DLL collegate in fase di compilazione che modificano i flag
prima principale() avuto la possibilità di essere chiamato.

L'altro trucco consiste nel ripristinare i flag FP dopo una chiamata a dlopen(). Questo aiuta contro
danno simile causato dalle DLL _DLLInitTerm() in fase di esecuzione. Al momento non c'è modo di cambiare
vengono forniti questi hack.

modifiche
Perl modifica alcune chiamate alla libreria C standard nei seguenti modi:

"popen" utilizza "my_popen". sh.exe se è richiesta la shell, cfr. "PERL_SH_DIR".

"tmpnam" viene creato utilizzando la variabile d'ambiente "TMP" o "TEMP", tramite "tempnam".

"filetmp"
Se la directory corrente non è scrivibile, il file viene creato utilizzando modificato
"tmpnam", quindi potrebbe esserci una condizione di competizione.

"ctermid"
un'implementazione fittizia.

Casi speciali "stat" "os2_stat". /dev/tty e /dev/con.

"mkdir", "rmdir"
queste funzioni EMX non funzionano se il percorso contiene un "/" finale. Perl
contiene una soluzione alternativa per questo.

"gregge" Da allora gregge(3) è presente in EMX, ma non è funzionale, è emulato da perl.
Per disabilitare le emulazioni, impostare la variabile d'ambiente "USE_PERL_FLOCK=0".

Identificare DLL
Tutte le DLL costruite con le attuali versioni di Perl hanno stringhe ID che ne identificano il nome
dell'estensione, della sua versione e della versione di Perl richiesta per questa DLL. Correre
"nome DLL bldlevel" per trovare queste informazioni.

Centralizzata of risorse
Poiché per chiamare determinate API OS/2 è necessario disporre di un sottosistema "Win" correttamente inizializzato,
Le estensioni specifiche di OS/2 potrebbero richiedere l'ottenimento di "HAB" e "HMQ". Se una proroga andasse bene
da solo, un'altra estensione potrebbe non riuscire a inizializzarsi.

Perl fornisce una gestione centralizzata di queste risorse:

"HAB"
Per ottenere l'HAB, l'estensione dovrebbe chiamare "hab = perl_hab_GET()" in C. Successivamente
viene eseguita la chiamata, è possibile accedere a "hab" come "Perl_hab". Non è necessario rilasciare
l'HAB dopo l'uso.

Se per qualche motivo perl.h non può essere incluso, utilizzare

extern int Perl_hab_GET(void);

anziché.

"HMQ"
Ci sono due casi:

· l'estensione necessita di un "HMQ" solo perché altrimenti alcune API non funzionerebbero. Utilizzo
"servire = 0" di seguito.

· l'interno necessita di un "HMQ" poiché desidera impegnarsi in un ciclo di eventi PM. Utilizzo
"servire = 1" di seguito.

Per ottenere un "HMQ", l'estensione dovrebbe chiamare "hmq = perl_hmq_GET(serve)" in C. Dopo
viene eseguita questa chiamata, è possibile accedere a "hmq" come "Perl_hmq".

Per segnalare a Perl che HMQ non è più necessario, chiamate "perl_hmq_UNSET(serve)". Perl
il processo si trasformerà/deformerà automaticamente se stesso in/da un processo PM se HMQ lo è
necessario/non necessario. Perl abiliterà/disabiliterà automaticamente il messaggio "WM_QUIT" durante
arresto se la coda dei messaggi viene servita/non servita.

NOTA. Se durante uno spegnimento è presente una coda di messaggi che non ha disabilitato WM_QUIT,
e che non ha elaborato il messaggio WM_QUIT ricevuto, verrà eseguito lo spegnimento
automaticamente cancellato. Non chiamare perl_hmq_GET(1) a meno che non si intenda elaborare
messaggi in modo ordinato.

Trattamento degli errori segnalati dall'API OS/2
Esistono due convenzioni principali (è utile chiamarle "Dos*" e "Win*" -
sebbene questa parte della firma della funzione non sia sempre determinata dal nome del file
API) di segnalare le condizioni di errore dell'API OS/2. La maggior parte delle API "Dos*" riportano il file
codice di errore come risultato della chiamata (quindi 0 significa successo e ne esistono molti tipi
errori). La maggior parte delle API "Win*" riportano il successo/fallimento tramite il risultato "TRUE"/"FALSE";
per scoprire il motivo del fallimento è necessario chiamare WinGetUltimoErrore() API.

Alcuni punti di ingresso "Win*" sovraccaricano anche un valore restituito "significativo" con l'errore
indicatore; avere un valore restituito pari a 0 indica un errore. Ancora qualche altra voce "Win*".
i punti sovraccaricano ancora di più le cose e il valore restituito 0 può significare una chiamata riuscita
restituendo un valore valido 0, nonché una condizione di errore; nel caso di 0 return
valore che si dovrebbe chiamare WinGetUltimoErrore() API per distinguere una chiamata riuscita da a
fallendone uno.

Per convenzione, tutte le chiamate all'API OS/2 dovrebbero indicare i propri errori mediante reimpostazione
$^E. Tutte le funzioni accessibili da Perl che chiamano l'API OS/2 possono essere suddivise in due
classi: alcune die ()s quando viene riscontrato un errore API, l'altro segnala l'errore tramite
un valore restituito falso (ovviamente, questo non riguarda le funzioni accessibili da Perl che
attenderti un errore della chiamata API OS/2, con la codifica di alcune soluzioni alternative).

Ovviamente, nella situazione dell'ultimo tipo di firma di un'API OS/2, lo è
deve essere più conveniente per gli utenti se il guasto è indicato da die ()ing: si fa
non è necessario controllare $^E per sapere che qualcosa è andato storto. Se, tuttavia, questa soluzione
non è desiderabile per qualche motivo, il codice in questione dovrebbe prima reimpostare $^E su 0
effettuando questa chiamata API OS/2, in modo che il chiamante di questa funzione accessibile in Perl abbia un
possibilità di distinguere un valore di successo ma con rendimento pari a 0 da un fallimento. (Uno può ritornare
undef come modo alternativo per segnalare un errore.)

Le macro per semplificare questo tipo di propagazione degli errori sono

"CheckOSError(espressione)"
Restituisce vero in caso di errore, imposta $^E. Si aspetta espressione() essere una chiamata dell'API in stile "Dos*".

"CheckWinError(espressione)"
Restituisce vero in caso di errore, imposta $^E. Si aspetta espressione() essere una chiamata dell'API in stile "Win*".

"SaveWinError(espressione)"
Restituisce "expr", imposta $^E da WinGetUltimoErrore() se "espr" è falso.

"SaveCroakWinError(espr,die,nome1,nome2)"
Restituisce "expr", imposta $^E da WinGetUltimoErrore() se "expr" è falso, e die ()s se
"morire" e $^E sono veri. Il messaggio da morire sono le stringhe concatenate "nome1"
e "nome2", separati da ":" dal contenuto di $^E.

"WinError_2_Perl_rc"
Imposta "Perl_rc" sul valore restituito di WinGetUltimoErrore().

"FillWinErrore"
Imposta "Perl_rc" sul valore restituito di WinGetUltimoErrore()e imposta $^E su
valore corrispondente.

"FillOSError(rc)"
Imposta "Perl_rc" su "rc" e imposta $^E sul valore corrispondente.

Caricamento di DLL e ordinali nelle DLL
Alcune DLL sono presenti solo in alcune versioni di OS/2 o in alcune configurazioni di
OS/2. Alcuni punti di ingresso esportati sono presenti solo nelle DLL fornite con alcune versioni
di OS/2. Se queste DLL e punti di ingresso fossero collegati direttamente per un file Perl
eseguibile/DLL o da estensioni Perl, questo binario funzionerebbe solo con il file
versioni/configurazioni specificate. Anche se questi punti di ingresso non fossero necessari, il caricare of
l'eseguibile (o DLL) fallirebbe.

Ad esempio, molte API più recenti e utili non sono presenti in OS/2 v2; molte API relative a PM
richiedono DLL non disponibili nella configurazione di avvio da floppy.

Per far fallire queste chiamate esclusivamente quando , il chiamate sono eseguito, si dovrebbero chiamare queste API
tramite un'API di collegamento dinamico. Esiste un sottosistema in Perl per semplificare questo tipo di
chiamate. Viene fornito un gran numero di punti di ingresso disponibili per tale collegamento (vedi
"entries_ordinals" - e anche "PMWIN_entries" - in os2ish.h). Questi ordinali possono essere
accessibile tramite le API:

CallORD(), DeclFuncByORD(), DeclVoidFuncByORD(),
DeclOSFuncByORD(), DeclWinFuncByORD(), AssignFuncPByORD(),
DeclWinFuncByORD_CACHE(), DeclWinFuncByORD_CACHE_survive(),
DeclWinFuncByORD_CACHE_resetError_survive(),
DeclWinFunc_CACHE(), DeclWinFunc_CACHE_resetError(),
DeclWinFunc_CACHE_survive(), DeclWinFunc_CACHE_resetError_survive()

Vedere i file di intestazione e il codice C nei moduli relativi a OS/2 forniti per
dettagli sull'utilizzo di queste funzioni.

Alcune di queste funzioni combinano anche la semantica del dynaloading con la propagazione degli errori
semantica discussa sopra.

Perl sapori

A causa delle idiosincrasie di OS/2 non è possibile avere tutte le uova nello stesso paniere (tuttavia
L'ambiente EMX si sforza di superare queste limitazioni, quindi la situazione potrebbe in qualche modo
migliorare). Ci sono 4 eseguibili per Perl forniti dalla distribuzione:

perl.exe
Il principale cavallo di battaglia. Questo è un eseguibile chimera: è compilato in stile "a.out".
eseguibile, ma è collegato alla libreria dinamica in stile "omf". perl.dlle con CRT dinamico
DLL. Questo eseguibile è un'applicazione VIO.

Può caricare estensioni dinamiche Perl e può farlo forchetta().

Nota. Tieni presente che forchetta() è necessario aprire una pipa verso te stesso.

perl_.exe
Questo è un eseguibile in stile "a.out" collegato staticamente. Non può caricare Perl dinamico
estensioni. L'eseguibile fornito nelle distribuzioni binarie ha molte estensioni
precostruito, quindi la restrizione di cui sopra è importante solo se si utilizzano estensioni personalizzate.
Questo eseguibile è un'applicazione VIO.

Questo is , il esclusivamente eseguibile con effettua non è un richiedere OS/2. Gli amici si sono rinchiusi nel mondo di "M$".
apprezzerei il fatto che questo eseguibile funzioni sotto DOS, Win0.3*, Win0.95 e WinNT
con un apposito extender. Vedi "Altri sistemi operativi".

perl__.exe
Questo è lo stesso eseguibile di perl___.exe, ma è un'applicazione PM.

Nota. Di solito (a meno che non venga reindirizzato esplicitamente durante l'avvio) STDIN, STDERR e STDOUT
di un'applicazione PM vengono reindirizzati nullo. Tuttavia, è possibile vedere loro se tu
avviare "perl__.exe" da un programma PM che emula una finestra di console, come Conchiglia modo of
Emacs o EPM. Così is possibile per usare il debugger Perl (vedi perldebug) per eseguire il debug del tuo PM
applicazione (ma fai attenzione ai blocchi del loop di messaggi: non funzionerà se hai un file
coda di messaggi da servire, a meno che non si colleghi il servizio al file getc() funzione del
debugger).

Un altro modo per vedere l'output di un programma PM è eseguirlo come

pm_prog argomenti 2>&1 | gatto -

con una conchiglia diverso da cmd.exe, in modo che non crei un collegamento tra un VIO
sessione e la sessione di "pm_porg". (Tale collegamento chiude la finestra VIO.) Ad esempio, this
funziona con sh.exe - o con Perl!

apri P, 'pm_prog argomenti 2>&1 |' o morire;
stampare mentre ;

Il sapore perl__.exe è necessario se desideri avviare il programma senza una finestra VIO
presente, ma non "staccato" (esegui "help detach" per maggiori informazioni). Molto utile per le estensioni
che utilizzano PM, come "Perl/Tk" o "OpenGL".

Si noti inoltre che le differenze tra gli eseguibili PM e VIO sono solo nel file difetto
comportamento. Si può iniziare in qualsiasi eseguibile in in qualsiasi tipo di sessione utilizzando gli argomenti
Switch "/fs", "/pm" o "/win" del comando "start" (of CMD.EXE o una shell simile).
In alternativa, si può usare il primo argomento numerico della funzione Perl "sistema" (vedi
OS2::Processo).

perl___.exe
Questo è un eseguibile in stile "omf" a cui è collegato dinamicamente perl.dll e DLL CRT. IO
non conosco i vantaggi di questo eseguibile rispetto a "perl.exe", ma non è così forchetta() affatto. BENE,
un vantaggio è che il processo di compilazione non è così contorto come con "perl.exe".

È un'applicazione VIO.

Perché strano nomi?
Poiché Perl elabora la riga "#!" (cfr. "DESCRIZIONE" in perlrun, "Interruttori di comando" in
perlrun, "Nessuno script Perl trovato nell'input" in perldiag), dovrebbe sapere quando un programma is a
Perl. Esistono alcune convenzioni sui nomi che consentono a Perl di distinguere le linee corrette da
quelli sbagliati. I nomi di cui sopra sono quasi gli unici nomi consentiti da questa convenzione che lo fanno
non contenere cifre (che hanno una semantica assolutamente diversa).

Perché dinamico collegamento?
Bene, avere diversi eseguibili collegati dinamicamente alla stessa enorme libreria ha il suo
vantaggi, ma ciò non sostanzia il lavoro aggiuntivo necessario per compilarlo. IL
il motivo è che è complicato per gli sviluppatori ma molto veloce e conveniente per gli utenti "difficile"
collegamento dinamico utilizzato da OS/2.

Ci sono due caratteristiche distintive del modello dyna-linking di OS/2: primo, tutto il
i riferimenti a funzioni esterne vengono risolti in fase di compilazione; secondo, non esiste
correzione runtime delle DLL dopo che sono state caricate in memoria. La prima caratteristica è un
enorme vantaggio rispetto ad altri modelli: evita conflitti quando più DLL utilizzate da un
voci di esportazione dell'applicazione con lo stesso nome. In questi casi “altri” modelli di dinamica
collegamento basta scegliere tra questi due punti di ingresso utilizzando un criterio casuale - con
disastri prevedibili come risultati. Ma è la seconda caratteristica che richiede la build
of perl.dll.

Le tabelle degli indirizzi delle DLL vengono patchate solo una volta, quando vengono caricate. Gli indirizzi di
è garantito che i punti di ingresso nelle DLL siano gli stessi per tutti i programmi che utilizzano
la stessa DLL. Ciò rimuove la correzione del runtime: una volta caricata la DLL, il suo codice è di sola lettura.

Sebbene ciò consenta alcuni (significativi?) vantaggi in termini di prestazioni, ciò rende la vita molto più difficile
per gli sviluppatori, poiché lo schema di cui sopra rende impossibile che una DLL sia "collegata" a un file
simbolo nel . EXE file. In effetti, ciò richiederebbe una DLL per avere rilocazioni diverse
tabelle per i (diversi) eseguibili che utilizzano questa DLL.

Tuttavia, un'estensione Perl caricata dinamicamente è costretta a utilizzare alcuni simboli del perl
eseguibile, ad esempio, per sapere come trovare gli argomenti delle funzioni: gli argomenti vivono
sullo stack di valutazione interna di Perl. La soluzione è inserire il codice principale del file
interprete in una DLL e creare il file . EXE file che carica semplicemente questa DLL in memoria e
fornisce argomenti di comando. La DLL di estensione non può collegarsi ai simboli in . EXE, ma ha
nessun problema nel collegamento ai simboli nel file .DLL.

Questo molto aumenta il tempo di caricamento dell'applicazione (nonché la complessità del file
compilazione). Poiché l'interprete si trova in una DLL, il C RTL è sostanzialmente costretto a risiedere in a
DLL (altrimenti le estensioni non sarebbero in grado di utilizzare CRT). Ci sono alcuni
vantaggi se usi diverse versioni di Perl, come la corsa perl.exe e perl__.exe
contemporaneamente: ne condividono la memoria perl.dll.

NOTA. C'è un ulteriore effetto che rende le DLL più dispendiose: le DLL vengono caricate
la regione della memoria condivisa, che è una risorsa scarsa data la barriera dei 512M del
memoria virtuale OS/2 "standard". Il codice di . EXE i file sono condivisi anche da tutti i file
processi che utilizzano il particolare . EXE, ma sono "condivisi nello spazio degli indirizzi privato
del processo"; ciò è possibile perché l'indirizzo al quale si trovano le diverse sezioni del
. EXE il caricamento dei file viene deciso in fase di compilazione, quindi tutti i processi li hanno
sezioni caricate agli stessi indirizzi e nessuna correzione dei collegamenti interni all'interno del file . EXE is
necessario.

Poiché le DLL possono essere caricate in fase di esecuzione, per avere lo stesso meccanismo per le DLL è necessario
hanno l'intervallo di indirizzi di in qualsiasi of , il caricato Le DLL nel sistema devono essere disponibili in contro tutti i , il
i processi che non ha ancora caricato una DLL particolare. Questo è il motivo per cui le DLL sono mappate su
regione di memoria condivisa.

Perché chimera costruire?
L'attuale ambiente EMX non consente l'uso di DLL compilate utilizzando il formato Unixish "a.out".
esportare simboli per i dati (o almeno alcuni tipi di dati). Ciò forza la compilazione in stile "omf".
of perl.dll.

L'attuale ambiente EMX non lo consente . EXE file compilati in formato "omf" in forchetta().
forchetta() è necessario per esattamente tre operazioni Perl:

· esplicito forchetta() nella sceneggiatura,

· "apri FH, "|-""

· "open FH, "-|"", in altre parole, aprendo i tubi verso se stesso.

Sebbene queste operazioni non siano questioni di vita o di morte, sono necessarie per molti
script utili. Ciò forza la compilazione in stile "a.out" di perl.exe.

AMBIENTE

Qui elenchiamo le variabili di ambiente che sono specifiche per OS/2, DOS e Win*, oppure
sono più importanti in OS/2 che in altri sistemi operativi.

"PERLLIB_PREFIX"
Specifico per porta EMX. Dovrebbe avere il modulo

percorso1;percorso2

or

percorso1 percorso2

Se l'inizio di un percorso predefinito corrisponde path1, è sostituito con path2.

Dovrebbe essere utilizzato se la libreria perl viene spostata preferibilmente dalla posizione predefinita a
"PERL(5)LIB", poiché ciò non lascerebbe voci errate in @INC. Ad esempio, se il file
la versione compilata di perl cerca @INC in f:/perllib/libe vuoi installare il file
libreria in h:/opt/gnuDi

imposta PERLLIB_PREFIX=f:/perllib/lib;h:/opt/gnu

Ciò farà sì che Perl abbia il valore @INC predefinito di

f:/perllib/lib/5.00553/os2
f:/perllib/lib/5.00553
f:/perllib/lib/site_perl/5.00553/os2
f:/perllib/lib/site_perl/5.00553
.

per utilizzare il seguente @INC:

h:/opt/gnu/5.00553/os2
h:/opt/gnu/5.00553
h:/opt/gnu/site_perl/5.00553/os2
h:/opt/gnu/site_perl/5.00553
.

"PERL_BADLANG"
Se 0, perl ignora impostalocale() fallendo. Può essere utile con qualche strano localitàs.

"PERL_BADFREE"
Se 0, perl non avviserà in caso di ingiustificato gratuito(). Con i Perls più vecchi questo potrebbe essere
utile insieme al modulo DB_File, che presentava bug quando era collegato dinamicamente e
Costruito da OMF.

Non dovrebbe essere impostato con Perls più recenti, poiché ciò potrebbe nasconderne alcuni di rose problemi.

"PERL_SH_DIR"
Specifico per porta EMX. Fornisce alla directory parte del percorso per sh.exe.

"USE_PERL_FLOCK"
Specifico per porta EMX. Da gregge(3) è presente in EMX, ma non è funzionale, lo è
emulato da perl. Per disabilitare le emulazioni, impostare la variabile d'ambiente "USE_PERL_FLOCK=0".

"TMP" or "TEMPERATURA"
Specifico per porta EMX. Utilizzato come luogo di archiviazione per file temporanei.

Evolution

Qui elenchiamo i principali cambiamenti che potrebbero sorprenderti.

Modalità testo filehandle
A partire dalla versione 5.8, Perl utilizza un livello di traduzione integrato per i file in modalità testo.
Questo sostituisce l'efficiente livello EMX ben testato con del codice che dovrebbe essere il migliore
caratterizzato come un "hack veloce".

Oltre a possibili bug e all'impossibilità di seguire le modifiche alla politica di traduzione
con gli interruttori off/on della traduzione TERMIO, questo introduce una grave modifica incompatibile:
prima sysread() sui filehandle in modalità testo passerebbero attraverso il livello di traduzione, ora
non lo farebbe.

priorità
"setpriority" e "getpriority" non sono compatibili con i port precedenti di Andreas Kaiser.
Vedi "setpriority, getpriority".

DLL Nome mutilamento: pre 5.6.2
Con la versione 5.003_01 le librerie caricabili dinamicamente dovrebbero essere ricostruite quando a
viene compilata una versione diversa di Perl. In particolare, le DLL (inclusi perl.dll) sono ora
creato con i nomi che contengono un checksum, consentendo così una soluzione alternativa per lo schema OS/2
di memorizzazione nella cache delle DLL.

Potrebbe essere possibile codificare una semplice soluzione alternativa che lo farebbe

· trovare le vecchie DLL cercando nel vecchio @INC;

· modificare i nomi secondo lo schema del nuovo perl e copiare le DLL con questi nomi;

· modificare le tabelle "LX" interne della DLL per riflettere il cambiamento del nome (probabilmente no
necessario per le DLL di estensione Perl, poiché i nomi codificati internamente non vengono utilizzati per
DLL "specifiche", venivano utilizzate solo per DLL "globali").

· modificare le tabelle interne "IMPORT" e cambiare il nome delle "vecchie" perl????.dll ai
"nuovo" perl????.dll.

DLL Nome mutilamento: 5.6.2 e al di là di
In effetti mutilazione di estensione Le DLL sono state create a causa di un'incomprensione di OS/2
modello di caricamento dinamico. OS/2 (effettivamente) mantiene due diverse tabelle di DLL caricate:

DLL globali
quelli caricati dal nome base da "LIBPATH"; compresi quelli associati al momento del collegamento;

DLL specifiche
caricato con il nome completo.

Quando si risolve una richiesta per una DLL globale, la tabella delle DLL specifiche già caricate è
(effettivamente) ignorato; inoltre, lo sono DLL specifiche sempre caricato dal percorso prescritto.

C'è/era una piccola svolta che rende fragile questo schema: cosa fare con le DLL caricate
da

"BEGINLIBPATH" e "ENDLIBPATH"
(che dipendono dal processo)

. da "LIBPATH"
quale in maniera efficace dipende dal processo (sebbene "LIBPATH" sia lo stesso per tutti i file
processi).

A meno che "LIBPATHSTRICT" non sia impostato su "T" (e il kernel sia successivo al 2000/09/01), tali DLL sono
considerato globale. Quando si carica una DLL globale, viene prima cercata nella tabella di
DLL globali già caricate. Per questo motivo è dovuto al fatto che un eseguibile ha caricato una DLL
da "BEGINLIBPATH" e "ENDLIBPATH", oppure . da "LIBPATH" potrebbe influire quale La DLL è caricata
quando un altro l'eseguibile richiede una DLL con lo stesso nome. Questo è la ragione per
modifica specifica della versione del nome DLL per perl DLL.

Poiché le DLL delle estensioni Perl vengono sempre caricate con il percorso completo, non è necessario farlo
modificare i loro nomi in modi specifici della versione: la loro directory riflette già il file
versione corrispondente di perl e @INC tiene conto della compatibilità binaria con le versioni precedenti
versione. A partire dalla versione 5.6.2 lo schema di modifica dei nomi è stato fissato per essere lo stesso di Perl
5.005_53 (come in una popolare versione binaria). Così i nuovi Perls potranno farlo risolvere
, il nomi delle vecchie DLL di estensione se @INC consente di trovare le loro directory.

Tuttavia, ciò non garantisce ancora che queste DLL possano essere caricate. Il motivo è il
storpiatura del nome del Perl DLL. E poiché le DLL di estensione si collegano al file Perl
DLL, le DLL di estensione per le versioni precedenti caricherebbero una DLL Perl precedente e la maggior parte dei file
probabilmente segfault (poiché i dati in questa DLL non sono inizializzati correttamente).

Esiste una soluzione parziale (che può essere completata con i kernel OS/2 più recenti): create
una DLL forwarder con lo stesso nome della DLL della versione precedente di Perl, che inoltra
l'ingresso punta alla DLL del Perl più recente. Rendi questa DLL accessibile su (ad esempio) il file
"BEGINLIBPATH" del nuovo eseguibile Perl. Quando il nuovo eseguibile accede al vecchio Perl
DLL di estensione, richiederebbero la vecchia DLL del Perl per nome, otterrebbero invece lo spedizioniere,
in modo così efficace si collegherà con la (nuova) DLL Perl attualmente in esecuzione.

Questo potrebbe rompersi in due modi:

· Il vecchio eseguibile perl viene avviato quando un nuovo eseguibile in esecuzione ha caricato un
estensione compilata per il vecchio eseguibile (ouph!). In questo caso il vecchio eseguibile
otterrà una DLL di inoltro invece della vecchia DLL perl, quindi si collegherà con il nuovo perl
DLL. Sebbene non sia direttamente fatale, si comporterà come un nuovo eseguibile. Questo batte
l'intero scopo di avviare esplicitamente un vecchio eseguibile.

· Un nuovo eseguibile carica un'estensione compilata per il vecchio eseguibile quando è disponibile un vecchio perl
l'eseguibile è in esecuzione. In questo caso l'estensione non ritirerà lo spedizioniere -
con esiti fatali.

Con il supporto per "LIBPATHSTRICT" questo può essere aggirato, a meno che non venga avviata una delle DLL
da . da "LIBPATH" (non so se "LIBPATHSTRICT" influisce in questo caso).

NOTA. A meno che i kernel più recenti non lo consentano . in "BEGINLIBPATH" (le versioni precedenti no), questo pasticcio non può
essere completamente pulito. (Si scopre che dall'inizio del 2002, . non è permesso,
ma .\. è - e ha lo stesso effetto.)

NOTA. "LIBPATHSTRICT", "BEGINLIBPATH" e "ENDLIBPATH" non sono variabili di ambiente,
sebbene cmd.exe li emula sulle righe "SET ...". Da Perl è possibile accedervi tramite
Cwd::extLibpath e Cwd::extLibpath_set.

DLL spedizioniere ELETTRICA
Supponiamo che la vecchia DLL sia denominata perlE0AC.dll (come uno per 5.005_53) e il new
la versione è 5.6.1. Crea un file perl5shim.def-leader con

TERMINISTANZA DI INITINSTANZA DELLA LIBRERIA 'perlE0AC'
DESCRIZIONE '@#[email protected]:5.006001#@ Modulo Perl per 5.00553 -> Perl 5.6.1 forwarder'
CODICE CARICACHIAMATA
CARICAMENTO DATICHIAMATA NON CONDIVISA MULTIPLA
ESPORTAZIONI

modificando le versioni/nomi secondo necessità. Correre

perl -wnle "successivo if 0../ESPORTA/; print qq( \"$1\") if /\"(\w+)\"/" perl5.def >lst

nella directory di compilazione Perl (per rendere la DLL più piccola sostituire perl5.def con la definizione
file per la versione precedente di Perl, se presente).

cat perl5shim.def-leader lst >perl5shim.def
gcc -Zomf -Zdll -o perlE0AC.dll perl5shim.def -s -llibperl

(ignorare più "avvisi L4085").

Threading
A partire dalla versione 5.003_01 perl è collegato alla DLL C RTL multithread. Se il perl stesso non lo è
compilato abilitato per il multithread, quindi non sarà di Perl malloc (). Tuttavia, le estensioni possono utilizzare
più thread a proprio rischio.

Questo era necessario per compilare immediatamente "Perl/Tk" per XFree86-OS/2 e collegarlo con le DLL
per altre librerie utili, che tipicamente vengono compilate con "-Zmt -Zcrtdll".

Bandi a esterno programmi
A causa della grande richiesta, la chiamata al programma esterno Perl è stata modificata rispetto ad Andreas
Il porto di Kaiser. If perl deve chiamare un programma esterno via conchiglia, l' f:/bin/sh.exe
verrà chiamato, o qualunque sia l'override, vedere "PERL_SH_DIR".

Ciò significa che è necessario ottenere una copia di a sh.exe (ne uso uno da pdksh). IL
sentiero F:/bidone sopra viene impostato automaticamente durante la compilazione su un valore corretto su
macchina del builder, ma è sovrascrivibile in fase di esecuzione,

Motivi: un consenso sui "perl5-porter" era che perl dovesse usare una shell non sovrascrivibile
per piattaforma. Le scelte ovvie per OS/2 sono cmd.exe e sh.exe. Avere build Perl
stesso sarebbe impossibile con cmd.exe come shell, quindi ho scelto "sh.exe". Questo
assicura quasi il 100% di compatibilità con gli script provenienti da *nix. Come ulteriore vantaggio
funziona anche sotto DOS se si utilizza la porta di pdksh abilitata per DOS (vedere "Prerequisiti").

svantaggi: attualmente sh.exe di pdksh chiama programmi esterni tramite forchetta()/exec ()e
c'è no funzionamento exec () su OS/2. exec () viene emulato da EMX tramite una chiamata asincrona
mentre il chiamante attende il completamento del figlio (per far finta che il "pid" non sia cambiato).
Ciò significa che 1 extra copia di sh.exe viene reso attivo tramite forchetta()/exec (), che può portare a
alcune risorse prelevate dal sistema (anche se non contiamo il lavoro extra necessario per
forchetta()ns).

Tieni presente che questo è un problema minore ora che non spawniamo sh.exe se non necessario (metachars
trovato).

Si può sempre iniziare cmd.exe esplicitamente tramite

sistema 'cmd', '/c', 'mycmd', 'arg1', 'arg2', ...

Se è necessario utilizzare cmd.exee non vuoi modificare manualmente migliaia di script, il file
La soluzione a lungo termine proposta su p5-p è quella di avere una direttiva

usa OS2::Cmd;

che avrà la precedenza sistema(), exec (), "``" e "open(,'...|')". Con il Perl attuale puoi
solo sovrascrivere sistema(), readpipe() - la versione esplicita di "``", e forse exec ().
il codice sostituirà la chiamata con un argomento a sistema() da "CORE::system('cmd.exe', '/c',
spostare)".

Se hai del codice funzionante per "OS2::Cmd", inviamelo e lo includerò
distribuzione. Non ho bisogno di un modulo del genere, quindi non posso testarlo.

Per i dettagli sulla situazione attuale con la chiamata di programmi esterni, vedere "Avvio
programmi OS/2 (e DOS) sotto Perl". Citiamo un paio di caratteristiche:

· Gli script esterni possono essere chiamati con il loro nome base. Perl proverà le stesse estensioni
come durante l'elaborazione -S opzione della riga di comando.

· Script esterni che iniziano con "#!" o "extproc " verrà eseguito direttamente, senza
chiamando la shell, chiamando il programma specificato nel resto della prima riga.

Memorie assegnazione
Perl usa il proprio malloc () sotto OS/2 - gli interpreti sono solitamente legati a malloc per la velocità,
ma il perl no, dato che il suo malloc è velocissimo. Benchmark ottimizzati per l'utilizzo della memoria Perl
mostrano che il malloc di Perl è 5 volte più veloce di quello di EMX. Non ho dati convincenti
sull'occupazione di memoria, ma un benchmark (abbastanza casuale) ha mostrato che quello di Perl è del 5%
meglio.

Combinazione di perl malloc () e la rigida risoluzione dei nomi DLL crea un problema speciale
con funzioni di libreria che si aspettano che il loro valore restituito sia gratuito()d per sistema gratuito().
Per facilitare le estensioni che devono richiamare tali funzioni, l'allocazione della memoria di sistema
le funzioni sono ancora disponibili con il prefisso "emx_" aggiunto. (Attualmente solo DLL perl ha
questo, dovrebbe propagarsi a perl_.exe in breve.)

Discussioni
È possibile creare Perl con il supporto dei thread abilitato fornendo l'opzione "-D usethreads" a
Configurazione. Attualmente il supporto OS/2 dei thread è ancora preliminare.

Problemi più notevoli:

"COND_WAIT"
potrebbe avere una condizione di competizione (ma probabilmente non lo è a causa della natura attivata dal fronte di OS/2
semafori di eventi). (Necessita di una reimplementazione (in termini di concatenamento di thread in attesa,
con l'elenco collegato memorizzato nella struttura per thread?)?)

os2.c
ha un paio di variabili statiche usate nelle funzioni specifiche di OS/2. (Hanno bisogno di essere spostati
alla struttura per thread o serializzato?)

Tieni presente che questi problemi non dovrebbero scoraggiare la sperimentazione, poiché hanno un livello basso
probabilità di influenzare piccoli programmi.

Usa perlos2 online utilizzando i servizi onworks.net