[C++] select() en standard in

[Verwijderd]

met de functie select kan je van een aantal sockets zien welke er klaar zijn om naar te schrijven of van te lezen.

Behalve sockets kan je ook andere file descriptors meegeven. Nu wil ik in mijn programma behalve van een aantal sockets ook van de standaard input weten of er iets te lezen valt. Dit krijg ik echter niet voor elkaar.

Ik heb even een klein voorbeeld programmaatje geschreven dat alleen de standaard input bekijkt. Volgens mij is de file descriptor die ik meegeef niet geldig want select retourneerd -1. (normaal gesproken retourneerd de functie het aantal file descriptors die "ready" zijn.

code:

#include <winsock.h>
#include <stdio.h> 

fd_set readfds ;
timeval timeout ;
int fdsReady ;
int running = 1 ;

int main (int argc, char *argv[]) 
{
    FD_ZERO (&readfds) ;                    // set is leeg
    FD_SET (fileno (stdin), &readfds) ;     // voeg stdin toe (fd van stdin is 0)
    
    timeout.tv_sec = 30 ;                   // timeout tijd op 30 seconden
    timeout.tv_usec = 0 ;

    printf ("prog started\n") ;
    while (running) {
        printf ("select called\n") ;
        fdsReady = select (1, &readfds, NULL, NULL, &timeout) ;
        printf ("fdsReady = %d\n", fdsReady) ;
        if (FD_ISSET (0, &readfds)) running = 0 ;
    }
    return 0 ;
}

Ik werk met windows XP maar de code moet wel enigszins portable worden.

[Soultaker]

Als ik het goed heb, zie ik dat select() in de Windows API alleen gedefinieerd is in winsock.h. Verder is FD_ISSET een macro die __WSAFDIsSet aanroept en het argument naar een socket cast. Ik denk dus, dat select in Windows uitsluitend op sockets werkt.

[JayTaph]

Select() kan gewoon met alle file-descriptors werken. fileno(stdin) mag gewoon.

Als je het portable wilt houden, dan zou ik fileno(stdin)+1 meegeven ipv grofweg 1. Misschien is stdin wel helemaal geen 0 op een ander platform.

Ik kan zo ook niet zien waarom het fout gaat. Ik zou errno() even afvangen en kijken wat voor foutmelding daar in staat (misschien WSA_STARTUP oid?)


En verder:

code:

if (FD_ISSET (0, &readfds)) running = 0 ;

Ik zou daarvan maken (portability):

code:

if (FD_ISSET (fileno(stdin), &readfds)) running = 0;

[edit]
dat kwam er verkeerd uit
[edit]

[Verwijderd]

die 0 en die 1 waren idd wel een beetje lomp, in het grotere programma zelf had ik dat ook niet maar dit is alleen ff een voorbeeld proggie. verder kan het heel goed kloppen dat het in windows niet gaat, hij geeft als error dat de file descriptor geen socket is

Iemand nog een idee hoe ik zonder threads toch tegelijk naar de sockets en de standaard input kan luisteren?

[igmar]

Select() kan gewoon met alle file-descriptors werken. fileno(stdin) mag gewoon.

Niet onder Windows :

File objects on Windows are not acceptable, but sockets are. On Windows, the underlying select() function is provided by the WinSock library, and does not handle file desciptors that don't originate from WinSock.

MAW : je kan geen filedescriptor gebruiken onder Windows in combinatie met select()

[igmar]

Als je het portable wilt houden, dan zou ik fileno(stdin)+1 meegeven ipv grofweg 1. Misschien is stdin wel helemaal geen 0 op een ander platform.

Het bovenstaande klopt ook niet : stdin, stdout en stderr zijn onderdeel van de POSIX standaard (en wellicht ook van ANSI-C), en hun gedrag en het feit dat ze een vast fd bezetten zijn hierin vastgelegd.

[JayTaph]

Het bovenstaande klopt ook niet : stdin, stdout en stderr zijn onderdeel van de POSIX standaard (en wellicht ook van ANSI-C), en hun gedrag en het feit dat ze een vast fd bezetten zijn hierin vastgeleg

stdin,err,out zijn inderdaad ANSI compliant, maar niet POSIX.

Maar hoe dan ook, je bent programeer-technischerwijs niet goed bezig als je dan maar hardcoded filedescriptors (of wat dan ook) erin gaat zetten. DAT het zo is, snapt iedereen die een beetje C kent wel, maar zelfs dan doe je het nog niet.

Ik kan me heel erg goed voorstellen (maar eerlijk is eerlijk, zelf ben ik het nog niet tegengekomen en dan ben ik op een redelijk wat aantal platformen bezig geweest), dat descriptor 0 voor iets anders wordt gebruikt, en dat stdin begint bij 1 (en misschien dat er helemaal geen stderr bestaat!).

Een C-compiler hoeft absoluut niet standaard te zijn. Dat is wel een ideale wereld natuurlijk, maar ik ga er mijn software niet op vastpinnen.




En over dat windows-select().. Da's gewoon dieptriest

Select() is een standaard BSD-functie en als windows zegt dat ze een BSD-like ip-stack hebben, dan mag je verwachten dat ze ook alles implementeren.. (niet dus.. )

[.oisyn]

Op maandag 25 februari 2002 14:38 schreef JayTaph het volgende:
Als je het portable wilt houden, dan zou ik fileno(stdin)+1 meegeven ipv grofweg 1. Misschien is stdin wel helemaal geen 0 op een ander platform.

ik vind fileno (stdin) + 1 nog slechter als gewoon 1 gebruiken eigenlijk... je hebt het tenslotte over stdout, dus wat heeft 'degene die na stdin komt' daarmee te maken?

fileno (stdout) lijkt me dus beter

.edit: farlane je hebt gelijk, hier stond onzin, had niet goed gelezen

[farlane]

Op maandag 25 februari 2002 22:35 schreef OiSyN het volgende:
ik vind fileno (stdin) + 1 nog slechter als gewoon 1 gebruiken eigenlijk...

Het is de bedoeling dat je je hoogste filedescriptor +1 meegeeft naar select(...). Het is niet gezegd dat stdout een hoger is dan stdin. (Theoretisch dan he....)

[curry684]

Op maandag 25 februari 2002 17:10 schreef Prommie het volgende:
Iemand nog een idee hoe ik zonder threads toch tegelijk naar de sockets en de standaard input kan luisteren?

WSARecv en WSASend kun je overlapped uitvoeren, evenals ReadFile en WriteFile. Vervolgens lekker met SleepEx(INFINITE, TRUE) in een alertable wait state gaan hangen tot er een overlapped operatie klaar is. Daarna met GetOverlappedResult en WSAGetOverlappedResult of met WaitForSingleObject(MyOverlappedEvent, 0) opvragen wie er nu eigenlijk klaar was.

Ik weet niet zeker of WinSock WSAEvents en reguliere kernel events exchangeable zijn, anders kun je zelfs gewoon met WaitForMultipleObjects wachten en krijg je meteen een return value die aangeeft wie er klaar is.

[curry684]

ps. wat is er eigenlijk mis mee om gewoon zoals de rest van de wereld in een aparte thread je socketcommunicatie te doen?

Sowieso kun je select ook een timeout geven van zeg 50ms ipv 30 seconden, en dan even checken of er al iets op stdin is verschenen. Zoniet, gezellig weer naar de select. Toetsenbordinvoer is gelukkig zelden tot nooit tijdskritiek, en ik moet de persoon nog tegenkomen die 20 aanslagen per seconde haalt (1200 per minuut... auw, ik haal krap 300 ).

[igmar]

stdin,err,out zijn inderdaad ANSI compliant, maar niet POSIX.

Maar hoe dan ook, je bent programeer-technischerwijs niet goed bezig als je dan maar hardcoded filedescriptors (of wat dan ook) erin gaat zetten. DAT het zo is, snapt iedereen die een beetje C kent wel, maar zelfs dan doe je het nog niet.

Inderdaad, alleen ANSI, niet POSIX, mijn fout.

fileno(stdin) is idd wat duidelijker als gewoon 0 gebruiken.

Wat betreft die Windhoos select() : De implementatie zit in de winsock.dll, en die kan alleen socket descriptors aan. Erg rare implementatie, maar ja, van de win32 API krijg ik zowiezo al hoofdpijn.

Voor de poster is het het makkelijkste om het lezen van stdin gewoon in een aparte thread te doen. Iets meer werk, maar wel te doen.




Ik kan me heel erg goed voorstellen (maar eerlijk is eerlijk, zelf ben ik het nog niet tegengekomen en dan ben ik op een redelijk wat aantal platformen bezig geweest), dat descriptor 0 voor iets anders wordt gebruikt, en dat stdin begint bij 1 (en misschien dat er helemaal geen stderr bestaat!).

Een C-compiler hoeft absoluut niet standaard te zijn. Dat is wel een ideale wereld natuurlijk, maar ik ga er mijn software niet op vastpinnen.




En over dat windows-select().. Da's gewoon dieptriest

Select() is een standaard BSD-functie en als windows zegt dat ze een BSD-like ip-stack hebben, dan mag je verwachten dat ze ook alles implementeren.. (niet dus.. )
[/quote]

[curry684]

Op dinsdag 26 februari 2002 09:57 schreef igmar het volgende:
Select() is een standaard BSD-functie en als windows zegt dat ze een BSD-like ip-stack hebben, dan mag je verwachten dat ze ook alles implementeren.. (niet dus.. )

Windows beweert niet een BSD-like IP-stack te hebben, Windows HEEFT een BSD stack en staat gebruik van de Berkeley, niet BSD, interface (send/recv/select/socket/etc) toe voor portability. Pure Win32 applicaties dienen echter welzeker WSARecv, WSAAsyncSelect e.d. te gebruiken, de standaard namelijk volgens WinSock.

Dat Windows toevallig dan vervolgens niet het hele systeem gaat zitten patchen zodat CreateFile een filedescriptor teruggeeft ipv een handle kun je hun niet kwalijk nemen. Ik ga Sun ook geen kwaaie brief schrijven dat CreateWindowEx het niet doet op Solaris.

[Verwijderd]

Op dinsdag 26 februari 2002 10:31 schreef curry684 het volgende:
Windows beweert niet een BSD-like IP-stack te hebben, Windows HEEFT een BSD stack en staat gebruik van de Berkeley, niet BSD, interface (send/recv/select/socket/etc) toe voor portability. Pure Win32 applicaties dienen echter welzeker WSARecv, WSAAsyncSelect e.d. te gebruiken, de standaard namelijk volgens WinSock.

Even een strikvraag: waarvoor staat BSD?

Dan het volgende: volgens de BSD standaard is een socket een filedescriptor. Windows implementeert sockets niet als filedescriptors (maar als een really ugly macro) en heeft dus geen BSD stack.

[igmar]

Windows beweert niet een BSD-like IP-stack te hebben, Windows HEEFT een BSD stack en staat gebruik van de Berkeley, niet BSD, interface (send/recv/select/socket/etc) toe voor portability. Pure Win32 applicaties dienen echter welzeker WSARecv, WSAAsyncSelect e.d. te gebruiken, de standaard namelijk volgens WinSock.

Standaard ? Welke standaard ? De enige reden waarom je die lelijke functies moet gebruiken is omdat die idioten bij M$ de TCP implementatie in een DLL hebben gegooid. Hoezo een achterlijk ontwerp, wel geheel in stijl met de Win32 API, ook een achterlijk ontwerp.

Dat Windows toevallig dan vervolgens niet het hele systeem gaat zitten patchen zodat CreateFile een filedescriptor teruggeeft ipv een handle kun je hun niet kwalijk nemen. Ik ga Sun ook geen kwaaie brief schrijven dat CreateWindowEx het niet doet op Solaris.

Dat is niet de issue. De issue hier is dat select() alleen maar op een socket werkt, en dat de rest van de wereld het ook op een filedescriptor laat werken. Dat dat ding dan intern een struct is zal mij een worst wezen.

Bovenstaande betekend weer eens dat je de meest standaard code die er is niet kan porten naar Windows.

[farlane]

Op dinsdag 26 februari 2002 11:06 schreef igmar het volgende:
Bovenstaande betekend weer eens dat je de meest standaard code die er is niet kan porten naar Windows.

Misschien onder Cygwin?

[curry684]

Op dinsdag 26 februari 2002 10:40 schreef mietje het volgende:
Even een strikvraag: waarvoor staat BSD?

Weinig strikvraag aan... de Berkeley socket-interface heeft verdomd weinig van doen met de gehele Berkeley Software Distribution. Het is enkel een klein onderdeel.

Dan het volgende: volgens de BSD standaard is een socket een filedescriptor. Windows implementeert sockets niet als filedescriptors (maar als een really ugly macro) en heeft dus geen BSD stack.

Err, wrong. Ik had het niet voor niets express over de Berkeley INTERFACE. Dat is de manier waarop je met het ding praat, niet de stack zelf. Achter de schermen heeft Windows NT de complete TCP-stack van BSD geripped (met toestemming), en ze hebben voor portability de interface ook toegankelijk gemaakt. Laat me even een stukje uit de Win32-docs van select en de FD_* macros quoten wat een hoop duidelijk maakt waarschijnlijk:

Internally, socket handles in an fd_set structure are not represented as bit flags as in Berkeley Unix. Their data representation is opaque. Use of these macros will maintain software portability between different socket environments.

Er wordt dus expliciet vermeld dat de interne representatie geen k*t van doen heeft met de Berkeley implementatie, maar daar dit OPAQUE oftewel ondoorzichtig is heb je er geen last van omdat je toch portability kunt verkrijgen door de wrappers te gebruiken.

Oftewel je hebt 2 interfaces: de WSA interface en de Berkeley interface. Deze praten beide achter de schermen tegen een Windows implementatie, die op lowlevel tegen een BSD-ported TCP-stack werkt.

[curry684]

Op dinsdag 26 februari 2002 11:06 schreef igmar het volgende:
Standaard ? Welke standaard ? De enige reden waarom je die lelijke functies moet gebruiken is omdat die idioten bij M$ de TCP implementatie in een DLL hebben gegooid. Hoezo een achterlijk ontwerp, wel geheel in stijl met de Win32 API, ook een achterlijk ontwerp.

Kun je me even kort uitleggen wat er zo achterlijk aan is?

Voordelen:
• Makkelijk upgradeable, patchable.
• Handige version control.
• Decentraal.

Nadelen:
• ?

Ik ben vast en zeker dom, en ik zie vast en zeker ook foutief geen nadelen in dat alle GUI-stuff in comctl32.dll, user32.dll e.d. zit, en dat de kernel in kernel32.dll zit en zo. Enlighten me...?

Dat is niet de issue. De issue hier is dat select() alleen maar op een socket werkt, en dat de rest van de wereld het ook op een filedescriptor laat werken. Dat dat ding dan intern een struct is zal mij een worst wezen.

Regel 1 uit Win32-docs voor select:

The Windows Sockets select function determines the status of one or more sockets, waiting if necessary, to perform synchronous I/O.

Lijkt me toch vrij duidelijk... en als jij iets wil gaan porten zonder uberhaupt de docs vluchtig (zeg de eerste regel) door te lezen ben jij volgens mij de 'idioot' en niet de heren van MS (erg kinderachtig trouwens dat dollar-teken).

Bovenstaande betekend weer eens dat je de meest standaard code die er is niet kan porten naar Windows.

Deze opmerking en de rest van je postings tot nu toe in deze topic zijn eigenlijk alleen maar 1 grote (onterechte) hate-mail richting Microsoft geweest, wat in ieder geval voor mij je geloofwaardigheid niet echt vergroot. Als je zonodig op Windows moet vloeken doe dat dan ergens anders terwijl wij hier in P&W mensen met hun programmeerproblemen helpen.

[curry684]

Erg interessant leesvoer voor zowel de topicstarter als Igmar: Porting from UNIX to Win32 met daarin een verwijzing naar Deviation from Berkeley Sockets


Altijd eerst dit soort docs doorlezen voordat je ervaring opgedaan met het ene OS wil gaan toespitsen op een ander OS...

[Verwijderd]

Op dinsdag 26 februari 2002 02:16 schreef curry684 het volgende:

[..]

WSARecv en WSASend kun je overlapped uitvoeren,

En als je echt een high performance app wilt (die helaas niet op de win9x/me os'en zal werken) gebruik je dit natuurlijk in combinatie met IOCompletionPorts!

[farlane]

Op dinsdag 26 februari 2002 18:55 schreef curry684 het volgende:

Voordelen:
• Makkelijk upgradeable, patchable.
• Handige version control.
• Decentraal.

Ik kan me herinneren dat punt 1 en 2 ook wel als onderdeel van de 'dll hell' werden afgedaan.

Dat het decentraal is is leuk, maar op welke manier is dat een voordeel?

Verder is de schrijver idd een beetje aan het flamen, maar geef toe, als je under een POSIX achtig iets werkt, en select(...) blijkt onder Win32 niet op normale file descriptors te werken, dan komt dat vreemd over.

[igmar]

Kun je me even kort uitleggen wat er zo achterlijk aan is?

Voordelen:
• Makkelijk upgradeable, patchable.
• Handige version control.
• Decentraal.

Nadelen:
• ?

Dat je weer functies moet gebruiken on de socket zaken te regelen. Met een typedef kom je heel ver, maar netjes vind ik het niet.

Ten tweede is mijn ervaring dat die TCP stack in Windows 95/98 met enige regelmaat kuren vertoond.

De voordelen ben ik het mee eens, maar wanneer upgrade je je TCP stack ?? Zelden zover ik weet. Een ander nadeel zijn de foutcodes : Je kan ze opvragen, maar niet omzetten in een normale melding. Met de rest van de Windows meldingen kan dat wel.

Ik ben vast en zeker dom, en ik zie vast en zeker ook foutief geen nadelen in dat alle GUI-stuff in comctl32.dll, user32.dll e.d. zit, en dat de kernel in kernel32.dll zit en zo. Enlighten me...?

Wel eens de Win32 API benaderd ?? Allemaal functies met 6 argumenten of meer met de meest vage structs. Je moet ALLES opzoeken zowat, zelfs naar aardig wat oefening. Niet echt wat ik handig noem. Gelukkig heeft VC function completion.

Lijkt me toch vrij duidelijk... en als jij iets wil gaan porten zonder uberhaupt de docs vluchtig (zeg de eerste regel) door te lezen ben jij volgens mij de 'idioot' en niet de heren van MS (erg kinderachtig trouwens dat dollar-teken).

Waarom doet dan MS net de zaken anders als de rest van de wereld ? Waarom een select() die geen FD's aankan ? Waarom niet standaard functies voor async communicatie ? Waarom POSIX calls die net anders werken als de UNIX versies ??

Deze opmerking en de rest van je postings tot nu toe in deze topic zijn eigenlijk alleen maar 1 grote (onterechte) hate-mail richting Microsoft geweest, wat in ieder geval voor mij je geloofwaardigheid niet echt vergroot. Als je zonodig op Windows moet vloeken doe dat dan ergens anders terwijl wij hier in P&W mensen met hun programmeerproblemen helpen.

Ik vloek niet op Windows, ik vloek op het feit dat ze het weer eens niet op de 'normale' manier doen. Maar daar kom je wel achter als je je eens in de WIN32 API vastbijt

[igmar]

Erg interessant leesvoer voor zowel de topicstarter als Igmar: Porting from UNIX to Win32 met daarin een verwijzing naar Deviation from Berkeley Sockets

Bekend documentje. We hebben toendertijd voor zowat alles een wrapper functie gemaakt om te voorkomen dat de hele code volzat met #ifdef / #endif.

Dat werkte op zich prima, maar het was helaas veel meer werk als we verwacht hadden, hoofdzakelijk door kleine verschillen in implementatie waar je niet zo snel bij stilstaat.

[igmar]

Misschien onder Cygwin?

Vast wel, alleen dat mochten we niet gebruiken

[Verwijderd]

Op dinsdag 26 februari 2002 18:44 schreef curry684 het volgende:
Weinig strikvraag aan... de Berkeley socket-interface heeft verdomd weinig van doen met de gehele Berkeley Software Distribution. Het is enkel een klein onderdeel.

Vrij vertaald: het heeft er niets mee van doen maar het hoort er wel bij.

Laat me even een stukje uit de Win32-docs van select en de FD_* macros quoten wat een hoop duidelijk maakt waarschijnlijk:

Eumz, ze "rippen" een ip-stack, maar vervolgens implementeren ze hem anders? Als je een implementatie van een stack overneemt, dan is het ook zonder meer mogelijk de API mee over te nemen, je hoeft dan geen "opaque" macro's te schrijven. Dit is gewoon MS hoggwash, er zijn wat algoritmes uit BSD geleend, maar het is wel degelijk een andere stack.

[JayTaph]

Eumz, ze "rippen" een ip-stack, maar vervolgens implementeren ze hem anders? Als je een implementatie van een stack overneemt, dan is het ook zonder meer mogelijk de API mee over te nemen, je hoeft dan geen "opaque" macro's te schrijven.

Hier kun je leven dat de highest filedescriptor niet eens gebruikt wordt, maar alleen ter compatibility bestaat.

Als MS dit ook gewoon had weggelaten, dan kon je nog gewoon aan de functie-aanroep al zien dat die select() niet compatible is met de "standaard" select().

Jammer dus dat je geen file-descriptors kunt gebruiken, maar je moet in ieder geval toegeven dat ze de stack (or at least de interface) niet consequent hebben geimplementeerd.

[.oisyn]

Op woensdag 27 februari 2002 09:04 schreef igmar het volgende:

Wel eens de Win32 API benaderd ?? Allemaal functies met 6 argumenten of meer met de meest vage structs. Je moet ALLES opzoeken zowat, zelfs naar aardig wat oefening. Niet echt wat ik handig noem. Gelukkig heeft VC function completion.

ik zal dan wel een kromme denkwijze hebben, maar naar een half jaartje te hebben geexperimenteerd met de Win32 API (die ik in het begin totaal onlogisch vond) vond ik het ineens WEL logisch in elkaar zitten, evenals de structs enz. En dat opzoeken is niet eens een probleem, alt+tab (msdn), functienaam intoetsen en hopla

Maar daar kom je wel achter als je je eens in de WIN32 API vastbijt

haaahahahaha, ik kan gewoon niet wachten op de reply van Curry

[Verwijderd]

Op woensdag 27 februari 2002 12:39 schreef JayTaph het volgende:
Hier kun je leven dat de highest filedescriptor niet eens gebruikt wordt, maar alleen ter compatibility bestaat.

Geheel im MS-stijl is deze pagina niet bereikbaar onder mozilla/linux

Jammer dus dat je geen file-descriptors kunt gebruiken, maar je moet in ieder geval toegeven dat ze de stack (or at least de interface) niet consequent hebben geimplementeerd.

Exactly my point Het interface is niet consequent, maar als de stack een "rip" van BSD zou zijn, zou het geen enkel probleem zijn de interface compatible/consequent te houden met BSD.

[JayTaph]

Op woensdag 27 februari 2002 14:40 schreef mietje het volgende:

[..]

Geheel im MS-stijl is deze pagina niet bereikbaar onder mozilla/linux

Hmm.. hier heb ik geen problemen met mozilla 0.9.4

[curry684]

Op woensdag 27 februari 2002 09:04 schreef igmar het volgende:
Wel eens de Win32 API benaderd??

Vaker dan jij gok ik.

Allemaal functies met 6 argumenten of meer met de meest vage structs. Je moet ALLES opzoeken zowat, zelfs naar aardig wat oefening. Niet echt wat ik handig noem. Gelukkig heeft VC function completion.

Tja zal wel aan mij liggen dat ik er nooit zo'n problemen mee heb... als een functie zoals StretchBlt (om een extreme te noemen) 11 argumenten nodig heeft, namelijk 2 keer 4 coordinaten, een source en een target DC, en een kopieermodus, heb ik liever die 11 parameters dan 1 achterlijke struct die ik moet vullen met dynamische data.

En JA ik vond de Win32 API ook rotzooierig toen ik er met Amiga-achtergrond voor het eerst in begon te graven, maar met een maandje zag ik de logica er ook wel ruimschoots in.

Ik vloek niet op Windows, ik vloek op het feit dat ze het weer eens niet op de 'normale' manier doen. Maar daar kom je wel achter als je je eens in de WIN32 API vastbijt

Als je 95+% van de markt beheerst ben je de standaard, of je het er nu mee eens bent of niet.

[curry684]

Op dinsdag 26 februari 2002 23:49 schreef farlane het volgende:
Ik kan me herinneren dat punt 1 en 2 ook wel als onderdeel van de 'dll hell' werden afgedaan.

Very true, maar jammer genoeg is dat dan ook altijd het directe gevolg van lamme programmeurs die juist niet de handige version-controle geimplementeerd hebben die DLL's mogelijk maken.

Dat het decentraal is is leuk, maar op welke manier is dat een voordeel?

Hoeft niet 300 keer meegedistribueerd te worden en op je HD te staan als 300 programma's hetzelfde stuk code wensen te gebruiken. Leuker nog, je mag van WinSock zowel versie 1.0 als 1.1 als 2.0 op je HD hebben staan, en programma's die om 1.1 vragen krijgen netjes de 1.1 die optimaal en uitontwikkeld is voor de gevraagde toepassingen.

[curry684]

Op woensdag 27 februari 2002 14:29 schreef OiSyN het volgende:
haaahahahaha, ik kan gewoon niet wachten op de reply van Curry

Het was een iets te open doel dus ik laat 'm maar liggen... Maar inderdaad denk ik niet dat ie bijvoorbeeld de 10e post in dit topic gelezen heeft als ie denkt dat ik een Win32-n00b ben...