Ich hab schon diverse Perl Versionen versucht, jedoch mit dem immer gleichen Resultat.

Die windowseigenen Stringfunktionen sind eh total
antiquiert bzw. buggy.

Kompilerläufe von DBD-Pg mit VS8 haben hunderte warnings
wg. deprecated strxxx-Funktionen ergeben. Um die
"sicheren" Stringfunktionen von Windows zu nutzen müsste
also der Quellcode von DBD-Pg dementsprechend modifiziert
werden, was eigentlich auch nicht Sinn der Sache sein kann
(der Aufwand dürfte auch nicht unbeträchtlich sein).

Ich bin der Überzeugung, dass XP hier schlichtweg noch
unzureichend ist. Im schlimmsten Fall bedeutet das dann einfach, dass es (zumindest mit den eingesetzten Systemen) nicht ohne größere Aktion funktionieren wird.

Läuft es eigentlich (wird eingesetzt, ist nicht nur installiert) stabil bei jemandem auf einem Rechner mit XP?

VS8 ist leider so inkompatibel zu VS7 und macht nur Probleme beim kompilieren von Code. :angry:

Ich hatte dummerwise auch zum kompilieren von Apache und mod_perl mit VC8 gekauft.
Das verstaubt jetzt in der Ecke.

Ist ja seit VS7 so. Nutzer soll weg von posixkonformen Funktionen, indem eine saubere Kompilierung durch Haufenweise deprecated-Meldungen (in der Standardeinstellung) verhindert wird. Würde mir wünschen, dass unter Windows die Trennung (zumindest bei den Kompilern) zwischen nativen und crl Binaries strikter wäre.

Ob mir das in diesem Fall das Leben leichter machen würde?
Wenn es ein Fehler in kernel32.dll ist, dann wohl eher nicht.

VS8 war aber auch bei mir schnell wieder deinstalliert, da klar war, dass es damit eher nicht funktionieren wird.

[quote=chkabel,25.04.2006, 10:35]Wenn es ein Fehler in kernel32.dll ist, dann wohl eher nicht.[/quote]
der Fehler ist nicht in kernel32.dll, sondern passiert nur da.

beispiel:


:)

[quote=esskar,25.04.2006, 12:54]der Fehler ist nicht in kernel32.dll

beispiel:
[/quote]
Wenn der Fehler in strcmpiW ist und strcmpiW in kernel32.dll,
dann behaupt ich jetzt mal ganz frech, dass der Fehler auch
in kernel32.dll ist. Ich weiss schon, dass die Standardfunktionen in Windows unbedingt gültige Speicherbereiche brauchen, hab aber nicht die Zeit den ganzen Code zu Fuß durchzugehen und diese durch die von MS als sicher eingestuften auszutauschen.

Sollte aber ein vertretbarer Aufwand sein, am Wochenende
ein Regexscript dafür zu schreiben - den Versuch ist es noch Wert.

Das erklärt allerdings immer noch nicht das Problem, dass es weder unter gcc noch VS6 kompiliert.

[quote=chkabel,25.04.2006, 13:16]Ich weiss schon, dass die Standardfunktionen in Windows unbedingt gültige Speicherbereiche brauchen, hab aber nicht die Zeit den ganzen Code zu Fuß durchzugehen und diese durch die von MS als sicher eingestuften auszutauschen.[/quote]
naja; wenn du das weißt, dann machst du als Entwickler einen Fehler und nicht die Funktion.

ich hab bei mir auch mal alles installiert.
selber fehler.
laut debugger passiert es in pg.dll

[quote=esskar,25.04.2006, 15:06]naja; wenn du das weißt, dann machst du als Entwickler einen Fehler und nicht die Funktion.

ich hab bei mir auch mal alles installiert.
selber fehler.
laut debugger passiert es in pg.dll[/quote]
War zu erwarten, wiegesagt: es ist auf x Computern reproduzierbar.

Allerdings versteh ich nicht, wieso ich an der Stelle einen Fehler mache. Würde die strxxx-Funktionen nie selbst verwenden.
Wenn MS meint, sie müssten in eine Kernkomponente ihres OS Funktionen bauen, die Applikationenen wegen simplen NULL-Pointern killen....anderes Thema.

Zu dem Code-Beispiel das du gepostet hast:
Ich habe keine Ahnung, ob im DBD-Pg-Fall der Absturz auch durch ein NULL ausgelöst wir. Es kann ebenso gut sein, dass
durch eine bestimmte Konstellation (z.B. kein \0 ...) ein völlig anderes Fehlverhalten entsteht. Aus der Fehlermeldung geht es ja leider nicht hervor.

Der Fehler tritt auf jeden Fall ziemlich wahrscheinlich schon
entweder beim DBI->connect(....) oder beim initialisieren von DBD-Pg auf.

Scheint als hätten die Entwickler des Moduls noch viel Arbeit vor sich, wenn Windows voll unterstützt werden soll.

Klar, die Wenigsten werden das je brauchen (Postgres&Perl&WinXP&!Cygwin), aber es ist doch
ein mögliches Szenario für eine Produktkonfiguration und wie mir inzwischen klar ist, momentan nicht stabil zu realisieren.

Das beste wird sein abzuwarten, wann funktionierende Packete erscheinen.

Danke für eure bisherigen Antworten\n\n

<!--EDIT|chkabel|1145975183-->

ich hab es hinbekommen.
so hab ich es getan:
* aktuelle DBD::Pg version ( 1.48 ) installiert
* environement variablen gesetzt:
  * SET POSTGRES_INCLUDE=H:\PostgreSQL\8.1\include
  * SET POSTGRES_LIB=H:\PostgreSQL\8.1\lib\ms;%LIB%
  * SET PATH=H:\PostgreSQL\8.1\bin;%PATH%
* makefile.pl
* nmake test
* nmake install

danach bekam ich noch immer den selben fehler.
Das hat mich stutzig gemacht, vorallem weil der connect test (nach dem ich auch DBI_DSN, DBI_PASS, DBI_USER gesetzt hat, ohne Geschrei durchlief).
dann hab ich die alte DBD::Pg von Hand gelöscht:

Verzeichnis: F:\Perl\site\lib\auto\DBD\Pg
Datei: F:\Perl\site\lib\DBD\Pg.pm

dann nochmal nmake install ausgeführt.
ab jetzt läuft es ohne probleme\n\n

<!--EDIT|esskar|1146489969-->

Vielen Dank,

werd es hoffentlich morgen nochmal versuchen.\n\n

<!--EDIT|chkabel|1146489567-->