[Alg] Makkelijke platform-onafhankelijke IPC methode

[Verwijderd]

Persoonlijk heb ik het probleem dat is DOS (voor de eenvoudige interface) en Windows pr0gjes met elkaar te laten communiceren, en daar heb ik een (eigenlijk veel breder inzetbare) oplossing voor bedacht. Een (shared) RAM disk/FS zou het beste zijn, omdat je anders afhankelijk bent van de I/O capaciteit en load
van je HD.

Kort gezegd: 2 bisynchrone monodirectionele kanalen die samen 1 asynchroon bidirectioneel kanaal vormen.

Het 1 en ander communiceert met elkaar via een constructie van bestanden.

Dat wil zeggen:

2 kanalen: 1 upstream
1 downstream

De kanalen hebben 1 richting om de eigenlijke data over de sturen (monodirectioneel), maar synchroniseren de pakketjes wel (acknowledge bij ontvangst pakket), dus bisynchroon (zowel het datakanaal als het acknowledgekanaal lopen volgens een vastgesteld patroon).

De 2 kanalen werken niet gelijk met elkaar (asynchroon) maar het samen wel 2 richtingen (bidirectioneel).

En in de praktijk:

Ik beschrijf maar 1 kanaal, omdat de ander toch hetzelfde werkt (maar dan natuurlijk de andere kant op).

1. Ontvanger heeft loop waarin wordt gecheckt op een UNlockfile (een soort lockfile die aangeeft dat er data ontvangen kan worden).
2a. Zender stopt data in packetfile (een soort network packet als een file).
2b. Zender maakt unlockfile aan.
3c. Zender wacht in loop op acknowledgeunlockfile.
4a. Ontvanger detecteert unlockfile.
4b. Ontvanger leest packetfile.
4c. Ontvanger maakt acknowledgepacketfile aan, die eventueel korte boodschap terug bevat.
4d. Ontvanger maakt acknowledgeunlockfile aan.
5a. Zender detecteert acknowledgeunlockfile.
5b. Zender leest acknowledgepacketfile.
5c. Zender verwijdert unlockfile, packetfile, acknowledgepacketfile, acknowledgeunlockfile.
6. Ontvanger klaar voor volgende packet.
(evt. wachttijd tot gereedheid volgende packet)
7. De sequntie begint opnieuw.

Dit kan natuurlijk ook tussen andere OS'sen/architecturen/etc. toegepast worden, of als remote shell over een netwerk ofzow.

Wat vinden jullie ervan?

[Orphix]

Ik denk dat je beter een tcp verbinding kan zetten tussen twee applicaties die via de localhost interface werkt dan deze opzet.

Deze oplossing lijkt me namelijk enorm traag (wegschrijven/inlezen bestanden, latency tussen plaatsen van bestand en het detecteren ervan) en enorm cpu en resource intensief (aldoor pollen om te checken op een nieuw bestandje)

[curry684]

Je omschrijft exact hoe IPC in de 80'er jaren werkte tussen VMS en Unix clusters e.d.

Filebased IPC is echter gruwelijk inefficient omdat je filesystem het traagste onderdeel van de computer is per definitie (mechanisch). IPC-mechanismes als named pipes en TCP-channeling, en recenter bijv. SOAP zijn wat dat betreft veel efficienter en flexibeler.

Ik zie de bonus niet echt van wat je wil, gezien het feit dat er toch geen nieuwe software meer voor DOS ontwikkeld wordt (pas een jaar of 10 )

[Tomatoman]

Verwijderd schreef op maandag 17 januari 2005 @ 22:35:
Persoonlijk heb ik het probleem dat is DOS (voor de eenvoudige interface) en Windows pr0gjes met elkaar te laten communiceren, en daar heb ik een (eigenlijk veel breder inzetbare) oplossing voor bedacht. Een (shared) RAM disk/FS zou het beste zijn, omdat je anders afhankelijk bent van de I/O capaciteit en load
van je HD.

[implementatie-idee]

Wat vinden jullie ervan?

[list]
• Programmeren voor MS-DOS is zoiets als programmeren voor holbewoners. Je bent dan software aan het maken voor het 16-bits tijdperk, terwijl we inmiddels aan het overstappen zijn naar 64-bits. Nou zeggen die bits niet zo veel, maar het is een beetje alsof je een Flintstonemobiel bouwt om mee te doen aan Formule-1-races.
• Zoals Orphix en curry684 al aangaven is file-based communicatie traag en achterhaald.
• Er zijn prachtige, kant en klare oplossingen beschikbaar. SOAP, COM/DCOM, message broadcasting, er zijn talloze oplossingen.Dat is mijn oordeel. Misschien niet subtiel, maar wel helder

N.B.
Bedoel je met DOS-programma's niet consoleprogramma's voor Windows?

[Verwijderd]

Kun je onder Windows tegenwoordig nog RAM disks aanmaken? Zonder extra software waar je voor moet betalen, bedoel ik?

In elk geval zou ik lekker voor TCP/IP sockets gaan. En als je toch op Windows zit kun je één van de gaziljoen IPC methodes gebruiken die door Windows worden aangeboden: named pipes/mailslots/shared memory/DDE (ieks!)/custom windows messages... you name it.

En als je console programma (we gaan er voor het gemak even van uit dat je dat bedoelde, en niet een echt DOS programma) door je GUI programma uitgevoerd wordt, kun je ook gewoon de stdin en stdout redirecten en op die manier met het programma communiceren.

[ Voor 3% gewijzigd door Verwijderd op 18-01-2005 01:24 ]

[curry684]

Verwijderd schreef op dinsdag 18 januari 2005 @ 01:23:
En als je console programma (we gaan er voor het gemak even van uit dat je dat bedoelde, en niet een echt DOS programma) door je GUI programma uitgevoerd wordt, kun je ook gewoon de stdin en stdout redirecten en op die manier met het programma communiceren.

In het console subsystem heb je de hele Win32 API tot je beschikking en dus alle gangbare IPC-methodes, tot aan messages aan toe

[Verwijderd]

curry684 schreef op dinsdag 18 januari 2005 @ 01:28:
[...]

In het console subsystem heb je de hele Win32 API tot je beschikking en dus alle gangbare IPC-methodes, tot aan messages aan toe

Ik bedoelde de nadruk te leggen op uitgevoerd worden (dus opgestart vanuit het ouderprogramma voor korte taken), niet op als het een console programma is dan moet je redirecten.

Als het console programma voor korte taken uitgevoerd wordt lijkt I/O redirection me de netste manier om te communiceren (na command-line parameters, natuurlijk).

Als het om een langdraaiend achtergrondproces gaat is een van de andere methodes beter natuurlijk. Al roept dat wel de vraag op waarom het dan een console programma zou zijn, en niet een service of een GUI programma zonder GUI.

[ Voor 3% gewijzigd door Verwijderd op 18-01-2005 01:37 ]

[Verwijderd]

Owkee, misschien niet de beste oplossing, maar het is meer dan acceptabel voor mijn doeleinden.

En in ben volgens mij een soort holbewoner omdat ik DOS pr0ggen nog leuk vind

Niet iets om in de toekomst te gebruiken dus. Maar het helpt mij wel enorm makkelijk over het netwerk te commuiniceren. Mijn doeleinden vereisen toch geen snelle communicatie.

[MSalters]

Het zou me overigens niets verbazen als DOS eruit gaat met de release van Longhorn. MS heeft al tenminste 15 jaar geen DOS compiler meer gemaakt. In elk geval voel ik de pijn al als je zoiets probeert op een laptop, die disks zijn helemaal niet gemaakt voor dit soort onzin. 4200 rpm, en je mag al die domme filetjes ergens proberen te dumpen. Die hele HD eindigt volledig gefragmenteerd.

[curry684]

MSalters schreef op dinsdag 18 januari 2005 @ 10:48:
Het zou me overigens niets verbazen als DOS eruit gaat met de release van Longhorn.

DOS is er al sinds 1994 uit? En ik denk dat ze die emulator niet zo snel eruithalen, maar het blijft natuurlijk een emulator

[Verwijderd]

MSalters schreef op dinsdag 18 januari 2005 @ 10:48:
Het zou me overigens niets verbazen als DOS eruit gaat met de release van Longhorn.

Ik verwacht niet dat ze dat doen, of ze moeten iets goeds bedenken voor loginscripts, maar daarvoor blijft dos perfect. Dos gebruik ik nog dagelijks als systeembeheerder, echt super handig als je iets moet doen wat windows zo snel niet wil doen.

code:

rechtermuisknop @ map -> dos here

/me DOS

[eghie]

Ik gebruik ook vrij vaak commandline commando's en batch bestanden. Vind ze toch vrij handig, helemaal omdat je ze ook niet hoeft te compilen en je hebt al vrij snel een scriptje ik elkaar gebatst.

Denk niet dat hij er met longhorn eruit gaat eerlijk gezegd, want de commandline is nog steeds een vrij handig middel.

[mierenneuk mode]
Het is geen DOS. DOS is een besturingssysteem en de commandline functie in windows is geen besturingssysteem.[/mierenneuk mode]

[ Voor 20% gewijzigd door eghie op 18-01-2005 11:50 ]

[Onno]

Verwijderd schreef op dinsdag 18 januari 2005 @ 11:17:
[...]

Ik verwacht niet dat ze dat doen, of ze moeten iets goeds bedenken voor loginscripts, maar daarvoor blijft dos perfect.

De command line is geen DOS.

[curry684]

Verwijderd schreef op dinsdag 18 januari 2005 @ 11:17:
[...]

Ik verwacht niet dat ze dat doen, of ze moeten iets goeds bedenken voor loginscripts, maar daarvoor blijft dos perfect. Dos gebruik ik nog dagelijks als systeembeheerder, echt super handig als je iets moet doen wat windows zo snel niet wil doen.

code:

rechtermuisknop @ map -> dos here

/me DOS

De commandline mogelijkheden worden in Longhorn zelfs enorm uitgebreid Dat zijn echter zoals ik al zei gewoon Win32 programma's in het Console subsystem. DOS-programma's daarentegen worden binnen een wowexec (Windows-on-Windows) emulator proces uitgevoerd, alhoewel de meeste mensen het OS programma DOSBox prefereren voor dat soort ancient meuk

[Verwijderd]

Als ze er nou ook nog een fatsoenlijke scriptingtaal in zouden hangen (dus niet batch (*kots*) of VBScript (*braak*)) dan zou het helemaal perfect zijn.

Sinds ik er enige ervaring mee verkregen heeft gaat mijn voorkeur toch uit naar Linux als programmeerbaar Operating System.

Tekstbestandje uitvoerbaar maken -> naam van interpreter erin -> vlammen maar met dat script. En alle gangbare talen zijn zo'n beetje meegeleverd op een standaarddistributie. Dat is bij Windows helaas nogal wat anders...

[Tomatoman]

Verwijderd schreef op dinsdag 18 januari 2005 @ 06:55:
En in ben volgens mij een soort holbewoner omdat ik DOS pr0ggen nog leuk vind

eghie schreef op dinsdag 18 januari 2005 @ 11:49:
[mierenneuk mode]
Het is geen DOS. DOS is een besturingssysteem en de commandline functie in windows is geen besturingssysteem.[/mierenneuk mode]

Onno schreef op dinsdag 18 januari 2005 @ 11:50:
[...]

De command line is geen DOS.

Er wordt hier volgens mij behoorlijk langs elkaar heengepraat. De Zeurkous zegt - ook na navraag - dat hij MS-DOS gebruikt, terwijl anderen het over de command line hebben (= Windows). Maar De Zeurkous heeft het helemaal niet over de command line

Aangezien hij echter impliciet aangeeft dat het gaat om verschillende programma's op één computer denk ik dat De Zeurkous het niet begrijpt en stiekem toch gewoon een command-line programma gebruikt (dus geen MS-DOS!). Maar misschien heeft hij wel een paar virtual pc's tegelijkertijd op dezelfde machine draaien of zo, waarbij er één MS-DOS als besturingssysteem draait.

De Zeurkous, twee vragen om aan de verwarring een eind te maken:
1. Boot je de computer met Windows, met MS-DOS of gebruik je misschien virtual machines?
2. Welke compiler gebruik je en welke versie?

[Verwijderd]

tomatoman schreef op woensdag 19 januari 2005 @ 13:12:

[...]

De Zeurkous, twee vragen om aan de verwarring een eind te maken:
1. Boot je de computer met Windows, met MS-DOS of gebruik je misschien virtual machines?
2. Welke compiler gebruik je en welke versie?

1. Win98SE, dus met DOS VM die in Win98 is ingebouwd
2. Schrik niet: meestal QuickBasic 4.5 en QuickBasic PDS 7.1

Dus het _zijn_ DOS progjes, alleen die kunnen met de multitasking van Win98 naast elkaar draaien.

[Tomatoman]

OK, MS-DOS dus . In dat geval heb je inderdaad een probleem met moderne communicatietechnieken. Zelfs communicatie met behulp van memory-mapped files werkt dan niet, omdat er (voor zover ik weet) geen MS-DOS API voor beschikbaar is die compatible is met de Windows API. Mocht dat wel het geval zijn, dan zou ik daarvoor kiezen. Het grote voordeel is dat je het door beide applicaties gedeelde geheugen in de memory-mapped file in het werkgeheugen van de pc staat, zodat je geen harddisk en bestandssysteem als bottlenecks hebt.

Custom messages, DDE, COM, named pipes, SOAP, het is allemaal problematisch. Misschien kun je ergens een DOS-implementatie van een van deze technieken op de kop tikken (alles is beter dan file-based communicatie), maar ik geef je eerlijk gezegd weinig kans.

Dat gezegd hebbende moet ik toegeven dat jouw oplossing niet elegant is, maar wel werkend is te krijgen. Veel mooier zou echter het zijn als je DOS-progje een (32-bits) Windows DLL zou kunnen laden. Hier zijn misschien wel trucs voor. In de DLL kun je dan alle communicatie programmeren.

[Verwijderd]

Met een RAMdisk is het helemaal niet zo sloom, gewoon ff RAMDRIVE.SYS laden in CONFIG.SYS.

/me kent ook geen MS-DOS -> WIIN32 API.

Filebased is dus idd de beste oplossing.

edit: Een DLL laden met RUNDLL32.EXE kan wel, alleen er is dan geen feedback mogelijk.

[ Voor 50% gewijzigd door Verwijderd op 20-01-2005 06:53 . Reden: aanvulling ]

[unclero]

Ik zou zelf voor de TCP gaan.. ook op DOS

Interessant Linkje

[MSalters]

BASIC maakt TCP niet makkelijk, en communicatiesnelheid irrelevant. File-based is misschien een optie, maar zelfs in dat geval zou ik zoveel mogelijk directory-nivo operaties vermijden: gewoon binnen 1 file separators schrijven om je messages uit elkaar te houden.

Aan de andere kant, DOS/BASIC? Eenvoudige interface en makkelijk? Echt niet, een console-mode Windows app is echt makkelijker op het moment dat je iets moderns wil doen (netwerk, IPC, threads, etc).


Overigens is mijn gok over het einde van DOS dat COMMAND.COM verwijderd wordt (CMD.EXE blijft uiteraard) net zoals de mogelijkheid om 16-bits programma's te draaien (DOS mode/Win16)

[Verwijderd]

De DOS pr0gjes die ik schrijf zijn toch voor mijzelf, dus dat hoeft geen probleem te zijn, net zoals de snelheid. Oorspronkelijk had ik dit bedacht voor het synchroniseren tussen verschillende computers/processen voor mijn home-control systeempje. Synchroniseren van de communicatie gaat het makkelijkste met FPGA's en CPLD's over de parallele poort.

En een mooie interface hoeft geen probleem te zijn in DOS/BASIC, gewoon een paar CHR$(mooiteken%) om lijntjes/kadertjes te maken, tekst erin plaatsen en

code:

DO
 inchar$ = INKEY$
LOOP UNTIL NOT inchar$ = ""

SELECT CASE

[...]

END SELECT

Voor mij mooi genoeg