---

Hejsa derude

Jeg går og overvejer hvordan jeg skal lave en webserver og om det skal gøres
i Java,VB, eller C.

Og så tænkte jeg om i kunne give mig noget hjælp hvad er hurtigts,mest
stabilt, bedst at lave en webserver i.

og om I gad at fortælle mig hvad slags sikkerhed der skal være i en
webserver


--
Best regards / Med venlig hilsen

David Poulsen
Email: dpoulsen@e-box.dk
ICQ: 150873892

---

David Poulsen wrote:
> Hejsa derude
>
> Jeg går og overvejer hvordan jeg skal lave en webserver og om det skal gøres
> i Java,VB, eller C.

Hvorfor vil du selv lave én? Bare for sjov?

Jeg vil fraråde VB - blandt andet pga. performance. Du kan sikkert lave
en glimrende webserver i C eller Java.

Jeg ville selv bruge Java, hvis det var. Mest fordi man får så meget
forærende: URL styring, sockets, unicode/tegnsæt og meget andet.

-dennis

> Og så tænkte jeg om i kunne give mig noget hjælp hvad er hurtigts,mest
> stabilt, bedst at lave en webserver i.

Hvad der er hurtigst er der sikkert delte meninger om. Mit gær er, at
det kan laves ca. lige hurtigt i Java og C, hvis det er lavet smart.

Hvad angår stabilitet, vil jeg foretrække Java. Først og fremmest pga.
'checked exceptions'. Desuden skal du ikke bekymre dig om buffer
overflows, som er en hyppig fejl i webservere.

> og om I gad at fortælle mig hvad slags sikkerhed der skal være i en
> webserver

Det er svært at svare på. Der findes mange standarder og løsninger. Du
kunne læne dig op af noget af det, som apache har lavet: Apache web
server, Tomcat servlet container.

-dennis

---

"David Poulsen" <dpoulsen@e-box.dk> writes:

> Hejsa derude
>
> Jeg går og overvejer hvordan jeg skal lave en webserver og om det skal gøres
> i Java,VB, eller C.
>
> Og så tænkte jeg om i kunne give mig noget hjælp hvad er hurtigts,mest
> stabilt, bedst at lave en webserver i.

Java er nok et godt bud.

Hvad er det for en funktionalitet der skal opnås, og hvorfor vil du
ikke bruge en eksisterende webserver til formålet?

--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

Thorbjoern Ravn Andersen <thunderbear@bigfoot.com> writes:

> "David Poulsen" <dpoulsen@e-box.dk> writes:
>
> > i Java,VB, eller C.
> >
> > Og så tænkte jeg om i kunne give mig noget hjælp hvad er hurtigts,mest
> > stabilt, bedst at lave en webserver i.
>
> Java er nok et godt bud.

Det er vel næppe hverken hurtigst eller mest stabilt? Men det er afgjort
det af alternativerne, der gør det sværest at skrive spaghettikode.
Hvis effektivitet og stabilitet er højeste prioritet, så er C IMO
stadig nummer 1.

Og så tilslutter jeg mig spørgsmålet: Hvorfor ikke bruge en eksisterende
webserver - f.eks. Apache?

--
Jakob

---

Jakob Schmidt <sumus@aut.dk> writes:

> > Java er nok et godt bud.
>
> Det er vel næppe hverken hurtigst eller mest stabilt? Men det er afgjort
> det af alternativerne, der gør det sværest at skrive spaghettikode.
> Hvis effektivitet og stabilitet er højeste prioritet, så er C IMO
> stadig nummer 1.

Hvis man kan finde ud af at lave rigtig programmering med strenge.
Hvis man vakler mellem VB, C og Java, så har man nok ikke programmeret
så meget i nogen af sprogene, og vil derfor nok ryge i de typiske
fælder.

Her er Java betydeligt nemmere at danse med end C.

--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

Jakob Schmidt wrote:
> Thorbjoern Ravn Andersen <thunderbear@bigfoot.com> writes:
>
>
>>"David Poulsen" <dpoulsen@e-box.dk> writes:
>>
>>
>>>i Java,VB, eller C.
>>>
>>>Og så tænkte jeg om i kunne give mig noget hjælp hvad er hurtigts,mest
>>>stabilt, bedst at lave en webserver i.
>>
>>Java er nok et godt bud.
>
> Det er vel næppe hverken hurtigst eller mest stabilt? Men det er afgjort
> det af alternativerne, der gør det sværest at skrive spaghettikode.
> Hvis effektivitet og stabilitet er højeste prioritet, så er C IMO
> stadig nummer 1.

Effektivitet er efter min mening udtrykt af koden, og ikke af sproget /
runtime environment. Den performance man oplever er derimod selvfølgelig
påvirket af disse.

Jeg vil påstå, at en almindelig webserver kan laves lige hurtig i C og
Java. Hvis den er skrevet rigtigt bruges langt det meste tid på I/O, og
resten skulle der ikke være så meget forskel på med en moderne JVM.

Med hensyn til stabilitet ser jeg Java som mere stabil en C. Hvad får
dig til at synes det modsatte?

-dennis

---

Dennis Thrysøe <dt@netnord.dk> writes:

> Effektivitet er efter min mening udtrykt af koden, og ikke af sproget
> / runtime environment. Den performance man oplever er derimod
> selvfølgelig påvirket af disse.

Definer lige effektivitet?

>
> Jeg vil påstå, at en almindelig webserver kan laves lige hurtig i C og
> Java. Hvis den er skrevet rigtigt bruges langt det meste tid på I/O,
> og resten skulle der ikke være så meget forskel på med en moderne
> JVM.

Når du siger "lige hurtig" mener du så programmørtid eller hvor
hurtigt resultatet kører?

>
> Med hensyn til stabilitet ser jeg Java som mere stabil en C. Hvad får
> dig til at synes det modsatte?

Øh, har jeg sagt andet? Javaprogrammers stacktrace er ofte betydeligt
mere informative end C programmers ditto.
--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

Thorbjoern Ravn Andersen wrote:
> Dennis Thrysøe <dt@netnord.dk> writes:
>
>
>>Effektivitet er efter min mening udtrykt af koden, og ikke af sproget
>>/ runtime environment. Den performance man oplever er derimod
>>selvfølgelig påvirket af disse.
>
>
> Definer lige effektivitet?

Forbrug af begrænsede resourcer: Tid, hukommelse, CPU tid osv.

>>Jeg vil påstå, at en almindelig webserver kan laves lige hurtig i C og
>>Java. Hvis den er skrevet rigtigt bruges langt det meste tid på I/O,
>>og resten skulle der ikke være så meget forskel på med en moderne
>>JVM.
>
>
> Når du siger "lige hurtig" mener du så programmørtid eller hvor
> hurtigt resultatet kører?

Jeg mener den oplevede hastighed af programmet. Mit *gæt* er, at
programmøren der bruger Java er først færdig.

>>Med hensyn til stabilitet ser jeg Java som mere stabil en C. Hvad får
>>dig til at synes det modsatte?

> Øh, har jeg sagt andet?

Nope. Men det har Jakob Schmidt, som jeg svarede.

-dennis

---

Dennis Thrysøe <dt@netnord.dk> writes:

> Effektivitet er efter min mening udtrykt af koden, og ikke af sproget
> / runtime environment. Den performance man oplever er derimod
> selvfølgelig påvirket af disse.

Du har ret - mit ordvalg var forkert. Jeg mente ikke effektivitet, men
derimod performance.

> Jeg vil påstå, at en almindelig webserver kan laves lige hurtig i C og
> Java. Hvis den er skrevet rigtigt bruges langt det meste tid på I/O,
> og resten skulle der ikke være så meget forskel på med en moderne JVM.

Jeg skal ikke udelukke, at det er sandt, men et velskrevet veloptimeret
program i native objektkode kører stærkere end et tilsvarende fortolket
program (ja, Java er jo et fortolket sprog (*avav du må ikke slå*)). OP'en
spurgte jo, hvad der var hurtigst - ikke hvorvidt det er relevant.

> Med hensyn til stabilitet ser jeg Java som mere stabil en C. Hvad får
> dig til at synes det modsatte?

Jo, ja, jeg ved nu ikke rigtig, om det giver mening at diskutere, hvorvidt
et givet _sprog_ er stabilt. Det jeg mente - og det var indrømmet ikke
så let at se - var, at når man eksekverer Java, er der gang i et ekstra
lag software og dermed i teorien flere fejlkilder. Til gengæld er det
ufattelig nemt at skrive noget i C, der er er dybt ustabilt, mens det
er noget sværere i Java. Efter min mening (samme argumentation som din
egen mht. effektivitet) har det dog ikke noget med _sprogene_ at gøre.
Fejlfri C-kode har så at sige færre bevægelige dele - derfor.

Men det er da meget meget lettere at skrive ordentlig software i Java.

--
Jakob

---

Jakob Schmidt wrote:
> Dennis Thrysøe <dt@netnord.dk> writes:
>
>>Jeg vil påstå, at en almindelig webserver kan laves lige hurtig i C og
>>Java. Hvis den er skrevet rigtigt bruges langt det meste tid på I/O,
>>og resten skulle der ikke være så meget forskel på med en moderne JVM.
>
> Jeg skal ikke udelukke, at det er sandt, men et velskrevet veloptimeret
> program i native objektkode kører stærkere end et tilsvarende fortolket
> program (ja, Java er jo et fortolket sprog (*avav du må ikke slå*)). OP'en
> spurgte jo, hvad der var hurtigst - ikke hvorvidt det er relevant.

Korrekt. Vi kan ikke blive uenige om at C per definition må være
hurtigere. Om ikke andet, så på et akademisk plan.

Mit svar påstår, at der ikke er (behøver at være) nævneværdig forskel.

Så derfor er der to svar: Et på akademisk/teoretisk plan og et på "det
man ser og oplever"-plan.

>>Med hensyn til stabilitet ser jeg Java som mere stabil en C. Hvad får
>>dig til at synes det modsatte?
>
> Jo, ja, jeg ved nu ikke rigtig, om det giver mening at diskutere, hvorvidt
> et givet _sprog_ er stabilt. Det jeg mente - og det var indrømmet ikke
> så let at se - var, at når man eksekverer Java, er der gang i et ekstra
> lag software og dermed i teorien flere fejlkilder.

Igen er jeg enig. På samme plan som før ;) I praksis er der dog ikke så
mange fejl i JVM'erne.

> Til gengæld er det
> ufattelig nemt at skrive noget i C, der er er dybt ustabilt, mens det
> er noget sværere i Java.

Ja. Her må man give 'checked exceptions' konceptet en stor del af æren.
Og så selvfølgelig udeladelsen af pointere og andre typeløse ting.

> Efter min mening (samme argumentation som din
> egen mht. effektivitet) har det dog ikke noget med _sprogene_ at gøre.

Kun for nogle ting. Checked exceptions hjælper efter min mening med at
lave kode, hvor der tages hånd om uventede situationer. Java *sproget*
definerer også, at der ikke er pointere som kan tilgås før de er
initialiserede / efter de er frigivet. Herved undgår man en masse
"illegal access to 0x893983298" og buffer overruns med videre.

> Fejlfri C-kode har så at sige færre bevægelige dele - derfor.

Det er rigtigt. Men et fejlfrit (åh hvilken utopi i denne branche ;) C
og et fejlfrit Java program vil sikkert opføre sig ligeså pænt i praksis.

C programmet har jo sikkert også brug for nogle libraries til sockets,
tråde osv. (osv. osv. osv.)

> Men det er da meget meget lettere at skrive ordentlig software i Java.

Enig.

-dennis

---

Dennis Thrysøe <dt@netnord.dk> writes:

> Korrekt. Vi kan ikke blive uenige om at C per definition må være
> hurtigere. Om ikke andet, så på et akademisk plan.

Hvorfor? En moderne JVM oversætter til binær kode.


--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

Thorbjoern Ravn Andersen wrote:
> Dennis Thrysøe <dt@netnord.dk> writes:
>
>
>>Korrekt. Vi kan ikke blive uenige om at C per definition må være
>>hurtigere. Om ikke andet, så på et akademisk plan.
>
> Hvorfor? En moderne JVM oversætter til binær kode.

Jeps. Men denne oversættelse tager jo også tid. Og kun noget bytecode
oversættes til native kode.

Men det er var også derfor (JIT og andre smarte optimeringer) jeg
skriver "på et akademisk plan".

En JVM har større forpligtelser (sikkerhed, kodevalidering mv.) end et
C-program (eller dets runtime miljø). Det må jo koste lidt, selvom jeg
selv betrager det som uvæsentligt.

-dennis

---

Thorbjoern Ravn Andersen <thunderbear@bigfoot.com> writes:

> Dennis Thrysøe <dt@netnord.dk> writes:
>
> > Korrekt. Vi kan ikke blive uenige om at C per definition må være
> > hurtigere. Om ikke andet, så på et akademisk plan.
>
> Hvorfor? En moderne JVM oversætter til binær kode.

Ja, men det tager da tid at oversætte. Mener du, at den oversætter idet
programmet initialiseres, og så kører det nativt derefter? Det vil
selvfølgelig være begrænset, hvad man så mærker til forsinkelsen - specielt,
når det er en server, der er tale om.

Jeg kender ikke så meget til fortolkerdesign, men der må vel være nogle
af Javas muligheder, som skaber mere langsommelig kode?

Og generisk automatisk garbage collection koster altså mere end speciel
gennemkodet oprydning. Det gælder uanset, hvor moderne algoritmen er.

--
Jakob

---

Jakob Schmidt <sumus@aut.dk> writes:

> Ja, men det tager da tid at oversætte. Mener du, at den oversætter idet
> programmet initialiseres, og så kører det nativt derefter?

Det gør hotspot serverudgaven.

> Jeg kender ikke så meget til fortolkerdesign, men der må vel være nogle
> af Javas muligheder, som skaber mere langsommelig kode?
>
> Og generisk automatisk garbage collection koster altså mere end speciel
> gennemkodet oprydning. Det gælder uanset, hvor moderne algoritmen er.

Måske. Har du selv skrevet malloc/free systemet i den konfiguration
du tænker på?


--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

Thorbjoern Ravn Andersen wrote:
> Jakob Schmidt <sumus@aut.dk> writes:
>
>
>>Ja, men det tager da tid at oversætte. Mener du, at den oversætter idet
>>programmet initialiseres, og så kører det nativt derefter?
>
> Det gør hotspot serverudgaven.

Den oversætter vistnok ikke før den kan konstatere, at noget given kode
er en "hot spot" - altså bruges ofte. Så der opsamles nok lige lidt
statistik først.



-dennis

---

Thorbjoern Ravn Andersen <thunderbear@bigfoot.com> writes:

> Jakob Schmidt <sumus@aut.dk> writes:
>
> > Ja, men det tager da tid at oversætte. Mener du, at den oversætter idet
> > programmet initialiseres, og så kører det nativt derefter?
>
> Det gør hotspot serverudgaven.

Den del af diskussionen overlader jeg til Dennis.

> > Og generisk automatisk garbage collection koster altså mere end speciel
> > gennemkodet oprydning. Det gælder uanset, hvor moderne algoritmen er.
>
> Måske. Har du selv skrevet malloc/free systemet i den konfiguration
> du tænker på?

Nej, men jeg kunne vælge at gøre det.

Det er ikke pointen - pointen er, at det er relativt simpelt at få
malloc/free til at køre. Garbage collection på det ambitionsniveau, som
Java holder, er en kompliceret opgave. Mao. vil selv et middelmådigt
kompileret program på et OS med en middelmådig hukommelsesadministration
komme til at bruge mindre tid på at allokere og dealokere hukommelse,
end selv den bedste JVM alt andet lige. Det gider jeg altså ikke at
diskutere. Idéen med gc er jo netop at lade maskinen om at løse en
kedelig og kompliceret opgave, som er kilden til størstedelen af fejl
i software, der er udviklet med dynamisk hukommelsesallokering og uden
gc, i stedet for at de stakkels programmører skal sidde og kæmpe med det.
Så slipper vi for det, men det gør maskinen altså ikke - og det koster.

Men ja, det hele er jo ganske akademisk (ellers ville jeg nok heller
ikke gide .

--
Jakob

---

Jakob Schmidt <sumus@aut.dk> writes:

> > > Og generisk automatisk garbage collection koster altså mere end speciel
> > > gennemkodet oprydning. Det gælder uanset, hvor moderne algoritmen er.
> >
> > Måske. Har du selv skrevet malloc/free systemet i den konfiguration
> > du tænker på?
>
> Nej, men jeg kunne vælge at gøre det.
>
> Det er ikke pointen - pointen er, at det er relativt simpelt at få
> malloc/free til at køre. Garbage collection på det ambitionsniveau, som
> Java holder, er en kompliceret opgave. Mao. vil selv et middelmådigt

Det er det så sandeligt også at skrive en passende malloc/free
implementation. Den skal kunne en hel del, fx "remalloc", og eftersom
områder er statisk placerede, så bliver det hurtigt langhåret.

> end selv den bedste JVM alt andet lige. Det gider jeg altså ikke at
> diskutere. Idéen med gc er jo netop at lade maskinen om at løse en
> kedelig og kompliceret opgave, som er kilden til størstedelen af fejl
> i software, der er udviklet med dynamisk hukommelsesallokering og uden
> gc, i stedet for at de stakkels programmører skal sidde og kæmpe med det.

Tjah, det afhænger jo af opgaven.

Det er en rent akademisk situation, som kun kan afgøres ved at måle i
praksis :)


--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

Thorbjoern Ravn Andersen <thunderbear@bigfoot.com> writes:

> > JS: [gc kompliceret at implementere]
> Det er det så sandeligt også at skrive en passende malloc/free
> implementation. Den skal kunne en hel del, fx "remalloc", og eftersom
> områder er statisk placerede, så bliver det hurtigt langhåret.

Ja, der er selvfølgelig udfordringer dér. Men helt ærligt?

Desuden kan jeg udmærket programmere i C uden malloc/free. Det har
jeg faktisk prøvet i sådan en Lego-robot-dims. Det var hylemorsomt!

> Tjah, det afhænger jo af opgaven.

Ja, der findes opgaver, der er så simple, at de relativt let kan løses
på en cirka-optimal måde. For deres vedkommende er diskussionen endnu
mindre interessant.

--
Jakob

---

Jakob Schmidt <sumus@aut.dk> writes:

> Thorbjoern Ravn Andersen <thunderbear@bigfoot.com> writes:
>
> > > JS: [gc kompliceret at implementere]
> > Det er det så sandeligt også at skrive en passende malloc/free
> > implementation. Den skal kunne en hel del, fx "remalloc", og eftersom
> > områder er statisk placerede, så bliver det hurtigt langhåret.
>
> Ja, der er selvfølgelig udfordringer dér. Men helt ærligt?
>
> Desuden kan jeg udmærket programmere i C uden malloc/free. Det har
> jeg faktisk prøvet i sådan en Lego-robot-dims. Det var hylemorsomt!

C programmering er netop velegnet til hardwarenære ting.

Jeg vil dog gerne se dig lave et ikke-trivielt program med strenge
uden malloc/free :)

>
> > Tjah, det afhænger jo af opgaven.
>
> Ja, der findes opgaver, der er så simple, at de relativt let kan løses
> på en cirka-optimal måde. For deres vedkommende er diskussionen endnu
> mindre interessant.

Godt. Hvor går grænsen mellem interessante og ikke-interessante opgaver?
--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

Thorbjoern Ravn Andersen <thunderbear@bigfoot.com> writes:

> Godt. Hvor går grænsen mellem interessante og ikke-interessante opgaver?

For nærværende diskussion er en opgave interessant, hvis den indebærer
en vis kompleksitet mht. allokering af hukommelse, og det ikke altid
er let at afgøre, hvem der skal deallokere og hvornår.

--
Jakob

---

Mit programmeringssprog er hurtigere end dit programmeringssprog :)
Som jeg ser det, er der ting der er langt vigtigere end "execution
speed". Et eksempel er godt design og kendskab til
kompleksitetsbegreber. Se nedenstående link for en Java HTTPD der ved
brug af nonblocking I/O outperformer Apache. Det skal selvf. tages med
et gran salt, da funktionaliteterne ikke er identiske, men ikke desto
mindre er det interessant i context af både denne tråd, og det
oprindelige topic.

http://www.cs.berkeley.edu/~mdw/proj/seda/

Mvh Morten

---

Morten <usenet@kikobu.com> writes:

> Mit programmeringssprog er hurtigere end dit programmeringssprog :)

Njaeh - nu er der jo ingen af os, der har bekendt kulør mht. hvilket
programmeringssprog, der er "vores". Jeg vil ikke betegne hverken
C eller Java som "mit" sprog.

> Som jeg ser det, er der ting der er langt vigtigere end "execution
> speed". Et eksempel er godt design og kendskab til
> kompleksitetsbegreber.

Ja, det har vi jo også erkendt, og som du kan se, betegner vi selv
diskussionen som akademisk. Efter min mening er akademiske diskussioner
interessante - og de er afgørende for udviklingen af de teknologier,
der danner basis for løsning af meget reelle problemer.

> Se nedenstående link for en Java HTTPD der ved
> brug af nonblocking I/O outperformer Apache. Det skal selvf. tages med
> et gran salt, da funktionaliteterne ikke er identiske, men ikke desto
> mindre er det interessant i context af både denne tråd, og det
> oprindelige topic.

Meget interessant indeed. Hvis vi skal holde os til det fuldkommen
virkelighedsignorerende plan, så ændrer det dog intet på de akademiske
pointer i nærværende tråd.

--
Jakob

---

Morten <usenet@kikobu.com> writes:

> Se nedenstående link for en Java HTTPD der ved
> brug af nonblocking I/O outperformer Apache. Det skal selvf. tages med
> et gran salt, da funktionaliteterne ikke er identiske, men ikke desto
> mindre er det interessant i context af både denne tråd, og det
> oprindelige topic.
>
> http://www.cs.berkeley.edu/~mdw/proj/seda/

Apropos akademiske diskussioner, så lur mig om ikke ham fyren, der
har lavet det non-blocking IO halløj har måtte høre på, at det var
da unødvendigt med Javas trådmodel, og at den reelle performance
forskel ikke ville spille nogen rolle, og at det var da vist
en akademisk idé, han havde dér.

OK - hvis han holder sig fra usenet, så er han måske sluppet - men
ellers....

--
Jakob

---

On Thu, 27 Jun 2002 14:34:14 +0200
"David Poulsen" <dpoulsen@e-box.dk> wrote:
> Hejsa derude
>
> Jeg går og overvejer hvordan jeg skal lave en webserver og om det skal
> gøres i Java,VB, eller C.
>
> Og så tænkte jeg om i kunne give mig noget hjælp hvad er hurtigts,mest
> stabilt, bedst at lave en webserver i.
>
> og om I gad at fortælle mig hvad slags sikkerhed der skal være i en
> webserver

jeg lavede i sin tid en i java og det var rimeligt nemt. Det blev ikke
den kønneste, hurtigste eller mest JAVA agtige kode, men den virker fint
og kan give en god ide om hvad man skal have med i sin kode.
du kan finde den her:
http://www.kampsax.dtu.dk/~schulz/webserver

Der ligger også noget doxygen genereret dokumentation.


Forresten lavede jeg noget simpel serverside scripting i webserveren, så
man kunne lave sine egne [% tags %] i ".jhtml" sider. Ikke noget vildt
men ganske underholdende.

--
Kim Schulz - Freelance Development | Cynic, n.: One who looks
www.schulz.dk - En nørds bekendelser | through rose-colored glasses
www.linuxia.dk - hverdagens små hacks | with a jaundiced eye.

---

Det var godt nok noget af en debat.

Men jeg vil lige sige at det nok først og fremmest for sjov og for at lære
java,internetets opbygning, hvordan en webserver fungere og det andet er jeg
har arbejdet med java i 4 år mest som hobby og VB prøvede jeg men hoppede
fra da det var irriterende at man skal huske alle de ski.... dll'er og så
har jeg arbejdet lidt med C men som Win32 api til Windows og Java er fedt
ingen tvivl om det men det irritere mig bare at man ikke kan lave det om til
exe filer eller skrive, som jeg før har skrevet, det ind i C...
men det er småting og jeg synes også det er fedt at man får alle de ekstra
funktioner med "Netværk,Exceptions,Threads,og så videre" og så er det let
indprogrammere i sine programmer.

JAVA IS 2 COOL

Takker for al den respons



--
Best regards / Med venlig hilsen

David Poulsen
Email: dpoulsen@e-box.dk
ICQ: 150873892

---

David Poulsen wrote:
> Det var godt nok noget af en debat.
>
> [SNIP] men det irritere mig bare at man ikke kan lave det om til
> exe filer eller skrive, som jeg før har skrevet, det ind i C...

Det kan man også godt. Det har andre (og jeg selv) gjort. (altså
invokere Java fra native kode).

-dennis

---

Jeg har også men som skrevet før er det kun version 1.1.x som har virket,
men lad det ligge jeg skal vel nok på et eller andet tidspunkt lærer hvordan
man rigtigt gør det

Men selvfølgelig kan der være flere fejlkilder fordi java kører som et
tredje lag men det er nu mere sandsynligt for C at bryde sammen, synes jeg
nu (?)

--
Best regards / Med venlig hilsen

David Poulsen
Email: dpoulsen@e-box.dk
ICQ: 150873892