sslug-teknik team mailing list archive

["E. Sj�d" <es@xxxxxxxxxx>]

"Poul-Erik Andreasen" <poulerik@xxxxxx> wrote in message
news:3BBE0248.4FFAA311@xxxxxx...
> > > Sorry guys, hvis spørgsmålet lå under jeres niveau.
> > Dit spørgsmål røbede en rimeligt ringe indsigt i hvad dll'er egentlig
er,
<snip>
> > Stil endeligt flere spørgsmål - at ønske at få svar er absolut
> > respektabelt.
> For en gangs skyld er jeg fuldstændig enig med dig. Det var sgu
> for lavt.

Jeg grinede også - men dog for mig selv.
Der er noget befriende ved at vide bedre end andre - jeg oplever det bare så
sjældent. Af og til kan jeg også forfalde til at sende et svar, som burde
have holdt sig mellem mine egne ører. Tag det som en oplevelse, at du fik to
af den slags svar, det er ikke alle beskåret.

Dit sp. var aldeles relevant. Når man har sine erfaringer fra Windows
verdenen, er .dll, .vcl (og flere) filtyper udtryk for, at deres indhold kan
deles af mange programmer. Din ide om, at de så kan deles mellem programmer
under Windows og Linux (blot CPU'en er den samme type) er derfor en helt
naturlig antagelse (læs jeg havde den selv engang). Forvirringen bliver ikke
mindre af, at man associerer fil-efternavne med programmer, så "enhver" ved,
at endelsen .txt betyder, at dette er en tekst-fi, og at den skal åbnes af
programmet notepad.exe. Man er i Windows gået så langt, så man i stifinder
endog som default skjuler disse åbenlyse efternavne (en af MS rigtigt
dårlige ideer efter min mening).

En .dll fil er en (binær) samling af rutiner, som man kan kalde op fra andre
programmer. Windows sørger for at hente filen ind, og at køre den eller de
rutiner, programmet har kaldt i den.
Ideen er jo oplagt. Paralellen i Linux-verdenen er .so filer, som altså også
er en samling af rutiner et fremmed program kan anvende.

Problemet med .dll og .so filerne er, at der skal være en eller anden form
for standard for, hvordan man kan sikre sig, at et kald til den indbyggede
funktion xx nu også udløser netop denne funktion, og at de parametre som
funktion xx skal bruge/aflevere nu også er på en forståelig måde. Bare for
at tage et let eksempel, kan man sende et 16-bits tal som to byte med enten
laveste byte først eller laveste byte sidst. Dette skal være fastlagt, så
alle gør det på samme måde. 258 er, opdelt i to hex-byte, = 01 02. Skal de
sendes i rækkefølgen 01 02 (68000 måden) eller som 02 01 (386' måden)
Forkert fortolket vil tallet blive til 513 (2*256 + 1) eller 258 (256*1 +
2). Der er en lang række af den slags problemer, som er løst i beskrivelsen
af de enkelte standarder, og der er en standard for både .dll og .so
formaterne.
Når nu der er en standard kan man naturligvis også implementere i Linux,
hvordan den skal håndteres - vil du sikkert sige.
Ja, det kan man , og ja, det gør man (ok nogle).
(Borland) Kylix er andet og mere end blot Delphi for Linux. Kylig/Delphi6 er
også programmer, som har lavet en standard for komponenter, der kan anvendes
under begge styresystemer. Den slags utyskestreger kan man ikke tjene penge
på, hvis man lever af at laver styresystemer, hvilket er grunden til at
Linuxfolket er begejstrede (de tjener alligevel ikke noget), mens MS er
afvisende (de kommet til ikke at tjene så meget fremover)

Tilbage står stadig, at en .dll eller .so fil som regel bygger på
systemkald, og derfor ikke uden videre kan anvendes under fremmede
styresystemer.
En simpel .dll eller .so fil, som blot kaldes med to tal, og returnerer
summen af dem, ville ret let (for guruer selvsagt) kunne håndteres i begge
verdener, men skal man kunne, skal man kunne det hele, og altså også arbejde
med en .dll som har en rutine, der tegner en streg fra punkt (x,y) til punkt
(x1,y1), eller for den sags skyld kopierer en fil fra A:navn til B:navn. Det
er den sidste del, der gør, at "man" på forhånd har opgivet at løse
delingsproblemet. Windows kalder disken for et bogstav, Linus for en
/dev/hd??, og dette er ikke et fladt spørgsmål om at oversætte "A:" til
"/dev/floppy" eller "C:" til "dev/hda1" ( på min maskine skulle det sidste
fx. være "/dev/sda1").

Altså, hvis du vil arbejde med samme programmer, herunder .dll filer, kan
det ikke lade sig gøre. Vil du arbejde men samme kildetekster, kan det
sikkert ikke lade sig gøre, da MS-kildetekster ikke er specielt
tilgængeligt.

Dit tredje sp. var om XML.
Dette er ikke et program, men en standard. Om du skal bruge det ene program
under Windows og et andet under Linux er jo dybest set kun et sp. om
tilvænning. For nu alligevel at være periferisk nedladende (tag det ikke
ondt op), så burde dit sp 3). have været noget i retning af:

Jeg bruger MSXML3 til at arbejde med XML-filer under Windows. Hvilket
program kan jeg bruge under Linux.

Desværre ville mit svar være: Jeg aner det ikke! (men det ville du aldrig
se, jeg ville holde det for mig selv, ligesom de første par svar på dit
indlæg bestemt burde have værer).

Hvis du er nået hertil i din læsning, har du det sikkert lidt bedre med
hensyn til at stille "tåbelige" spørgsmål, og din "åbentlyse", "slå mig på
maven af grin", "ha, ha hvor er du dum" uvidenhed omkring et dybt teknisk
spørgsmål er bragt til et andet niveau. Guru er jeg ikke, så mit svar vil
ikke bringe dig til nirvana, men forhåbentlig (gen)give dig lysten til at
spørge, næste gang du ikke kan forstå hvad i alverden det er der sker.

Da Linux og sslug er rent anarki, er det hverken op til mig, Mads Bondo
Dydensborg eller Poul-Erik Andersen at stikke en undskyldning for andres
svar, du må læse vores indlæg, som en anden måde at se verden på.