WinUSB *.inf unter x64

Hallo,

ich habe eine USB-Hardware die ich über den
Device -Manager unter 32Bit mit folgendender *.inf Datei
mit WinUSB normal verwenden kann.

Frage:
warum klappt das unter 64 Bit nicht, den Standard WinUSB -Treiber anzumelden ?

Fehlermeldung:
**The thrid-party INF does not contain digital signature Information.
**

Inhalt der *inf Datei die unter 32Bit funktiniert.

[Strings]
DeviceName = "Honywall"
VendorName = "IMan"
DeviceID   = "VID_23C6&PID_13A0"
DeviceGUID = {EEBE3F79-3A2A-4304-9791-EBF0E998E900}"

[Version]
Signature   = "$Windows NT$
ClassGuid   = {88bae032-5a81-49f0-bc3d-a4ff138216d6} 
Provider    = "Honywall"
DriverVer   = 30/11/2015, 8.0.0.0

[ClassInstall32]
Addreg = WinUSBDeviceClassReg

[Manufacturer]
%VendorName% = Honywall_WinUSB,NTx86,NTamd64,NTia64

[FlexxVision_WinUSB.NTx86]
%DeviceName% = USB_Install, USB\%DeviceID%

[FlexxVision_WinUSB.NTamd64]
%DeviceName% = USB_Install, USB\%DeviceID%

[FlexxVision_WinUSB.NTia64]
%DeviceName% = USB_Install, USB\%DeviceID%

[USB_Install]
Include = winusb.inf
Needs   = WINUSB.NT

[USB_Install.Services]
Include    = winusb.inf
AddService = WinUSB,0x00000002,WinUSB_ServiceInstall

[WinUSB_ServiceInstall]
DisplayName   = "WinUSB - Kernel Driver 0/11/2015 8.0.0.0"
ServiceType   = 1
StartType     = 3
ErrorControl  = 1
ServiceBinary = %12%\WinUSB.sys

[USB_Install.Wdf]
KmdfService = WINUSB, WinUsb_Install

[USB_Install.HW]
AddReg = AddDeviceInterfaceGUID

[AddDeviceInterfaceGUID]
HKR,,DeviceInterfaceGUIDs,0x10000,%DeviceGUID%
HKR,,FriendlyName,,"IMan"

https://www.google.de/search?q=The+third-party+INF+does+not+contain+digital+signature+Information

Hallo,

der Psycho-Terror Schalter mit dem halb-Affen griff shift+restart war
mir neu.

Aber es handelt sich um WinUSB dieser Treiber ist ja von Microsoft.

Dennoch habe ich das auch mal durchgeführt, aber ohne Erfolg.

Ich muss dazu sagen, das ich die Inf + den USB-Baustein selber
herstelle, dennoch funktioniert das seit langem unter verschiedenen 32Bit Systemen, irgendwas fehlt in der *.inf Datei für 64 Bit..

Danke für deine Schnell Hilfe
Gruß
K.

Achromat schrieb:

Aber es handelt sich um WinUSB dieser Treiber ist ja von Microsoft.

Und die INF ist von Dir. Erstellst Du Katalog (Inf2Cat.exe), signierst du (signtool.exe), fertig.

Danke für deine Rückmeldung, aber das läuft ja mit WinUSB, ich verfüge über keine gekaufte Signatur, es ist auch kein HobbyProjekt wo man das mal ebend machen könnte. Warum sollte es denn unter 32Bit funktionieren aber nicht unter 64 Bit ?

WinUSB ist ja ein Windows -Standardtreiber.

Danke für deine Hilfestellung.
Gruß
K.

Achromat schrieb:

WinUSB ist ja ein Windows -Standardtreiber.

Die INF Datei ist aber von Dir. Und die INF Datei muss signiert sein, bzw. deren Katalog. Das ist halt so. Wenn Dir das nicht passt, nimmst Du eben die mitgelieferte INF. Allerdings musst Du Deine Firmware dahingehend ändern, als das Du OS Descriptoren ausgeben musst, siehe "How to install WinUSB.sys without a custom INF?".

Alternativ kannst Du auf CDC umschwenken. Bis einschließlich Windows 7 geht das dann mit einer custom INF, Windows 8 und 8.1 geht ohne Signatur nicht, und ab 10 brummt das out-of-the-box ganz ohne Aktivität deinerseits.

Es läuft unter w10 xp w7 w8 aber nicht unter 64 Bit.
Warum nicht bei 64 Bit ? Treiber bleibt im Manager64bit Gelb.
Mitgelieferte Inf ? Da muss ja mein Class ID rein. Eine mitgelieferte *.inf
welche soll das sein das DDK ist voll davon.

über eine Million treffer bei USB WIN ^^ unglaubliches Chaos.
Ich denke an solchen Krücken wird das W eingehen.
Unter Linux geht's mit fopen fwrite fread, seit 1972 weiß jeder Informatiker
Geräte werden wie Dateien behandelt. Es gibt keine Sicherheit.

Achromat schrieb:

Warum nicht bei 64 Bit ?

Deswegen:

Achromat schrieb:

Fehlermeldung:
The thrid-party INF does not contain digital signature Information.

Schau Dir dazu auch das hier an: WinUSB (Winusb.sys) Installation.

MSDN schrieb:

A signed catalog file for the package. This file is required to install WinUSB on x64 versions of...

Achromat schrieb:

über eine Million treffer bei USB WIN ^^ unglaubliches Chaos.

Chaos ist es nur, weil Du Dich etwas schwierig anstellst. OS Descriptor und fertig ist die Laube. Das weißt Du doch jetzt.

Danke erstmal.

Ja ich sende Deskriptoren über den AVR Baustein an Windows.
Den Os Deskriptor kenne ich noch nicht. Ich kann mein Gerät auch als Standard Input Device erscheinen lassen gänzlich ohne *inf leider ist es dann weder
über WinUSB noch über Hid_ Funktionen ansprechbar, öffnen geht via OpenFile immer gut.

Naja das Problem ist die begrenzte Lebenszeit, das Projekt hat nun schon 1 Jahr verbraucht und es scheint sich nun das zweite anzuschließen.

Dann werde ich mal nach dem OS Deskriptor forschen.

Unklar bleibt warum die *inf nun nicht unter x64 wirkt..

Danke der Hinweise
Lg.
K.

Achromat schrieb:

Input Device erscheinen lassen gänzlich ohne *inf leider ist es dann weder
über WinUSB noch über Hid_ Funktionen ansprechbar, öffnen geht via OpenFile immer gut.

Ein HID ist über WinUSB nicht ansprechbar, na klar. Die HidD_ Funktionen gehen aber sehr wohl. Allerdings musst Du dazu in Deiner Firmware Unterstützung für den GET_REPORT- und SET_REPORT-Request einbauen, da die besagten Funktionen auf den EP0 wirken. Erst wenn Du ReadFile/WriteFile verwendest, läuft das über die in den Deskriptoren ausgewiesenen Interrupt-Endpunkte.

Außerdem musst Du auf Seiten des Windows-Hosts die Puffer entsprechend vorbereiten, auch die Lese-Puffer! Ich fürchte fast, dass Du das auch nicht gemacht hast.

Das eigentliche Problem scheint fehlende USB Erfahrung zu sein. Ist das möglich?

Hallo Mox,

naja die dynamische Deskriptoren liste im Baustein ist eine aus vielen AVR Examples like V-Usb abgekupfert, dort stehen ja bereits Endpunkte, bezeichnet mit idx 83 und 81 drin.

Das ich für Write und Read zwei Open's brauche habe ich auch schon gesehen, obschon mit "RW-Flag" geöffnet wird. Da nun unklar war wie Write/Read auf den Endpunkt wirken solle, habe ich HID_SetFuture HID_GetFuture verwendet.

Auf dem Baustein hätte die LED geblinkt wenn auch nur einer der beiden Operationen den Interrupt der als WinUsb auch so vorkommt, ausgelöst worden wäre.

Den Speicher für read/write Operationen wurde im Baustein als auch im win mit 8 Bytes angegeben.

Genau ich sollte mich darauf konzentrieren das das InputDevice von alleine sich in den HardwareManager einklingt (DescLen=22 sonnst 0 für WinUsb) und den Deskriptor noch mal genau studieren, was mir sehr schwer fällt, ich habe den Descriptor aus dem Flash in den 512 Byte großen Arbeitsspeicher übertragen denn ich kann zur Laufzeit zb Pid und Vid dynamisch verändern was auch gut funktioniert.

Ja wenig Ahnung von USB, ich habe die Dokumentationen gesichtet, aber mangels Lebenenszeit nicht gänzlich erfasst.

Mal gurz gebettelt, hast Du vielleicht einen Descriptor der da passen würde ?

Ich verwende folgende Konfiguration:

#define USBDESCR_CONFIG         2
#define USB_CFG_HAVE_INTRIN_ENDPOINT    1
#define USB_CFG_HAVE_INTRIN_ENDPOINT3   0
#define USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH 22 //22 HIDgerät oder 0 WinUsb!
#define USB_CFG_MAX_BUS_POWER           1//oder 100 [mA]
#define USBDESCR_INTERFACE      4
#define USB_CFG_DEVICE_CLASS        0xff  /*ks default was 0 set to 0 if deferred to interface */
#define USB_CFG_DEVICE_SUBCLASS     0
#define USB_CFG_INTERFACE_CLASS     0x3 /* HID */ /* define class here if not at device level  default 0x03 HID*/
#define USB_CFG_INTERFACE_SUBCLASS  0x0 //keyboard=1 Hid input/joy = 0
#define USB_CFG_INTERFACE_PROTOCOL  0x0 //keyboard=1 Hid input/joy = 0
#define USBDESCR_HID            0x21
#define USBDESCR_ENDPOINT       5
#define USB_CFG_INTR_POLL_INTERVAL      10//much mor 20 = 1Khz 5 = 2Khz

char usbDescriptorConfiguration[] =     /* USB configuration descriptor */
  {
    9,          /* sizeof(usbDescriptorConfiguration): length of descriptor in bytes */
    USBDESCR_CONFIG,    /* descriptor type */
    18 + 7 * USB_CFG_HAVE_INTRIN_ENDPOINT + 7 * USB_CFG_HAVE_INTRIN_ENDPOINT3  +USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH,  /* total length of data returned (including inlined descriptors) */
	0,
    1,          /* number of interfaces in this configuration */
    1,          /* index of this configuration */
    0,          /* configuration name string index */
    (1 << 7),                           /* attributes selfpower no*/
    USB_CFG_MAX_BUS_POWER/2,            /* max USB current in 2mA units */
    9,          /* sizeof(usbDescrInterface): length of descriptor in bytes */
    USBDESCR_INTERFACE, /* descriptor type */
    0,          /* index of this interface */
    0,          /* alternate setting for this interface */
    USB_CFG_HAVE_INTRIN_ENDPOINT + USB_CFG_HAVE_INTRIN_ENDPOINT3, /* endpoints excl 0: number of endpoint descriptors to follow */
    USB_CFG_INTERFACE_CLASS,
    USB_CFG_INTERFACE_SUBCLASS,
    USB_CFG_INTERFACE_PROTOCOL,
    0,          /* string index for interface */

#if (USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH)    /* HID descriptor */
    9,          /* sizeof(usbDescrHID): length of descriptor in bytes */
    USBDESCR_HID,   /* descriptor type: HID */
    0x01, /* BCD representation of HID version */
	0x01, /* BCD representation of HID version */
    0x00,       /* target country code */
    0x01,       /* number of HID Report (or other HID class) Descriptor infos to follow */
    0x22,       /* descriptor type: report */
    USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH,  /* total length of report descriptor */
	0, 
#endif

    7,          /* sizeof(usbDescrEndpoint) */
    USBDESCR_ENDPOINT,  /* descriptor type = endpoint */
    (char)0x81, /* IN endpoint number 1 */
    0x03,       /* attrib: Interrupt endpoint */
    8,          /* maximum packet size */
	0,      
    USB_CFG_INTR_POLL_INTERVAL, /* in ms */

    7,  /* sizeof(usbDescrEndpoint) */
    USBDESCR_ENDPOINT,  /* descriptor type = endpoint */
    (char)0x83, /* IN endpoint number 1 */
    0x03,       /* attrib: Interrupt endpoint */
    8,          /* maximum packet size */
	0,          /* maximum packet size */
    USB_CFG_INTR_POLL_INTERVAL, /* in ms */
};

Mann mann...

Achromat schrieb:

Hallo Mox,

naja die dynamische Deskriptoren liste im Baustein ist eine aus vielen AVR Examples like V-Usb abgekupfert, dort stehen ja bereits Endpunkte, bezeichnet mit idx 83 und 81 drin.

Das ist schon mal ein Problem. Das sind nämlich beides IN Endpunkte, schreiben kannst Du damit schon mal nichts. Sollte das nicht eher 81 und 1, beziehungsweise 3 und 81 sein?

Hast Du keinen OUT-EP, sollten die geschriebenen Reports wieder auf EP0 landen. Damit bist Du wieder in der Pflicht, SET_REPORT Requests zu verarbeiten (Firmware prüfen und ggf anpassen).

Achromat schrieb:

Das ich für Write und Read zwei Open's brauche habe ich auch schon gesehen, obschon mit "RW-Flag" geöffnet wird. Da nun unklar war wie Write/Read auf den Endpunkt wirken solle, habe ich HID_SetFuture HID_GetFuture verwendet.

Feature, nicht Future!
Für HID brauchst Du keine zwei Opens, für WinUSB auch nicht.

Achromat schrieb:

Auf dem Baustein hätte die LED geblinkt wenn auch nur einer der beiden Operationen den Interrupt der als WinUsb auch so vorkommt, ausgelöst worden wäre.

Den Speicher für read/write Operationen wurde im Baustein als auch im win mit 8 Bytes angegeben.

Siehste, schon falsch. Auf Seiten des Windows-Hosts gibst Du die Anzahl schon mal nicht fest an. Du parst erst einmal die Reports (HidD_GetPreparsedData), um dann im nächsten Schritt die tatsächliche Länge anzufragen (HidP_GetCaps). Und als Write-Buffer allokierst Du nun HIDP_CAPS.OutputReportByteLength Bytes. Und siehe da: Das sind 9 Bytes. Das allererste Byte des Reports ist von Dir selbst mit dem Report-Identifier zu initalisieren, egal ob Du schreibst oder liest! Arbeitest Du nicht mit Report-Identifiern, nimmst Du eben die 0.

Achromat schrieb:

Genau ich sollte mich darauf konzentrieren das das InputDevice von alleine sich in den HardwareManager einklingt (DescLen=22 sonnst 0 für WinUsb) und den Deskriptor noch mal genau studieren, was mir sehr schwer fällt, ich habe den Descriptor aus dem Flash in den 512 Byte großen Arbeitsspeicher übertragen denn ich kann zur Laufzeit zb Pid und Vid dynamisch verändern was auch gut funktioniert.

Die gezeigten Deskriptoren sehen doch einigermaßen aus, auch wenn ich bcdHID auf 1.11 und nicht auf 1.01 gesetzt hätte. Und dann sollte noch ein beschreibbarer Endpunkt ausgerufen werden.

Achromat schrieb:

Ja wenig Ahnung von USB, ich habe die Dokumentationen gesichtet, aber mangels Lebenenszeit nicht gänzlich erfasst.

Mal gurz gebettelt, hast Du vielleicht einen Descriptor der da passen würde ?

Zeig her Deinen Report-Deskriptor, den kriegen wir schon korrigiert.

Ungeprüft:

const uint8_t g_ReportDescriptor[] =
{
    0x06, 0x00, 0xFF,              // USAGE_PAGE (Generic Desktop)
    0x09, 0x01,                    // USAGE (Vendor Usage 1)
    0xA1, 0x01,                    // COLLECTION (Application)

    0x09, 0x02,                    //   USAGE (Vendor Usage 0x02)
    0x15, 0x00,                    //   LOGICAL_MINIMUM (0)
    0x26, 0xFF, 0x00,              //   LOGICAL_MAXIMUM (255)
    0x75, 0x08,                    //   REPORT_SIZE (8)
    0x95, 0x08,                    //   REPORT_COUNT (8)
    0x81, 0x02,                    //   INPUT (Data,Var,Abs)

    0x09, 0x03,                    //   USAGE (Vendor Usage 0x03)
    0x75, 0x08,                    //   REPORT_SIZE (8)
    0x95, 0x08,                    //   REPORT_COUNT (8)
    0x91, 0x02,                    //   OUTPUT (Data,Var,Abs)

    0x09, 0x04,                    //   USAGE (Vendor Usage 0x04)
    0x75, 0x08,                    //   REPORT_SIZE (8)
    0x95, 0x08,                    //   REPORT_COUNT (8)
    0xB1, 0x02,                    //   FEATURE (Data,Var,Abs)

    0xC0                           // END_COLLECTION
};

Übrigens: Feature-Reports werden grundsätzlich über den EP0 transportiert. Du musst dafür zwingend SET_REPORT und GET_REPORT bearbeiten.

Hallo Mox,

schau an Size abfragen für hid, für WinUsb sende ich einen geformten request mit Endpunkte angaben.

Ich habe deinen Vorschlag 1:1 durch meinen Descriptor ersetzt (1)
usbDescriptorConfiguration[] Original umgenannt nach : usbDescriptorConfiguration1[]

mit Avrdude rüber gezogen: (Ich muss das erst Untersuchen aber das ergab der 1:1 Vorgang. http://euve12011.vserver.de/p1.jpg
und andere Version mit meinem BastelmodDescriptor:
http://euve12011.vserver.de/p2.jpg

Erstmal vielen Dank für deine Hinweise!
Grüße Karsten

das define DESCRIPTORLENGHT

wieder auf 22 gesetzt, und ich sehe das Hid Input Gerät,
ich berichte dann später Details.

Thx !

Achromat schrieb:

Hallo Mox,

schau an Size abfragen für hid, für WinUsb sende ich einen geformten request mit Endpunkte angaben.

HIDs haben eben den Schick, als das sie sich selbst beschreiben. Geformate Requests kannst Du aber immer noch schicken.

Achromat schrieb:

Ich habe deinen Vorschlag 1:1 durch meinen Descriptor ersetzt (1)
usbDescriptorConfiguration[] Original umgenannt nach : usbDescriptorConfiguration1[]

Stopp! Mein Vorschlag war ein Report-Descriptor, nicht ein Configuration-Descriptor! Das ist was anderes. Schau Dir mal Deinen HID-Descriptor an:

#if (USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH)    /* HID descriptor */
    9,          /* sizeof(usbDescrHID): length of descriptor in bytes */
    USBDESCR_HID,   /* descriptor type: HID */
    0x01, /* BCD representation of HID version */
    0x01, /* BCD representation of HID version */
    0x00,       /* target country code */
    0x01,       /* number of HID Report (or other HID class) Descriptor infos to follow */
    0x22,       /* descriptor type: report */
    USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH,  /* total length of report descriptor */
    0, 
#endif

Also:
0x01, /* number of HID Report (or other HID class) Descriptor infos to follow */

Damit sagst Du, dass das Gerät einen zusätzlichen durch die Geräteklasse definierten Deskriptor zur Verfügung stellt, nämlich:
0x22, /* descriptor type: report */

Es handelt sich also um einen Report-Descriptor, z.B. mein Vorschlag. Ändere jetzt diese Zeile:
USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH, /* total length of report descriptor /
in:
sizeof(g_ReportDescriptor), / total length of report descriptor */

Du musst jetzt noch sicherstellen, dass der Report auch ausgegeben wird. Das machst Du da, wo der GET_DESCRIPTOR Request bearbeitet wird. Aber das scheint ja bereits zu funktionieren, wenn ich Deinen letzten Beitrag richtig interpretiere.

Ja richtig, ich hatte den Hid Descriptor als Descriptor-Config eingehangen das war natürlich falsch. Im Moment sehe ich zwar das Gerät als HidInput, und kann auch 9 Byte schreiben, ich muss mir erst den Atmel Debugger kaufen mit dem
USB- 1Euro Programmer sehe ich nicht was passiert.

Vielen Dank für deine Hinweise
Gruß
Karsten

Hi,

nachdem ich die Deskriptoren wie beschrieben ergänzt habe, integrierte ich
eine Ein Draht rs232 sende Leitung, und tickerte mir die Anlaufenden Daten
auf einen anderen Microcontroller der diese als 38200B auf 100500b an einem Comport übersetze.

Damit war es möglich das etwas andere "behandeln" unter HID, im Controller
zu ergänzen. Inzwischen erreicht man mit dem Atiny85 2.5[K/s].
Jedes packet hat 8Byte.

Hier die HotWire DebugLeitung am PB1

//Use Atiny85 PB1 as TX DebugTransmitter to emit Strings
#define BD300   3333 //300  Baud   3,33 ms
#define BD1200   833 //1200  Baud  833 µs
#define BD2400   417 //2400  Baud  417 µs
#define BD9600   104 //9600  Baud  104 µs
#define BD19200   52 //19200  Baud  104 µs
#define BD28800   34.6//28800 Baud 34.6 µs
#define BD38400   23.04//38400 Baud 26,04 µs
#define BD115200   7.68
#define ACTBAUD    BD38400
//9600 8 n 1  1Startbit 8Datenbit 1Stopbit (can use two stop bitslots)

void TxStr(unsigned char *p)
{
   TxDat(p,strlen(p));
}
void TxDat(unsigned char *p, int len)
{
	unsigned char n;
	while(len-- > 0)
	{ 
		cli();//DisableInterrupt
		_delay_ms(1);

		//Startbit 	
		PORTB &= ~(1 << PB1);
		_delay_us(ACTBAUD);

		for(n=0; n < 8; n++) //Databits
		 *p&(1<<n)?(PORTB |=  (1 << PB1)):(PORTB &= ~(1 << PB1)),_delay_us(ACTBAUD);//make this slot

		//Stopbit1	
		PORTB |=  (1 << PB1);
		_delay_us(ACTBAUD);

		sei();//EnableInterrupt
		_delay_ms(1);

		p++;
	}
}

Schade das mit HID_SetFuture() oder ::WriteFile kein geformter Header
mit index value und size gesendet werden kann, die requests sind unter
Hid anders definiert, das musste man wissen.

//0x21 (33)comes from Hid_SetFuture
//0xa1 (161)comes from Hid_GetFuture

Schade das ReadFile nicht funktioniert (hängt fest blocklen 8+1=9)
HidGetFuture funktioniert, alles ist wunderbar.

Danke der Hinweise !
Gruß
K.

Achromat schrieb:

Schade das mit HID_SetFuture() oder ::WriteFile kein geformter Header
mit index value und size gesendet werden kann, die requests sind unter
Hid anders definiert, das musste man wissen.

Du kannst durchaus auch verschieden geformte Reports senden. Unterschieden werden sie dann zwar über wValue und nicht per wIndex, aber das ist ja auch nicht so schlimm. Die size brauchst Du nicht mitzusenden, da sie sowieso schon klar ist: Steht schließlich im Report-Deskriptor.

Allerdings musst Du den Report-Deskriptor dafür anpassen. Meinen Vorschlag kannst Du nicht mehr 1:1 übernehmen.

Achromat schrieb:

Schade das ReadFile nicht funktioniert (hängt fest blocklen 8+1=9)
HidGetFuture funktioniert, alles ist wunderbar.

Und wie das funktioniert! Du darfst halt nicht vergessen, das erste Byte des Puffers vor dem Aufruf von ReadFile zu initialisieren. Allerdings schaut es eher danach aus, als das Deine Firmware noch einigermaßen fehlerhaft ist. Das Gegenstück zu ReadFile ist HidD_GetInputReport, nicht HidD_GetFeature. Es scheint, als bedienst Du den In-Endpunkt nicht oder nicht richtig. Hast Du denn wenigstens Deine Endpunkt-Deskriptoren in Ordnung gebracht (ein HID hat nur einen In-Endpunkt)?

Ansonsten schau Dir das im Protokoll-Analyser an.

Hi,

in der Doku steht das lediglich das erste Byte noch beachtet wird. Das trifft nun aber für SetFuture zu. Das es sich um ein Equalent zum HID_Input oder zum HID_SetFurute verhält ist ja doll.. Und genau dann wird auch wieder das geformtes WINUSB Request verwendbar (unter HId_Write statt HID_SetFuture(Vermutung). Natürlich wenn der dritte Endpunkt auch wirklich off sein sollte.

Ich prüf das noch nach, im Moment läuft es Treiberlos sogar etwas schneller.
(Linux dito 32/64 ab xp sp1 )

Danke der Hinweise
Lg.
Karsten