🚀 go-pugleaf

On Mon, 17 May 1999 12:37:35 +0200, "Roland Reiss" <rreiss@eso.org>
wrote:

>Auf meinem PC mit P200MMX und NT4 SP4 funktioniert Microteks ScanSuite (1.2)
>nur, solange die Fritz!-SW (2.06) noch nicht installiert ist.

Scansuite 1.1, nicht 1.11 (!) verwenden, damit funzt es bei mir (nur
in Verbindung mit ScanWizard 2.47, 2.49 und 2.52, andere Kombinationen
liefen bei mir nicht). Auf die Fritz!Card als Ursache bin ich bis
jetzt nicht gekommen. Habe aber auch eine, k�nnte also gut die
Ursache sein (Scanner E6 mit dem mitgelieferten Mini-Adaptec-
Controller AE 1502).

Ich dachte schon, die Microtek-Leute w�rden das nie hinbekommen ...
Wie oft habe ich schon neue Versionen installiert in der Hoffnung es
w�rde endlich laufen um letztendlich wieder downzugraden.

Gru�  Bertram

PS: Falls Du mit ftpsearch oder filez nicht f�ndig wirst, ggf. PM an
mich, damit ich mal den IDTrans-Server anwerfe.
-----------------------

Markus Broede schrieb in Nachricht
<374090ea.0@news.munich.netsurf.de>...
> die das Betriebssystem Windows NT 4.0 immer
> wieder straucheln l��t.

hatte ich bisher nur mit einem der ersten Versionen von Fritz!Com. Fax
und EFT laufen hier ohne Probleme seit Jahren unter NT 4.0.

Dieter

Bertram Schlenker schrieb in Nachricht
<7hr15o$kvd$1@newsread.f.de.uu.net>...

>Dto. wenn beim Weg �ber den neuen T-Online-Decoder (z.B. weil auch
>noch auf CEPT-Seiten zugegriffen werden soll) gleichzeitig ein
Browser
>bzw. Newsreader �ber diesen Decoder gestartet ist und in der
>"falschen" Reihenfolge beendet wird, h�ngt das gesamte 16-Bit-System.
>Erst nach ca. 5 min. kann dann das ganze Teilsystem beendet werden.

hast Du bei T-Online unter den Web-Einstellungen 'WinSock �ber
Lader...' aktiviert ? Das hilft.

Ich hatte es auch mal, dass T-Online ne eigene WinSocket ins
Systemverzeichnis kopierte und nicht wieder umbenannte. Danach
ben�tigte JEDE 32-Bit-Anwendung ca. 5 Minuten, bis sie gestartet
werden konnte.

Dieter

On Tue, 18 May 1999 18:20:58 +0100, D.Boettcher@t-online.de (Dieter
Boettcher) wrote:

>Bertram Schlenker schrieb in Nachricht
><7hr15o$kvd$1@newsread.f.de.uu.net>...
>
>>Dto. wenn beim Weg �ber den neuen T-Online-Decoder (z.B. weil auch
>>noch auf CEPT-Seiten zugegriffen werden soll) gleichzeitig ein
>Browser
>>bzw. Newsreader �ber diesen Decoder gestartet ist und in der
>>"falschen" Reihenfolge beendet wird, h�ngt das gesamte 16-Bit-System.
>>Erst nach ca. 5 min. kann dann das ganze Teilsystem beendet werden.
>
>hast Du bei T-Online unter den Web-Einstellungen 'WinSock �ber
>Lader...' aktiviert ? Das hilft.

Ja, habe ich schon l�nger so konfiguriert, trotzdem passiert es. Ja
nie Browser bzw. Newsclient (bei mir Fort� Agent) offen lassen und
versuchen zuerst den T-Online-Decoder zu schlie�en, dann ist
Feierabend ... Decoder immer als letztes schlie�en.

Gru� Bertram
-----------------------

Es zweifelt niemand an, da� von AVM bei der Realisierung der Fritz!Cards die
Schnittstellenspezifikation CAPI 2.0 eingehalten wurde. Auch ich bin von der
AVM-Hardware nach wie vor �berzeugt.

Diese Beitragskette und meine pers�nlichen Erfahrungen zeigen jedoch sehr
deutlich, da� die Schwachstellen im Fritz!32-Paket liegen.

A prospos "Einhaltung der CAPI-Spezifikation": hier habe ich noch einen ganz
besonderen Leckerbissen. Man schaue sich einmal den auf der AVM-Site der
�ffentlichkeit zug�nglich gemachten Beispielcode in der CAPI-ADK an. Hier
wird an einer Stelle ganz glatt und sauber die Karte gepollt. Genau von
diesem Polling wird in der CAPI-Spezifikation mehrmals dringend abgeraten
(aus eigener Erfahrung wei� ich auch genau, warum). Sicherlich mu� in einer
Beispielanwendung kein musterg�ltiger und allen Fehlern standfester Code
geschrieben sein - aber wenigstens sollten die verwendeten Algorithmen der
CAPI-Spezifikation entsprechen. Und das tun sie in diesem Fall nicht.

Hans-Juergen Ortmann <hj.ortmann@writeme.com> schrieb in im Newsbeitrag:
37436632.19917029@news.avm.de...
> On 18 May 1999 06:26:00 GMT, bebes@gmx.de (Bertram Schlenker) wrote:
>
> >Mit dem Taytron-ISDN-Moni harmonieren die CAPIs schon
> >seit ca. 1 Jahr nicht mehr, d.h. immer H�nger beim Herunterfahren bei
> >mir.
>
> Du meinst bestimmt: der Taytron-ISDN-Monitor ist keine anst�ndige CAPI
> Anwendung...
>
> CAPIs k�nnen nicht 'harmonieren'; das ganze ist eine
> Schnittstellenspezifikation - und die wird von FRITZ!Cards recht genau
> eingehalten.
>
> Hans-J�rgen
>
> --
> Hans-Juergen Ortmann
> hj.ortmann@writeme.com

Es zweifelt niemand an, da� von AVM bei der Realisierung der Fritz!Cards die
Schnittstellenspezifikation CAPI 2.0 eingehalten wurde. Auch ich bin von der
AVM-Hardware nach wie vor �berzeugt.

Diese Beitragskette und meine pers�nlichen Erfahrungen zeigen jedoch sehr
deutlich, da� die Schwachstellen im Fritz!32-Paket liegen.

A prospos "Einhaltung der CAPI-Spezifikation": hier habe ich noch einen ganz
besonderen Leckerbissen. Man schaue sich einmal den auf der AVM-Site der
�ffentlichkeit zug�nglich gemachten Beispielcode in der CAPI-ADK an. Hier
wird an einer Stelle ganz glatt und sauber die Karte gepollt. Genau von
diesem Polling wird in der CAPI-Spezifikation mehrmals dringend abgeraten
(aus eigener Erfahrung wei� ich auch genau, warum). Sicherlich mu� in einer
Beispielanwendung kein musterg�ltiger und allen Fehlern standfester Code
geschrieben sein - aber wenigstens sollten die verwendeten Algorithmen der
CAPI-Spezifikation entsprechen. Und das tun sie in diesem Fall nicht.


Hans-Juergen Ortmann <hj.ortmann@writeme.com> schrieb in im Newsbeitrag:
37436632.19917029@news.avm.de...
> On 18 May 1999 06:26:00 GMT, bebes@gmx.de (Bertram Schlenker) wrote:
>
> >Mit dem Taytron-ISDN-Moni harmonieren die CAPIs schon
> >seit ca. 1 Jahr nicht mehr, d.h. immer H�nger beim Herunterfahren bei
> >mir.
>
> Du meinst bestimmt: der Taytron-ISDN-Monitor ist keine anst�ndige CAPI
> Anwendung...
>
> CAPIs k�nnen nicht 'harmonieren'; das ganze ist eine
> Schnittstellenspezifikation - und die wird von FRITZ!Cards recht genau
> eingehalten.
>
> Hans-J�rgen
>
> --
> Hans-Juergen Ortmann
> hj.ortmann@writeme.com

On Tue, 18 May 1999 22:46:21 +0200, "Markus Broede"
<markus.broede@munich.netsurf.de> wrote:

>A prospos "Einhaltung der CAPI-Spezifikation": hier habe ich noch einen ganz
>besonderen Leckerbissen. Man schaue sich einmal den auf der AVM-Site der
>�ffentlichkeit zug�nglich gemachten Beispielcode in der CAPI-ADK an. Hier
>wird an einer Stelle ganz glatt und sauber die Karte gepollt. Genau von
>diesem Polling wird in der CAPI-Spezifikation mehrmals dringend abgeraten

wo (genau) steht das denn? ist mir noch nie aufgefallen, da� das dort
steht. und ich lese fast jeden tag darin...

pollen der capi ist vielleicht nicht sch�n. aber erlaubt. und nirgends
in der capi-spec wird "mehrmals dringend abgeraten" davon!!!

>(aus eigener Erfahrung wei� ich auch genau, warum). Sicherlich mu� in einer
>Beispielanwendung kein musterg�ltiger und allen Fehlern standfester Code
>geschrieben sein - aber wenigstens sollten die verwendeten Algorithmen der
>CAPI-Spezifikation entsprechen. Und das tun sie in diesem Fall nicht.

das ist demnach nicht richtig. es ist erlaubt, wenn auch nicht
besonders elegant.


mfg
werner

Hi !

Ich selbst habe auch eine Fritz-Card und habe daher mittlerweile so meine
Erfahrungen mit dem Fritz!32 - Paket unter Windows NT 4.0 gemacht. In vielen
harten N�chten und unz�hligen Systemabst�rzen bin ich immer wieder �ber die
Fritz!32 - Software gestolpert, die das Betriebssystem Windows NT 4.0 immer
wieder straucheln l��t.

H�rtestes Beispiel ist Fritz!Fax: es ist doch tats�chlich m�glich, einen NT
4.0 - Rechner, auf dem Fritz!Fax auf Empfang ist, per Telefonanruf und
Verursachen eines (sehr wahrscheinlichen) Fehlers beim Verbindungsaufbau zum
sofortigen System-Halt zu bewegen ("blauer Bildschirm" mit Dump). Man stelle
sich das vor: da kommt ein Fax rein und Dein Rechner h�lt mir nichts, Dir
nichts einfach an. Ich habe diesen Fehler an mehreren verschiedenen Rechnern
erzeugen k�nnen, so da� die Vermutung naheliegt, da� er an allen Rechnern
reproduzierbar ist.

Mit diesem kleinen Beispiel (ich habe noch weitere) m�chte ich nur
verdeutlichen und leider feststellen, da� das komplette Softwarepaket von
den Entwicklern nur sehr bescheiden nach Windows NT portiert worden sein
kann.

Seit ich meinen Anrufbeantworter und ein Faxprogramm per CAPI selbst
gestrickt habe, laufen meine Softwaren allesamt wieder problemlos.

Das Dumme ist nur, da� man den AVM-Leuten nat�rlich nichts nachweisen kann,
da mir deren Quellcode nicht vorliegt.

Kurz und gut, ich kann nur w�rmstens raten: Finger weg von Fritz!32 unter NT
4.0  (unter Windows 9x sind mir derart gravierende Probleme nicht bekannt).



Roland Reiss <rreiss@eso.org> schrieb in im Newsbeitrag:
7horh9$qlk$1@fu-berlin.de...
> Auf meinem PC mit P200MMX und NT4 SP4 funktioniert Microteks ScanSuite
(1.2)
> nur, solange die Fritz!-SW (2.06) noch nicht installiert ist. Sobald
Fritz!
> installiert ist, stuerzt ScanDetect beim Start von ScanSuite ab. ScanSuite
> selbst ist sehr instabil, d.h. es stuerzt bei manchen Aktionen
> ebenfalls ab.  Deinstalliert man Fritz!, laeuft wieder alles bestens.
>
> Ich hab' das Ganze auf einer ansonsten jungfraeulichen NT-Installation
> getestet, um andere Verursacher auszuschliessen. Der X6 Scanner haengt
> zusammen mit diversen Platten am On-Board SCSI-Kontroller eines Gigabyte
> 586DX Mainboards.
>
> Die Rechnerkonfiguration:
>
> NT4 SP4, mit SP1 geht's aber auch nicht...
> Gigabyte 586DX mit Adaptec 2940 on-board
> P200MMX
> 192MB RAM
> Matrox Millennium I
> Miro Video PCTV
> 3Com 509 Ethernet
> SB AWE32
> Fritz!Card Classic
> 2 Ultra SCSI Festplatten (IBM)
> 1 CDROM
> 1 ZIP 100
> Microtek X6 Scanner, Firmware 1.0, Scanwizard 2.53, ScanSuite 1.2
>
> Hat jemand aehnliche Erfahrungen gemacht oder weiss vielleicht eine
Loesung?
>
> --
> Roland Reiss
>
>
>
>

On 18 May 1999 02:38:58 GMT, tobias.ertl@uumail.de (Tobias Ertl)
wrote:

>Markus Broede schrieb:
>
>>Mit diesem kleinen Beispiel (ich habe noch weitere) m�chte ich nur
>>verdeutlichen und leider feststellen, da� das komplette Softwarepaket von
>>den Entwicklern nur sehr bescheiden nach Windows NT portiert worden sein
>>kann.
>
>>Das Dumme ist nur, da� man den AVM-Leuten nat�rlich nichts nachweisen kann,
>>da mir deren Quellcode nicht vorliegt.
>>
>>Kurz und gut, ich kann nur w�rmstens raten: Finger weg von Fritz!32 unter NT
>>4.0  (unter Windows 9x sind mir derart gravierende Probleme nicht bekannt).
>
>Da mu� ich Dir aber ein wenig widersprechen und mitteilen,da� ich mit
>der Fritz-Software unter NT noch _nie_ Probleme hatte.

Hi Tobias,

sch�n f�r Dich. Mit dem Taytron-ISDN-Moni harmonieren die CAPIs schon
seit ca. 1 Jahr nicht mehr, d.h. immer H�nger beim Herunterfahren bei
mir.

Dto. wenn beim Weg �ber den neuen T-Online-Decoder (z.B. weil auch
noch auf CEPT-Seiten zugegriffen werden soll) gleichzeitig ein Browser
bzw. Newsreader �ber diesen Decoder gestartet ist und in der
"falschen" Reihenfolge beendet wird, h�ngt das gesamte 16-Bit-System.
Erst nach ca. 5 min. kann dann das ganze Teilsystem beendet werden.

Wurde schon in den internen T-Online-Gruppen diskutiert und passiert
nur mit den neuesten CAPI-Versionen der Fritz!Card. Zum Scanner
habe ich schon weiter oben in diesem Thread etwas geschrieben,
betrifft mich auch.

Also so mit der rosa Brille sehe ich seither AVM auch nicht mehr. Alle
Fehler sind schon l�ngere Zeit bekannt und es wird trotzdem
nicht nachgebessert. Mit der Anwendungssoftware selbst hatte ich
bisher auch wenig Probleme.

Gru� Bertram
----------------------

On 18 May 1999 06:26:00 GMT, bebes@gmx.de (Bertram Schlenker) wrote:

>Mit dem Taytron-ISDN-Moni harmonieren die CAPIs schon
>seit ca. 1 Jahr nicht mehr, d.h. immer H�nger beim Herunterfahren bei
>mir.

Du meinst bestimmt: der Taytron-ISDN-Monitor ist keine anst�ndige CAPI
Anwendung...

CAPIs k�nnen nicht 'harmonieren'; das ganze ist eine
Schnittstellenspezifikation - und die wird von FRITZ!Cards recht genau
eingehalten.

Hans-J�rgen

--
Hans-Juergen Ortmann
hj.ortmann@writeme.com

F�r einen, der (fast) jeden Tag in etwas liest, scheinst Du nicht sehr genau
zu lesen. Hier ist die Stelle.

In der Datei "capi.c" findest Du folgenden Code:

/*--------------------------------------------------------------------------
*\
 * Handle_CAPI_Msg: the main routine, checks for messages and handles them
\*--------------------------------------------------------------------------
*/
void Handle_CAPI_Msg(void) {
    MESSAGE_EXCHANGE_ERROR  Info;
    int       count;

    count=0;
    do {
 switch (Info = CAPI_GET_CMSG(CMSG, Appl_Id)) {
 case 0x0000:        /*----- a message has been read -----*/
     switch (CMSG->Subcommand) {
     case CAPI_CONF:
  Handle_Confirmation();
  break;

     case CAPI_IND:
  Handle_Indication();
  break;

     default:    /*----- neither indication nor confirmation ???? -----*/
  puts("Error: Unknown subcommand in function Handle_CAPI_Msg");
  return;
     }
     break;

 case 0x1104:
     return; /*----- messagequeue is empty -----*/

 default:
     puts("Error: CAPI_GET_CMSG returns Info != 0 in function
Handle_CAPI_Msg");
     return;
 }
 count++;
    } while (count < 6);    /*----- CAPI is checked maximal 5 times before
returning -----*/
}

Hier steht sogar im Kommentar, da� die CAPI bis zu 5x gepollt wird !

Die entsprechenden Hinweise in der CAPI-Spezifikation (die Du wahrscheinlich
auch mehrmals t�glich liest) findest Du in der Datei "Capi20-1.pdf" (zu
finden bei www.capi.org) bei:
- Kapitel 4.2.1.3, Absatz 1
- Kapitel 4.2.2.4

Zum Thema "Polling der ISDN-Karte" kann ich nur immer wieder schreiben: es
ist nicht nur nicht elegant (besser formuliert: es ist sehr schlechter
Programmierstil), die Karte zu pollen, sondern f�hrt auf vielen Rechnern
unter Windows NT 4.0 bei Eintreffen eines Calls nach 4 Sekunden zum
System-Halt.

Allerdings r�ume ich ein, da� die meisten CAPI-Anwendungen faulerweise die
Karte pollen, was jedoch diesen Fehler nicht weniger brisant macht, sondern
nur verdeutlicht, da� die jeweiligen Entwickler oder Programmierer kein Geld
oder keine Zeit haben, sich tief genug mit Betriebssystemen zu besch�ftigen.
Es ist eben sehr bequem, eine CAPI-Anwendung unter Win 9.x zu schreiben und
dabei so zu codieren, da� einfachst auf NT portiert werden kann - denn zur
Umgehung des Pollings unter NT mu� man sich mit eben dem Thema
"Multi-Threading" besch�ftigen (reine Flei�arbeit).


Werner Fehn <wfehn@popmail.oche.de> schrieb in im Newsbeitrag:
3741ee5a.749380652@news.oche.de...
> On Tue, 18 May 1999 22:46:21 +0200, "Markus Broede"
> <markus.broede@munich.netsurf.de> wrote:
>
> >A prospos "Einhaltung der CAPI-Spezifikation": hier habe ich noch einen
ganz
> >besonderen Leckerbissen. Man schaue sich einmal den auf der AVM-Site der
> >�ffentlichkeit zug�nglich gemachten Beispielcode in der CAPI-ADK an. Hier
> >wird an einer Stelle ganz glatt und sauber die Karte gepollt. Genau von
> >diesem Polling wird in der CAPI-Spezifikation mehrmals dringend abgeraten
>
> wo (genau) steht das denn? ist mir noch nie aufgefallen, da� das dort
> steht. und ich lese fast jeden tag darin...
>
> pollen der capi ist vielleicht nicht sch�n. aber erlaubt. und nirgends
> in der capi-spec wird "mehrmals dringend abgeraten" davon!!!
>
> >(aus eigener Erfahrung wei� ich auch genau, warum). Sicherlich mu� in
einer
> >Beispielanwendung kein musterg�ltiger und allen Fehlern standfester Code
> >geschrieben sein - aber wenigstens sollten die verwendeten Algorithmen
der
> >CAPI-Spezifikation entsprechen. Und das tun sie in diesem Fall nicht.
>
> das ist demnach nicht richtig. es ist erlaubt, wenn auch nicht
> besonders elegant.
>
>
> mfg
> werner

On Wed, 19 May 1999 09:10:09 +0200, "Markus Broede"
<markus.broede@munich.netsurf.de> wrote:

>F�r einen, der (fast) jeden Tag in etwas liest, scheinst Du nicht sehr genau
>zu lesen. Hier ist die Stelle.
>
>In der Datei "capi.c" findest Du folgenden Code:

du sprachst von der capi spec. nicht von der avm-implementation der
capi-applikation.

>Die entsprechenden Hinweise in der CAPI-Spezifikation (die Du wahrscheinlich
>auch mehrmals t�glich liest) findest Du in der Datei "Capi20-1.pdf" (zu
>finden bei www.capi.org) bei:
>- Kapitel 4.2.1.3, Absatz 1
>- Kapitel 4.2.2.4

hier wird nicht mehrmals dringend davon abgeraten (wie du behauptet
hast), sondern empfohlen auf das pollen zu verzichten und die
signalisierungsfunktion zu benutzten. nicht aus gr�nden der
stabilit�t, sondern aus gr�nden der systemlast. 

>Zum Thema "Polling der ISDN-Karte" kann ich nur immer wieder schreiben: es
>ist nicht nur nicht elegant (besser formuliert: es ist sehr schlechter
>Programmierstil),

na das h�rt sich schon viel besser an: 100% agree :)

>die Karte zu pollen, sondern f�hrt auf vielen Rechnern
>unter Windows NT 4.0 bei Eintreffen eines Calls nach 4 Sekunden zum
>System-Halt.

das ist dann ein fehler in der capi-treiber-implementation. capi ist
aber nur eine schnittstelle (und keine implementation). nach capi ist
pollen erlaubt und auf einer fehlerfreien implementation auch ohne
probleme m�glich.

aber nicht sch�n. da geb ich dir recht.

>Allerdings r�ume ich ein, da� die meisten CAPI-Anwendungen faulerweise die
>Karte pollen, was jedoch diesen Fehler nicht weniger brisant macht, sondern
>nur verdeutlicht, da� die jeweiligen Entwickler oder Programmierer kein Geld
>oder keine Zeit haben, sich tief genug mit Betriebssystemen zu besch�ftigen.
>Es ist eben sehr bequem, eine CAPI-Anwendung unter Win 9.x zu schreiben und
>dabei so zu codieren, da� einfachst auf NT portiert werden kann - denn zur
>Umgehung des Pollings unter NT mu� man sich mit eben dem Thema
>"Multi-Threading" besch�ftigen (reine Flei�arbeit).

win95 und nt unterscheiden sich nicht in der systematik der
programmierung. bei beiden ist die capi-definition die gleiche. bei
beiden empfiehlt sich mutithreading f�r die signalisierungsfunktion.


mfg
werner (entwicklung isdn, elsa ag)

Hi

Was ist eigentlich "Pollen"??
Wenn ich bei mir auf DF� Verbindung klicke dauert es ca. 10 sek bis das
Fenster "Verbinden mit" erscheint.
Liegt das am Pollen??

MfG
Daniel

Daniel Platz schrieb in Nachricht <7hvdli$85g$1@news04.btx.dtag.de>...
>Was ist eigentlich "Pollen"??

alle paar Millisekunden nachschauen, ob Daten f�r die �bertragung
bereitstehen. Das kostet Zeit und wirkt sich auf andere Anwendungen
st�rend aus.

Die feinere Art w�re, sich nur um die �bertragung zu k�mmern, WENN
Daten wirklich anstehen. Dazu bedarf es einer
Unterbrechungsanforderung (Interrupt-Handling).

Dieter

Bertram Schlenker schrieb in Nachricht
<7hsbdl$jmh$1@newsread.f.de.uu.net>...

[T-Online]
>Ja, habe ich schon l�nger so konfiguriert, trotzdem passiert es. Ja
>nie Browser bzw. Newsclient (bei mir Fort� Agent) offen lassen und
>versuchen zuerst den T-Online-Decoder zu schlie�en, dann ist
>Feierabend ... Decoder immer als letztes schlie�en.


Warum verwendet Ihr nicht einfach das DF�-Netzwerk? Ist in meinen Augen viel
komfortabler.

Sch�ne Gr��e

Oliver Fischer

Hallo Werner,

leider habe ich wegen Providerwechsels erst jetzt Deinen Beitrag empfangen
k�nnen. Hier meine Antwort:

> hier wird nicht mehrmals dringend davon abgeraten (wie du behauptet
> hast), sondern empfohlen auf das pollen zu verzichten und die
> signalisierungsfunktion zu benutzten. nicht aus gr�nden der
> stabilit�t, sondern aus gr�nden der systemlast.

Vom Unterschied zwischen Stabilit�t und Systemlast steht nichts in der
Spezifikation, das ist Deine pers�nliche Interpretation, die hinsichtlich
Uniprozessorsystemen auch stimmt. Bei Multiprozessorsystemen ist das jedoch
auch eine Frage der Stabilit�t.

> das ist dann ein fehler in der capi-treiber-implementation. capi ist
> aber nur eine schnittstelle (und keine implementation). nach capi ist
> pollen erlaubt und auf einer fehlerfreien implementation auch ohne
> probleme m�glich.

Dachte ich eigentlich auch, aber der Hersteller meiner
CAPI-Treiber-Implementation bestreitet dies nat�rlich !

> >Allerdings r�ume ich ein, da� die meisten CAPI-Anwendungen faulerweise
die
> >Karte pollen, was jedoch diesen Fehler nicht weniger brisant macht,
sondern
> >nur verdeutlicht, da� die jeweiligen Entwickler oder Programmierer kein
Geld
> >oder keine Zeit haben, sich tief genug mit Betriebssystemen zu
besch�ftigen.
> >Es ist eben sehr bequem, eine CAPI-Anwendung unter Win 9.x zu schreiben
und
> >dabei so zu codieren, da� einfachst auf NT portiert werden kann - denn
zur
> >Umgehung des Pollings unter NT mu� man sich mit eben dem Thema
> >"Multi-Threading" besch�ftigen (reine Flei�arbeit).
>
> win95 und nt unterscheiden sich nicht in der systematik der
> programmierung. bei beiden ist die capi-definition die gleiche. bei
> beiden empfiehlt sich mutithreading f�r die signalisierungsfunktion.
>

Da gebe ich Dir vollkommen recht und r�ume ein, dies ungl�cklich formuliert
zu haben. Sowohl CAPI-Spezifikation, als auch die Systemreferenzen von Win95
und NT propagieren identisches Systemverhalten. In der Praxis jedoch zeigen
sich die Unterschiede insbesondere (schon wieder) bei
Multiprozessorsystemen. Den Auswirkungen dieser Unterschiede kann man jedoch
durch genaueres Studium und gewissenhafte Verwendung der
Multithreading-Technik aus dem Weg gehen.