Hallo an die Runde,
nach längerer Abstinenz (15 Jahre) möcht ich alte
Anwendungen (damals mit Turbo Pascal)aufgreifen:

- Messwerteingänge über Gameport, Soundkarte und
A-D-Wandler (über den seriellen Port).

- Nutzung der Grafik

Unter Windows ist heute kein Zugriff auf die Ports
mehr möglich (mit Turbo Pascal).

Ich muss mich nun entscheiden ob z.B.

Delphi der "richtige" Weg ist oder
ob Free Pascal unter Linux auch geht.

Kann mir jemand Tipps geben bzw. eine
Einschätzung zu folgenden Fragen geben?

- Ist der gpm-Bug bei Free Pascal auf Debian nur
ein Schönheitsfehler der Enwicklungsumgebung
oder gibt es auch weitere Auswirkungen?

- Bei ersten Versuchen hatte ich Probleme mit der
UNIT Graph (nicht vorhanden). Ist das ohne grosse
Kunstgriffe lösbar?


- Ist der Zugriff auf Gameport, Soundkarte, serielle
Schnittstelle (USB???) machbar - vergleichsweise
so einfach wie früher bei DOS, W95??


Gruß

Arnold

Hi,

auch wenn es keine Antwort auf deine eigentliche Frage ist, ich würde
dir für plattformunabhängige grafische Anwendungen zu Lazarus raten. Und
vergiss Graph, das funktioniert zwar, aber bestimmt nicht so wie du es
dir vorstellst.

Gameport wird seit Windows Vista nicht mehr unterstützt*, den kannst du
dann gleich vergessen. Und such dir vielleicht ne ordentliche
plattformunabhängige Sound-Library.

Unter Linux wäre es sicherlich ähnlich einfach wie unter DOS, auf
serielle Schnittstellen zuzugreifen (einfach Datei /dev/gerät öffnen,
z. B. /dev/ttyS<nummer>). Windows hat aber auch sowas ähnliches über
\\.\gerät geht es irgendwie aber ich weiß nicht ob bei allen oder nur
Laufwerken.

Und unter Ubuntu wird zwar die GPM-Warnung angezeigt, aber ich konnte
kein ungewöhnliches Mausverhalten feststellen. Es funktioniert wunderbar.

Gruß
FAlter

--
Felix Alter Die folgenden Zeilen sind ein Smiley für n3rd5:
001FF800 01F00F80 070000E0 1C181838 3118181C 60181806 60181806
670000E6 61FFFF16 7061160E 3833CC1C 1C1E7831 070000E0 01F00F80
001FF800 =B FAlter Kontakt: http://faltersoft.de/contact.php

Hallo Arnold,

Du schriebst am Sun, 04 Oct 2009 22:08:42 +0200:

> Hallo an die Runde,
> nach längerer Abstinenz (15 Jahre) möcht ich alte
> Anwendungen (damals mit Turbo Pascal)aufgreifen:
>
> - Messwerteingänge über Gameport, Soundkarte und
> A-D-Wandler (über den seriellen Port).

Letzteres wird zunehmend schwieriger, die ersten beiden eher kaum möglich.

> - Nutzung der Grafik

_Welcher_ Grafik? Etwa das alte BGI? Is nich mehr.

> Unter Windows ist heute kein Zugriff auf die Ports
> mehr möglich (mit Turbo Pascal).

Auch nicht mit anderen Programmiersystemen, auch nicht mit Delphi, auch
nicht mit Free-Pascal (ok, mit Tricks, und als Administrator, schon
"irgendwie"). BTW, unter Linux auch nicht.

> Ich muss mich nun entscheiden ob z.B.
>
> Delphi der "richtige" Weg ist oder

Für "Windows only": Ja.

> ob Free Pascal unter Linux auch geht.

Ja.

> Kann mir jemand Tipps geben bzw. eine
> Einschätzung zu folgenden Fragen geben?

> - Ist der gpm-Bug bei Free Pascal auf Debian nur

Noch nie was von gehört (benutze aber auch kein Debian).

> - Bei ersten Versuchen hatte ich Probleme mit der
> UNIT Graph (nicht vorhanden). Ist das ohne grosse
> Kunstgriffe lösbar?

Kaum, die müßtest Du Dir vollständig selber schreiben. (Sowas hab' ich vor
langer Zeit mal weitgehend für OS/2 gemacht.)
Inzwischen gibt's eine Reihe anderer Möglichkeiten, hängt halt vom System
ab.
Falls Windows/Delphi: kann sowas sowieso.
Falls Linux/FPC: X11, GTK, Qt, wxWindows u.v.a.

> - Ist der Zugriff auf Gameport, Soundkarte, serielle
> Schnittstelle (USB???) machbar - vergleichsweise
> so einfach wie früher bei DOS, W95??

Wer braucht einen "Gameport"? Was'n das überhaupt?
Soundkarte - gibt's diverse Möglichkeiten, unter Windows und Linux kaum
unterschiedlicher denkbar.
Serielle Schnittstelle - obwohl leider am Aussterben, kein Problem, solange
man nicht direkt an der Hardware 'rumpfriemeln möchte.
USB - eigentlich nie direkt zu nutzen, und wenn doch, dann immer über
firmenspezifische Schnittstellen (DLL, Treiber o.ä.).

So einfach wie früher bei DOS, W95?
Teils einfacher, teils weniger - unter Dos war eigentlich _gar nichts_
richtig unterstützt, fast alles Handarbeit, bei W95 gab's bisserl was.
Inzwischen gilt im wesentlichen: was das System zur Verfügung stellt, geht
relativ einfach; was das System zur _nicht_ Verfügung stellt, geht, falls
überhaupt, nur unter impraktikablem Aufwand trotzdem.

(Und noch was: Unter Windows gibt es mehr Unterstützung für exotische und
brandneue Hardware; unter Linux ist das, was es gibt, einfacher und vor
allem konsistenter zu handhaben ["alles ist eine Datei"].)

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

Hello,

auf der Windows Seite gibt's für Delphi diverse RS232 Bibliotheken, auch
event basierte. Viele davon sind frei.

Gruß

Markus

Am 04.10.2009, 16:08 Uhr, schrieb Arnold Bender <arnold.bender*arcor.de>:

> Hallo an die Runde,
> nach längerer Abstinenz (15 Jahre) möcht ich alte
> Anwendungen (damals mit Turbo Pascal)aufgreifen:
>
> - Messwerteingänge über Gameport, Soundkarte und
> A-D-Wandler (über den seriellen Port).

Da wirst Du erhebliche Schwierigkeiten haben, weil diese Eingänge (ebenso
wie der bidirektionale Druckerport) heute bei kaum noch einem Computer
vorhanden sind ("legacy free" nennt sich das dann). Damit sind viele
einfache Schaltungen für die Meßwert-Erfassung leider obsolet.

Die Soundkarte kannst Du für NF verwenden (da gibt es Beispielprogramme
für Oszilloskope, Spektrumanalysatoren und dgl, zT auch in Pascal), aber
nicht für DC oder HF (Frequenzgang!).

Adapter, die RS232 oder Centronics nach USB wandeln, gibt es zwar, aber
das sind nur Krücken, die ich für neue Projekte nicht empfehlen würde.

Relativ zukunftssicher (also für die nächsten 2-3 Jahre) ist wohl nur die
USB-Schnittstelle. Da gibt es Entwicklungskits, die dann auch
Treiber-Bibliotheken enthalten. Diese Treiberfunktionen kannst Du dann mit
Deinem Programm aufrufen. Allerdings dürfte das idR nur unter Win
funktionieren, die wenigsten solcher Kits werden auch Linux-Bibliotheken
mitbringen. Hardwaremäßig strickst Du dann Deine Meß-Hardware um dieses
Kit, welches die Kommunikation mit dem Computer übernimmt.

Für sehr schnelle Signale gäbe es dann noch Entwicklungsboards, die etwa
in die PCI-Schnittstellen gesteckt werden, das wird dann aber sehr teuer.

Arnold Bender (arnold.bender*arcor.de) schrieb:
> Hallo an die Runde,
> nach längerer Abstinenz (15 Jahre) möcht ich alte
> Anwendungen (damals mit Turbo Pascal)aufgreifen:
>
> - Messwerteingänge über Gameport, Soundkarte und
> A-D-Wandler (über den seriellen Port).
>
> - Nutzung der Grafik
>

Ja, _sehr_ lange Abstinenz. Heutzutage kannst du...

> Unter Windows ist heute kein Zugriff auf die Ports
> mehr möglich (mit Turbo Pascal).
>

....Direktzugriff auf Ports vergessen. Und DOS-Grafik ist wohl nicht mehr
so das Wahre.

> Ich muss mich nun entscheiden ob z.B.
>
> Delphi der "richtige" Weg ist oder
> ob Free Pascal unter Linux auch geht.
>
> Kann mir jemand Tipps geben bzw. eine
> Einschätzung zu folgenden Fragen geben?
>
> - Ist der gpm-Bug bei Free Pascal auf Debian nur
> ein Schönheitsfehler der Enwicklungsumgebung
> oder gibt es auch weitere Auswirkungen?
>

Das ist insofern ein Schönheitsfehler, als er Windows-Nutzer und
X11-Nutzer nicht interessiert.

> - Bei ersten Versuchen hatte ich Probleme mit der
> UNIT Graph (nicht vorhanden). Ist das ohne grosse
> Kunstgriffe lösbar?
>

Nicht wirklich.

Die Unit Graph ist ja für DOS-Grafik zuständig. Wer will sowas
heutzutage haben? Ich empfehle, auch wenn es viel Arbeit ist, auf die
SDL oder OpenGL umzusteigen. Die sind beide portabel, sowohl auf andere
Hardware als auch auf andere Betriebssysteme.
>
> - Ist der Zugriff auf Gameport, Soundkarte, serielle
> Schnittstelle (USB???) machbar - vergleichsweise
> so einfach wie früher bei DOS, W95??
>

Mit DOS soll das einfach gewesen sein? Ich weiß ja nicht... da durfte
man ja die Eingaben alle selber parsen. Und wehe der Joystick kam mal
von nem anderen Hersteller...

Machbar ist das alles. Sogar in manchen Dingen einfacher als früher.
Beispielsweise gab es früher kein USB. Heutzutage kann an USB ein
Gamepad/Joystick (für die Software ist das egal), Audio-Hardware,
Seriell- oder Parallelwandler und Kaffeewärmer dranhängen.
Berücksichtige mal alle diese Fälle alleine!

Ton kann man auch mit der SDL oder OpenAL ausgeben. Der Ton selbst muss
dabei im PCM-Format vorliegen (meistens).

Input insgesamt macht dir die SDL ebenfalls. OpenGL hat hier nur wenig
anzubieten (GLUT kann eine KeyboardFunc registrieren, aber hat keinen
Joystick-Support).

Was die seriellen Schnittstellen angeht: Kommt drauf an, was du an deren
Ende erwartet hast. Für Mäuse gibt es ebenfalls Unterstützung durch SDL
und GLUT. Für Spezialgeräte gibt es leider nichts Platformunabhängiges.
Aber heutzutage gibt es ja Gerätedateien. Bei Linux heißt sie
"/dev/ttyS0", bei Windows "\\.\COM1". Ich weiß leider nicht, ob das
FP-API mit assign und rewrite nutzbar ist, oder ob die OS-spezifischen
Funktionen hermüssen.

Eine Liste aller seriellen Schnittstellen bei Linux ist mit

uses sysutils;
var sr: tsearchrec;
begin
if findfilefirst('/dev', 0, sr) <> 0
then
halt(1);

repeat
if leftstr(sr.name, 4) = 'ttyS'
or leftstr(sr.name, 6) = 'ttyUSB'
then begin
{mach was mit sr.name}
end
until findnext(sr) <> 0;
end;

erhältlich. Bei Windows musst du ins MSDN gucken.

>
> Gruß
>
> Arnold

HTH,
Markus
--
Nur weil ein Genie nix reißt, muß ja nun nicht gleich jeder Idiot
pausieren... Bully hats ja auch geschafft.
-- gUnter nanonüm in de.alt.anime

Sieghard Schicktanz schrieb:

Hi,

> "Gameport" kenn' ich nicht, nie wasdamit gemacht, aber soll halt
> Bit-Pfriemelei sein, die unter "fortgeschritteneren" Betriebssystemen zm
> einen nur mit root-Rechten zugelassen ist und zum anderen vom Multitasking
> mehr oder weniger behindert.

Bit-Pfriemelei geht auch mit Userrechten (Als Userland Programm). Der
Punkt ist wohl eher, wie die Bits und Bytes zum User gelangen.


> _Messen_ mit eine Soundkarte würde ich mal als Illusion ansehen, allenfalls
> Pegel schätzen oder so .

Das kommt darauf an was man machen will. Zur Drehzahlüberwachung des
Deckenventilators als Gimmik benötigt man nicht unbedigt ein Equipment
im Kilo-Euro Bereich. Genauso wenig auch für die allermeisten privaten
Basteleien. Und ich glaube nicht das es hier um eine Profianwendung geht.

>> Es gibt diverse Unit die alle Grafikbefehle von TP zur Verfügung stellen.
> Sicher, ist nur alles kein BGI.

Ob sich das nun BGI schimpft, oder einen anderen Namen trägt spielt im
Endeffekt keine Rolle. Wichtiger ist, das diese Black-Box mit den
gleichen Befehlen das selbe Ergebnis liefert.


>>> Wer braucht einen "Gameport"? Was'n das überhaupt?
>> Die analoge Universalschnittstelle des PC.
> Spielkram, untauglich auch für nur ansatzweise nützliche Sachen.

Werden heutzutage die "nützlichen Sachen" überhaupt noch in irgend einem
Pascal-Dialekt programmiert?


>> Was ist impraktikabler Aufwand? Das ist wohl eher Relativ.
> Impraktikabler Aufwand ist dann gegeben, wenn jede andere Lösung einfacher,
> schneller oder billiger ist als eine direkte Softwarelösung per PC.
> (Z.B. mit 'nem Mikrocontroller ala PIC oder AVR, anderer Hardware, USB-
> Geräten u.v.m.)

Schneller? Dann darf man für sich selber nichts mehr Programmieren,
sondern greift auf fertige Lösungen zu.
Billiger? Für privat und sich selber darf man den Programmieraufwand
nicht mit einrechnen. Zumal hier ja auch noch ein Lerneffekt gegeben
ist. Gewerblich? Da kann eine Kauflösung wegen Lohnkosten auch billiger
sein.

Bleiben wir doch real. Es kommt immer auf die Gesamtumstände an, und was
damit bezweckt werden soll.

> (Sorry für die späte Antwort, war letzte Woche "unter". :-| )
Dito.

Gruß
Martin

Hallo Martin,

Du schriebst am Thu, 22 Oct 2009 17:52:49 +0200:

> > "Gameport" kenn' ich nicht, nie wasdamit gemacht, aber soll halt
> > Bit-Pfriemelei sein, die unter "fortgeschritteneren" Betriebssystemen zm
....
> Bit-Pfriemelei geht auch mit Userrechten (Als Userland Programm). Der
> Punkt ist wohl eher, wie die Bits und Bytes zum User gelangen.

Bit-Pfriemelei kannste auch als Selbstzweck treiben. Hier war aber der
Zugriff auf Ein-/Ausgangs-Ports im Gespräch, und dafür brauchste (unter
Linux zumindest) halt root-Rechte. Oder zumindest ausreichende Fähigkeiten
(aka "capabilities").

> > _Messen_ mit eine Soundkarte würde ich mal als Illusion ansehen,
....
> Das kommt darauf an was man machen will. Zur Drehzahlüberwachung des
> Deckenventilators als Gimmik benötigt man nicht unbedigt ein Equipment

Beim CPU-Miefquirl geht das oft mit Bordmitteln, beim Deckenventilator
brauchste auch mit der Soundkarte (da geht's ja eh bloß um die Frequenz)
schon eine anständige Bastelei, damit de überhaupt was in Deine Kiste
kriegst.

> Ob sich das nun BGI schimpft, oder einen anderen Namen trägt spielt im
> Endeffekt keine Rolle. Wichtiger ist, das diese Black-Box mit den
> gleichen Befehlen das selbe Ergebnis liefert.

Das tut sie mit Sicherheit nicht. Eine andere "Black Box" hat normalerweise
eine andere Schnittstelle, wenn sie unabhängig entwickelt wurde und nicht
einen Clone darstellen soll. Die "Befehle" (Prozeduraufrufe) werden sich
ähneln, aber nicht identisch zu verwenden sein oder funktionieren.

> Werden heutzutage die "nützlichen Sachen" überhaupt noch in irgend einem
> Pascal-Dialekt programmiert?

Wennde keine sterilien Operationsbestecke im Krankenhaus brauchst, von mir
aus nicht viel. Ansonsten arbeite ich mehr mit Mikrocontrollern und SPS.

> >> Was ist impraktikabler Aufwand? Das ist wohl eher Relativ.
> > Impraktikabler Aufwand ist dann gegeben, wenn jede andere Lösung
> > einfacher, schneller oder billiger ist als eine direkte Softwarelösung
....
> Schneller? Dann darf man für sich selber nichts mehr Programmieren,
> sondern greift auf fertige Lösungen zu.

Wenn man dafür erst programmieren lernen müßte, sicher. Machen ja viele.
Ansonsten ist selber schreiben meistens doch einfacher - man muß nicht erst
was brauchbares suchen, installieren, konfigurieren, die Probleme finden,
sich damit arrangieren...

> Billiger? Für privat und sich selber darf man den Programmieraufwand
> nicht mit einrechnen. Zumal hier ja auch noch ein Lerneffekt gegeben

Das kommt noch dazu.

> ist. Gewerblich? Da kann eine Kauflösung wegen Lohnkosten auch billiger
> sein.

Aber auch teurer, oder wegen Lizenzkosten oder Nutzungsbeschränkungen...

> Bleiben wir doch real. Es kommt immer auf die Gesamtumstände an, und was
> damit bezweckt werden soll.

Da kann und will ich Dir nicht widersprechen. ;->

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

Sieghard Schicktanz (Sieghard.Schicktanz*SchS.de) schrieb:
> Hallo Martin,
>
> Du schriebst am Thu, 22 Oct 2009 17:52:49 +0200:
>
>> > "Gameport" kenn' ich nicht, nie wasdamit gemacht, aber soll halt
>> > Bit-Pfriemelei sein, die unter "fortgeschritteneren" Betriebssystemen zm
> ...
>> Bit-Pfriemelei geht auch mit Userrechten (Als Userland Programm). Der
>> Punkt ist wohl eher, wie die Bits und Bytes zum User gelangen.
>
> Bit-Pfriemelei kannste auch als Selbstzweck treiben. Hier war aber der
> Zugriff auf Ein-/Ausgangs-Ports im Gespräch, und dafür brauchste (unter
> Linux zumindest) halt root-Rechte. Oder zumindest ausreichende Fähigkeiten
> (aka "capabilities").
>

Also, bei mir (kein Gameport da, daher nehm ich was anderes) gehört die
serielle Schnittstelle der Gruppe "dialout" und hat 6 als Gruppenrecht.
D.h. man darf als Mitglied dieser Gruppe auch ohne root-Rechte durchaus
diese Datei lesen und schreiben. Und mit termios kann man einiges für
diese Schnittstelle einstellen. Daher ist direkter Hardware-Portzugriff
(inb, outb, etc.) eigentlich eher unnötig.

>> > _Messen_ mit eine Soundkarte würde ich mal als Illusion ansehen,
> ...
>> Das kommt darauf an was man machen will. Zur Drehzahlüberwachung des
>> Deckenventilators als Gimmik benötigt man nicht unbedigt ein Equipment
>
> Beim CPU-Miefquirl geht das oft mit Bordmitteln, beim Deckenventilator
> brauchste auch mit der Soundkarte (da geht's ja eh bloß um die Frequenz)
> schon eine anständige Bastelei, damit de überhaupt was in Deine Kiste
> kriegst.
>

Wo liegt das Problem? Es gibt zwei Möglichkeiten:

1. Ventilator liefert Drehzahl selbst. Dann ist es doch egal, durch
welchen Port die in den Rechner kommt, oder?

2. Ventilator liefert eine 1 bei jeder vollen Umdrehung. Da muss die
Anwendung also Pegel zählen und evtl. interpolieren (oder willst du eine
Minute warten, bis du weißt, wie schnell sich das Ding dreht?). Das
Ergebnis ist korrekt, wenn der Pegel ohne Verzögerung beim Programm
ankommt. Es ist aber selbst dann noch korrekt, wenn die Verzögerung bei
jedem einzelnen Pegel gleich ist. Wo soll jetzt die Soundkarte etwas
schlechter machen, als bspw. der serielle Anschluss?

Aber den Gameport brauchte man eigentlich nur in der Vor-USB-Zeit um
Joysticks oder Gamepads zu betreiben. Heute kann man das alles mit USB
und generalisierten Input-Libs wie SDL-Input machen.

Tschö,
Markus
--
Nur weil ein Genie nix reißt, muß ja nun nicht gleich jeder Idiot
pausieren... Bully hats ja auch geschafft.
-- gUnter nanonüm in de.alt.anime

Hallo Markus,

Du schriebst am Sat, 24 Oct 2009 16:46:13 +0200:

> > Zugriff auf Ein-/Ausgangs-Ports im Gespräch, und dafür brauchste (unter
> > Linux zumindest) halt root-Rechte. Oder zumindest ausreichende
> > Fähigkeiten (aka "capabilities").
>
> Also, bei mir (kein Gameport da, daher nehm ich was anderes) gehört die
> serielle Schnittstelle der Gruppe "dialout" und hat 6 als Gruppenrecht.

Serielle hat hier (Arch) Gruppe "tty", auch "rw".
Nur ist die "Serielle" für Bit-Pfriemelei sowas von ungeeignet (weil's
wesentlich besser Methoden gibt), daß ich hier daran gar nicht gedacht habe
- eher an die Parallele (die gehört hier "lp", weil da normalerweise
'n Drucker dranhängt oder sowas.
Es hängt also durchaus von "ein paar" Randumständen ab, und _ändern_ kann
die zuverlässig nur root. Das gilt sogar für die "Capabilities".

> >> Das kommt darauf an was man machen will. Zur Drehzahlüberwachung des
> >> Deckenventilators als Gimmik benötigt man nicht unbedigt ein Equipment
....
> Wo liegt das Problem? Es gibt zwei Möglichkeiten:
>
> 1. Ventilator liefert Drehzahl selbst. Dann ist es doch egal, durch
> welchen Port die in den Rechner kommt, oder?

Nicht ganz, Zugriff muß möglich sein und er muß die Signale verarbeiten
können - und woher bekommst Du von einem (230V-) Deckenventilator PC-Port-
geeignete Signale? Na siehste, da brauchste erstmal bissel Bastelei
drumrum, bevorde überhaupt dran denken kannst, die irgendwo anzuklemmen.

> 2. Ventilator liefert eine 1 bei jeder vollen Umdrehung. Da muss die

Wie liefert der die "1"? Siehe oben - Du mußtr schon sicherstellen, daß die
für den Eingangs-Port verträglich sind. _Erst_ _dann_ kannst Du Dir
sinnvoll Gedanken drüber machen, wie Du die auswertest...

> jedem einzelnen Pegel gleich ist. Wo soll jetzt die Soundkarte etwas
> schlechter machen, als bspw. der serielle Anschluss?

Die Soundkarte kann sowas (niederfrequente Signale in digitalisierte
Abtastwerte umsetzen, aus denen sich dann die Frequenz bestimmen läßt)
wesentlich besser als der serielle Port - der erwartet im wesentlichen ein
Signal mit einer _festen_, nur in wenigen Schritten veränderbaren
Grundfrequenz und kann jedenfalls keine Impulse zählen, ohne vollkommen
seines Zweckes beraubt zu werden.

> Aber den Gameport brauchte man eigentlich nur in der Vor-USB-Zeit um
> Joysticks oder Gamepads zu betreiben. Heute kann man das alles mit USB
> und generalisierten Input-Libs wie SDL-Input machen.

Na, dann viel Spaß dabei, "mal schnell" 'nen Deckenventilator über USB
anzuschließen... ;->
Klemmste dafür die +5V oder die Masse an D+, oder nimmste dafür eher D- her?
=;->

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------