Windows 7 EXE läuft nicht mehr nach linken

[Rudolf]

Hallo,
habe gerade alles auf einen Windows 7 Rechner übertragen, soweit läuft das Ding. Wenn ich jedoch ein Programm linke das einwandfrei läuft, ist es danach nicht mehr lauffähig. Die Grösse ist jedoch die gleiche. Es dauert ca. 15 Sekunden (schaut aus als ob die EXE gestartet wird), dann schliesst sich das Kommando Fenster wieder. Wenn ich es mit Debugger starte:
ERROR loading HKP.EXE
error creatin debugee process
error code 273
Habe aber Ausführung schon als XP kompatibel und als Administrator umgestellt. Hat jemand schon auf Windows 7 was neu compliert und zum Laufen gebracht ?
Grüsse
Rudolf

[Ewald]

Hallo Rudolf,
habe grade mal testweise meine Quellcodes und XBASE++ auf einen WIN 7 Rechner installiert und dort alles neu gelinkt. Die EXE - Files laufen normal. Der Fehler tritt bei mir nicht auf.
Bin auf dem WIN 7 Recherner als Administrator angemeldet.
Gruß
Ewald

[Ewald]

Kleine Ergänzung dazu, es läuft aber auch nur wenn ich als Administrator angemeldet bin.
Ich habe als Adimistrator die Pfadangaben zu XBASE++ zur Registrierung hinzugefügt. Die stehen jetzt nur zur Verfügung, wenn ich mich als Administrator anmelde. Gehe ich mit einem anderen Namen rein (auch mit Admin Rechten), sind die Pfadangaben nicht da.
Was auch nicht geht:
Ich habe ein Testverzeichnis, in dem die Daten (Tabellen) und die XBASE++DLL's liegen. In einem anderen Pfad liegen die Programme. Mit der DOS Umgebungsvariablen LW stelle ich dann vom Programmpfad die Verbindung zu den Daten her. Also - set LW=D:\pps . Beim Programmstart fange ich die Umgebungsvariable ab und stelle mit set default xy die Verbindung her. Das geht unter WIN 7 auch nicht so richtig. Ich kann dann zwar auf die Daten zugreifen, nicht jedoch auf die DLL's.
Es gibt viel zu tun, fangt schon mal an

[Rudolf]

Hallo,
also ich hab Windows 7 wieder entsorgt, ist mir zu unsicher. Schaut super aus, läuft schnell, lässt sich problemlos installieren, aber mein Vertrauen hat es nicht
lg
Rudolf

[AUGE_OHR]

also ich hab Windows 7 wieder entsorgt, ist mir zu unsicher.

du gibst aber schnell auf ...

Frage : "welche" Version von Win7 ? OEM, Retail und welche Version davon, oder RC1 ?

die RC1 Version hast du doch wohl selbst von M$ downgeloadet und das ISO gebrannt ?
... es gibt diverse Versionen "im Umlauf" die nicht original sind !!!

nachdem du Win7 installiert hattest, hast du sicherlich einen "Leistungstest" gemacht ?
wenn er da "hängt" liegt es meistens am Bildschirmtreiber ...

naja und online "updates" hattes du ja sicherlich auch alles auf den "lates" Stand gebracht ?

... und dann fragt sich "wie" du Xbase++ "wohin" installiert hast ... doch etwa nicht nach
c:\Programme ...

3PP Tools ?

Op´s look mit SMB2 ?

...aber mein Vertrauen hat es nicht

Vertrauen ist auch eine Sache der Zeit.
Ich habe Win7 jetzt seit über 6 Monaten "nebenbei" am laufen und auch in der Zeit an der
Hardware "geschraubt", aber ganz "vertrauen" tue ich dem ganzen dennoch nicht ganz ...

Ich kann, per FSB, bis 28x121 3,388GHz "hochtakten" und bei FSB122 crasht er dann. Unter
DOS/Win98se kann ich die bis >3.5GHz jagen, also liegt es nicht an der Hardware.
Ich weiss noch aus NT4 Zeiten das dass meisten ein Grafikkarten Problem war und das "wirkt"
sich auch auf den Rest der Hardware aus und produziert "komische" Fehler.

Tja und nun steht Win7 "vor der Tür" und ob man will oder nicht man wird sich damit beschäftigen
müssen so wie "damals" mit VISTA ... und den "Problemchen" die man mit dem "Rechte" System hat

[Rudolf]

Hallo Jimmy,
war eine sauber Installation, direkt runtergeladen mit ISO Image. Dann einfach in ein eigenes Verzeichnis auf C rüberkopiert. Compilieren und linken hat keine Fehler gebracht, aber die EXE war nachher nicht lauffähig. Habe sie leider aufgehoben, sonst hätte ich sie im Detail vergleichen können. Vor dem complilieren ist sie noch einwandfrei gelaufen. Leider hatte ich nicht genug Zeit zum Testen, aber der nächste Rechner wartet schon,auf dem werd ich es nebenbei genauer ansehen. Wäre schade, Windows 7 gefällt sonst sehr gut,vor allem schnell und intuitiver zu bedienen. Die Installation lief auch total prolemlos, besser bei Vista und XP. Aber würde mich auch wundern, wenn es jetzt schon problemlos laufen würde.
Grüsse
Rudolf

[Koverhage]

Rudolf,

es läuft auch bein einem Kunden von uns problemlos (ok der erstellt die Exe Dateien nicht selber),
aber kann ja nur was mit den Pfaden zu tun haben. Soll das eine Entwicklungsmaschine werden ?
Der hat das schon im Echtzeitbetrieb (als Arbeitsplatz).
Hat alles selber installiert, Netzwerkverbindungen alles kein Problem, zählt auch nicht unbedingt zu den
Profis, was Installation usw. betrifft und ist weit über 60!

Klaus

[Rudolf]

Hallo Klaus,
es ist ja vorher gelaufen, erst nach dem Linken war die EXE nicht mehr aufrufbar.
Grüsse
Rudolf

[psp]

Hallo,

ich stehe nun auch vor dem Problem. Windows 7 Ultimate 64 Bit installiert, XBase++ 1.9 ließ sich nicht normal installieren, daher die komplette Installation von Windows XP übernommen und mittels der Reg-Dateien die Pfade und Variablen im System registriert.

Die Übersetzung selbst läuft an und auch bis zum Ende durch. Doch die fertig übersetzten Programm sind weder unter Windows 7 noch unter Windows XP (XP-Modus) lauffähig. Xbase 1.90.355 ist in Verwendung

Habe ich irgendwas vergessen oder hat jemand noch einen Tipp, was man tun kann?

MfG

[Martin Altmann]

Moin,
was heißt: läuft nicht?
Kommt eine Windows-Fehlermeldung beim Starten? Oder passiert scheinbar gar nichts? In letzterem Fall: gibt es eine XPPFATAL.LOG, die erzeugt wird?
In welchem Verzeichnis liegt denn Deine EXE? Und in welchem Deine sourcen (in welchem rufst Du das PBUILD auf und in welches werden Deine OBJ-Dateien geschrieben)?
Das Kopieren der Alaska-Verzeichnisse und das Importieren der XPP.REG hat bei mir gereicht! Ich musste nur noch einmal in das Fenster mit den gesetzten Umgebungsvariablen gehen und dieses mit OK verlassen (damit die per XPP.REG importierten Einstellungen sofort greifen).
Aber das Problem hast Du ja nicht mehr, da Du ja die Anwendung kompilieren und linken kannst.

Viele Grüße,
Martin

[AUGE_OHR]

Habe ich irgendwas vergessen oder hat jemand noch einen Tipp, was man tun kann?

Frage : laufen die Xbase++ Demo Sample ? ... neu erstellen !

verwendest du XbpToolbar() oder XbpStatusbar() ? wenn ja musst du noch MSCOMCTL.OCX registrieren, alles mit "runas Administrator" !!!

wenn du XbpRFT() verwendest ist das RICHTX32.OCX auf der Win7 Maschine zu "installieren"

Wenn du Express++ hast würde ich auch den Express++ Source neu stellen (dann stimmen auch die PATH wenn es klappt)

last but not least : mit XppLOAD kontrollieren ob nicht irgendwo noch "alte" *.DLL geladen werden

[psp]

Guten Morgen,

danke schon mal für die Antworten. Nun versuche ich dies mal abzuarbeiten.

Ob die Demos nach der Neukompilierung noch funktionieren, kann ich nicht sagen. Wird zwangsläufig dahin führen. Die von uns erstellen Programme sind allesamt GUI-Programme, verwenden weder Toolbar, Statusbar noch RTF-Komponenten. Express++ verwenden ebenso wir nicht. XPPLoad könnte ich mal versuchen.

Jedoch startet selbst das einfachste Beispiel nicht:

Code: Alles auswählen

#include "inkey.ch"

PROCEDURE Main
  ? "Test"
RETURN

Unter Windows 7 bekomme ich nach dem Programmstart einen höflichen Hinweis zur Problembehandlung und versucht etwas mit dem Kompatibilitätsmodus anzufangen, was auch nach hinten los geht. Unter Windows XP bekomme ich die Meldung mit dem Problembericht, den ich zu Microsoft übermitteln kann. Eine XPPFATAL.LOG wird nicht erstellt, soweit kommt das Programm gar nicht. Das Beispiel-Programm von oben liegt in dem Verzeichnis mit dem Quelltext. Während die großen Programme in das Datenverzeichnis kopiert werden müssen. Das Ergebnis ist jedoch immer das gleiche. Die Obj-Dateien werden in separate Verzeichnisse gelinkt, da wir IFDEF-Definitionen exzessiv benutzen:

Code: Alles auswählen

//
// Project - Definition - File created by PBUILD Version 1.0
// Date: 31.01.99 Time: 13:53:04
//

[PROJECT]
    COMPILE       = xpp
    DEBUG         = yes
    DEBUG_SAVE    = yes
    GUI           = yes
    LINKER        = alink
    LINK_FLAGS    =
    RC_COMPILE    = arc
    RC_FLAGS      = -v
    ROOT

[ROOT]
    .\testBDE\PASSBDE.EXE
...

[.\testBDE\PASSBDE.EXE]
    COMPILE_FLAGS = /dBDE /q
    OBJ_DIR = .\testBDE\obj
// $START-AUTODEPEND
...

Mit dem Xbase-Debugger bekomme ich jeweils die Meldung 0xC000005 "DLL Version Conflict".

[brandelh]

Hi,

bei meinem Vista Notebook hat gestern die "schelle Methode" auch nicht funktioniert ...
Mal sehen ob ich neute noch dazu komme das nochmal zu machen.

[psp]

die Xbase-Samples lassen sich dagegen übersetzen und laufen auch, bin gerade noch am Probieren

[psp]

bin noch etwas weiter

die Programme laufen nun wieder, nachdem ich sie auf einem lokalen Laufwerk übersetzt habe

über die Netzwerkfreigabe ging das dagegen nicht

[Martin Altmann]

Prima,
dann weißt Du ja, wo Du suchen musst
Rechte - und wenn das alles stimmt und es trotzdem nicht geht, statt UNC-Namen vielleicht besser Laufwerksbuchstaben verwenden (also subst).

Viele Grüße,
Martin

[brandelh]

Hi,

ja UNC Namen haben Ihre Tücken. Man kann zwar wunderbar damit arbeiten solange man USE oder andere interne Befehle nutzt,
aber eine CMD Datei z.B. geht damit nicht. Hinzu kommt, dass auch mit Laufwerksbuchstaben einiges auf Netzwerklaufwerken aus Berechtigungsgründen grundsätzlich nicht geht. Waren die CHM nicht so ein Beispiel ?

[psp]

ich hab genug Rechte, sogar "Jeder" hatte testweise Vollzugriff, über UNC arbeite ich am Arbeitsplatz selten, sind schon über Netzlaufwerk verbinden auf einem Laufwerksbuchstaben gemappt gewesen

die Ursprünglichen Daten liegen ja lokal auf dem Arbeitsplatz aber durch die Verzeichnisstruktur halt recht tief, nun hab ich die beiden Verzeichnisebenen in die Bibliothek gehängt, wie es mit Kompilierungen auf einem richtigen Netzlaufwerk aussieht, teste ich gleich mal ab, da sind die Rechte durch den Server vorgegeben und ich habe dort alle administrativen Rechte, die man haben kann (Administrator, Domänenadministrator usw.)

edit:

Übersetzung auf einem richtigen Netzlaufwerk ist durch, Programme ebenfalls nicht lauffähig wie vorher

[AUGE_OHR]

ich hab genug Rechte, sogar "Jeder" hatte testweise Vollzugriff, über UNC arbeite ich am Arbeitsplatz selten, sind schon über Netzlaufwerk verbinden auf einem Laufwerksbuchstaben gemappt gewesen

ich fürchte das Win7 doch da deutlich restriktiver ist. Auch als "runas Administrator" bist du noch nicht unbedingt "Herrscher" im Netzwerk.

Frage : was für ein "Server" hast du und welches OS() ?

Ich versuche mich ja am 2008 Server und lese da immer wieder vom SMB2 Protokoll was mir mit "Sperren" ständig den Weg verbaut.
ähnlich wie bei Oportunistic Locking muss ich dabei die Registry (runas ...) modifizieren UND bei den Workstationen es entsprechend "enable"n ... booten und "warten" ...

Frage : wenn ihr in euren Win7 Taskmanager schaut, wie viele Dienste laufen da (alle anzeigen) ?

Bei XP hab ich ja alles "abgeschaltet" was ich nicht haben wollte, also laufen auch nur noch eine Handvoll davon.

Wenn man aber unter Win7 sich das ansieht ... vor allem die "Sicherheits"- Dienste, die man für bestimmte "tiefere" Eingriffe abschalten muss ...

[AUGE_OHR]

Übersetzung auf einem richtigen Netzlaufwerk ist durch, Programme ebenfalls nicht lauffähig wie vorher

im Alaska Forum habe ich das gefunden

On this second scenario, the Workstation uses Windows 7 and Server 2008 with
SMB 2.0 disabled. The problem now is that, when linking up a program from
the workstation, the executable generated is not correct. If this executable
is compared with the FC command, there are some differences if this same
routine is done from another computer.

also genau das was wir auch beobachtet haben

I try to activate the SMB 2.0 and then it links correctly.

dazu kann ich nichts sagen, den bei mir ist SMB2 abgeschaltet.

[Rudolf]

Hallo,
SMB2 abschalten hat auch nichts gebracht. Da es nur den Linker betrifft und auch schon andere in der offiziellen Newsgroup über das selbe Problem geschrieben haben, denke ich dass Alaska reagieren muss. Leider hört man von den wieder überhaupt nichts in der Beziehung. Werde wohl warten müssen bis sich sich genug andere bei Alaska gemeldet haben. In der Zwischenzeit muss ich eben alles auf C kopieren damit ich linken kann.
Grüsse
Rudolf

[lesny]

Danke an alle, dieser Forum-Thread hat mir viel Zeit der Fehlersuche erspart. Habe nämlich grade meine Entwicklungsumgebung auf neuen Laptop mit Windows 7 64-bit übertragen (einfach Alaska-Ordner kopiert und die Umgebungsvariablen gesetzt). Compilen und Linken hat gleich funktioniert, aber die Anwendung startete nicht, genau das Verhalten wie hier beschrieben: ein paar Sekunden, ohne dass was passiert und fertig. Keine Fehlermeldung, keine xppfatal.log, nichts. Ich dachte zunächst, dass der Linker unter 64-bit nicht funktioniert. Habe dann gemäß dem Tipp alle Quellen auf die lokale Festplatte gelegt und gelinkt, siehe da: die Anwendung läuft.

Übrigens: Die Quellen lagen vorher auch lokal, nur wurden sie über ein gemapptes Laufwerk angesprochen. Ich habe meinen Ordner mit den Quelldateien nämlich freigegeben, damit er im Netz erreichbar ist und einen Laufwerksbuchstaben auf diesen freigegebenen Ordner auf der lokalen Platte erstellt. Das reicht schon, dass der Linker nicht richtig arbeitet...

Ich arbeite übrigens mit Xbase++ 1.90.350

Grüße
Stefan

[Rudolf]

Hallo Stefan,
das Problem haben immer mehr so wie es aussieht. Habe meine Laufwerke mit VSUBST gemappt, hat auch nicht funktioniert. Nur wenn von C: aus gelinkt wurde, auch wenn der Linker woanders installiert ist, funktioniert es. Scheint so als ob nur der Aufruf wichtig ist, nämlich von C aus.
Grüsse
Rudolf

[Wolfgang Ciriack]

Vielleicht ist das ein ähnliches Problem wie das, was ich unter Windows 7 festgestellt habe:
Wenn man ein XBase++ - Programm UPDATER.EXE benennt, so lässt sich dieses auch nicht starten. Es hat automatisch das Administrator-Symbol angehängt, wenn man dann die Sicherheitsabfrage mit ja beantwortet, wird es trotzdem nicht gestartet.
Abhilfe schaffte da nur das umbenennen z.B. in UPDATFVW.EXE
Scheint da irgendwelche Programmnamen-Restriktionen zu geben.