Discussion:
Delphi aktiv?
(zu alt für eine Antwort)
Dirk Schauris
2004-11-11 13:45:53 UTC
Permalink
Hallo NG,

ich habe noch eine Frage:
wie erfahre ich am besten, ob Delphi aktiv ist?

Vielen Dank,
Dirk Schauries
Dirk Schauris
2004-11-11 13:57:43 UTC
Permalink
Sorry,
habs gefunden:
result := FindWindow('TAppBuilder', nil)>0;
Post by Dirk Schauris
Hallo NG,
wie erfahre ich am besten, ob Delphi aktiv ist?
Vielen Dank,
Dirk Schauries
Andreas Kardin
2004-11-11 14:20:31 UTC
Permalink
Hi
Post by Dirk Schauris
wie erfahre ich am besten, ob Delphi aktiv ist?
Aeh... was willst Du damit machen?

Grüsse
--
Andreas Kardin - Software Developer - E-Mail : ***@mephzara.com
- Main Web Site : www.mephzara.com
- Particle Systems Screen Saver : www.mephzara.com/particle-systems/
- XDreamity : www.xdreamity.de
Dirk Schauris
2004-11-11 14:43:27 UTC
Permalink
Hallo Andreas,
ich möchte wissen, ob mein Programm aus der Delphi-Umgebung heraus gestartet
wurde oder nicht.
Post by Andreas Kardin
Hi
Post by Dirk Schauris
wie erfahre ich am besten, ob Delphi aktiv ist?
Aeh... was willst Du damit machen?
Grüsse
--
- Main Web Site : www.mephzara.com
- Particle Systems Screen Saver : www.mephzara.com/particle-systems/
- XDreamity : www.xdreamity.de
Jens Winter
2004-11-11 14:48:25 UTC
Permalink
Post by Dirk Schauris
Hallo Andreas,
ich möchte wissen, ob mein Programm aus der Delphi-Umgebung heraus gestartet
wurde oder nicht.
FindWindow('TAppBuilder', nil) ist ein Indiz, aber kein Beweis dafür.

Ciao
Jens
Mario Rothacher
2004-11-11 15:00:26 UTC
Permalink
Post by Dirk Schauris
Hallo Andreas,
ich möchte wissen, ob mein Programm aus der Delphi-Umgebung heraus gestartet
wurde oder nicht.
Dann ist die Frage nicht richtig gestellt. Denn wenn Dein Delphi läuft,
kannst Du ja trotzdem ausserhalb das Exe starten.

Hier ist eine Unit mit welcher Du das feststellen kannst:

cu
Mario


{ Betreff: Re: Detecting IDE at Runtime?
Datum: Wed, 07 Jul 1999 11:16:20 GMT
Von: ***@nospam.trendline.co.il (Yorai Aminov (TeamB))
Firma: TeamB
Foren: borland.public.delphi.vcl.components.writing

I have a component that I want to release as demo version, for this I
want to only enable the component if Delphi is running. Is there an easy
way to do this with out having to make calls like enumeratewindows(),
and parsing the windows list. }

(**************************************************************)
(* Unit Name: DelRun *)
(* Description: Detect whether the current process is running *)
(* under the control of Delphi under Windows 95 *)
(* and NT. *)
(* Author: Yorai Aminov *)
(* Created: 30 April 1998 *)
(* Updates: 12 April 1999 *)
(* Use correct IsDebuggerPresent on Windows 98 *)
(* *)
(* Copyright (c) 1998, 99 Yorai Aminov *)
(**************************************************************)
unit DelRun;

interface

uses
Windows, Classes, SysUtils;

function RunningUnderDelphi: Boolean;

implementation

{ NtQueryInformation constants }

const
ProcessBasicInformation = 0;

{ NtQueryInformation types }

type
TProcessBasicInformation = packed record
ExitStatus: Integer;
PebBaseAddress: Pointer;
AffinityMask: Integer;
BasePriority: Integer;
UniqueProcessID: Integer;
InheritedFromUniqueProcessID: Integer;
end;

TNtQueryInformationProcess =
function(hProcess: THandle; ProcessInformationClass: Integer;
var ProcessInformation; ProcessInformationLength: Integer;
var ReturnLength: Integer): Integer; stdcall;

{ NT IsDebuggerPresent prototype }

type
TIsDebuggerPresent = function: BOOL; stdcall;

{ Retrieve parent process ID from NtQueryInformation }

function GetParentProcessIDForNT: Integer;
var
hNTDLL: Integer;
NtQueryInformationProcess: TNtQueryInformationProcess;
PBI: TProcessBasicInformation;
ReturnLength: Integer;
begin
Result := 0;
// Attempt to load NTDLL
hNTDLL := LoadLibrary('NTDLL.DLL');
if hNTDLL <> 0 then
begin
// Retrieve address of NtQueryInformationProcess
NtQueryInformationProcess := GetProcAddress(hNTDLL,
'NtQueryInformationProcess');
if Assigned(NTQueryInformationProcess) then
begin
// Call NtQueryInformationProcess
NtQueryInformationProcess(GetCurrentProcess,
ProcessBasicInformation,
PBI, SizeOf(PBI), ReturnLength);
// Return parent process ID
Result := PBI.InheritedFromUniqueProcessID;
end;
// Release NTDLL
FreeLibrary(hNTDLL);
end;
end;

{ Check for debugger under NT }

function IsDebuggerPresentForNT: Boolean;
var
Kernel32: THandle;
FIsDebuggerPresent: TIsDebuggerPresent;
begin
Result := False;
// Attempt to load KERNEL32
Kernel32 := LoadLibrary('KERNEL32.DLL');
if Kernel32 <> 0 then
begin
// Retrieve address of IsDebuggerPresent
FIsDebuggerPresent := GetProcAddress(Kernel32,
'IsDebuggerPresent');
// Return True if a debugger is present
if Assigned(FIsDebuggerPresent) then
Result := FIsDebuggerPresent;
// Release KERNEL32
FreeLibrary(Kernel32);
end;
end;

{ ToolHelp32 constants }

const
TH32CS_SNAPPROCESS = $00000002;

{ ToolHelp32 types }

type
PProcessEntry32 = ^TProcessEntry32;
TProcessEntry32 = record
dwSize: DWORD;
cntUsage: DWORD;
th32ProcessID: DWORD;
th32DefaultHeapID: DWORD;
th32ModuleID: DWORD;
cntThreads: DWORD;
th32ParentProcessID: DWORD;
pcPriClassBase: Longint;
dwFlags: DWORD;
szExeFile: array[0..MAX_PATH - 1] of Char;// Path
end;

{ ToolHelp32 function prototypes }

type
TCreateToolhelp32Snapshot =
function(dwFlags, th32ProcessID: DWORD): THandle; stdcall;
TProcess32First =
function(hSnapshot: THandle; var lppe: TProcessEntry32): BOOL;
stdcall;
TProcess32Next =
function(hSnapshot: THandle; var lppe: TProcessEntry32): BOOL;
stdcall;

function GetParentProcessIDForWindows: Integer;
var
Kernel32: THandle;
CreateToolhelp32Snapshot: TCreateToolhelp32Snapshot;
Process32First: TProcess32First;
Process32Next: TProcess32Next;
Snapshot: THandle;
Entry: TProcessEntry32;
WalkResult: Boolean;
ID: ULONG;
begin
Result := 0;
// Attempt to load KERNEL32
Kernel32 := LoadLibrary('KERNEL32.DLL');
if Kernel32 <> 0 then
begin
// Retrieve ToolHelp32 function addresses
CreateToolhelp32Snapshot :=
GetProcAddress(Kernel32, 'CreateToolhelp32Snapshot');
Process32First := GetProcAddress(Kernel32, 'Process32First');
Process32Next := GetProcAddress(Kernel32, 'Process32Next');
if Assigned(CreateToolhelp32Snapshot) and
Assigned(Process32First) and
Assigned(Process32Next) then
begin
// Retrieve current process ID for comparison
ID := GetCurrentProcessId;
// Create processes snapshot
Snapshot := CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
if Integer(Snapshot) <> -1 then
begin
// Start walking list of processes
Entry.dwSize := SizeOf(TProcessEntry32);
WalkResult := Process32First(Snapshot, Entry);
// Walk through entire list until result can be determined
while (GetLastError <> ERROR_NO_MORE_FILES) and (Result = 0)
do
begin
if WalkResult then
begin
// If this is the current process, return its parent
if Entry.th32ProcessID = ID then
Result := Entry.th32ParentProcessID;
end;
// Move to next item in the process list
Entry.dwSize := SizeOf(TProcessEntry32);
WalkResult := Process32Next(Snapshot, Entry);
end;
// Release handle to the snapshot
CloseHandle(Snapshot);
end;
end;
// Release KERNEL32
FreeLibrary(Kernel32);
end;
end;

{ Process database constants }

const
fDebugSingle = $00000001;

{ Process database types }

type
PProcessDatabase = ^TProcessDatabase;
TProcessDatabase = packed record
DontCare1: array[0..7] of Integer;
Flags: Integer;
DontCare2: array[0..11] of Integer;
DebugeeCB: Integer;
DontCare3: array[0..22] of Integer;
DontCare4: Word;
end;

function IsDebuggerPresentForWindows: Boolean;
var
PDB: PProcessDatabase;
TID: Integer;
Obsfucator: ULONG;
begin
Result := False;
Obsfucator := 0;
TID := GetCurrentThreadID;
// Calculate Obsfucator
asm
MOV EAX, FS:[18h]
SUB EAX, 10h
XOR EAX, [TID]
MOV [Obsfucator], EAX
// Obsfucator := (@TIB - $10) xor GetCurrentThreadID
end;
if Obsfucator <> 0 then
begin
// Retriece pointer to the PDB
PDB := Pointer(GetCurrentProcessID xor Obsfucator);
// Return True if process is being debugged
Result := (PDB^.Flags and fDebugSingle) <> 0;
end;
end;

function GetParentProcessID: Integer;
begin
// If Windows 95/98 or NT 5.0+, use ToolHelp32
if (Win32Platform = VER_PLATFORM_WIN32_NT) and
(Win32MajorVersion < 5) then
Result := GetParentProcessIDForNT else
Result := GetParentProcessIDForWindows;
end;

function IsDebuggerPresent: Boolean;
begin
// If Windows 95, use PDB. Otherwise, use NT's IsDebuggerPresent
if (Win32Platform = VER_PLATFORM_WIN32_NT) or
((Win32Platform = VER_PLATFORM_WIN32_WINDOWS) and
((Win32MajorVersion > 4) or
((Win32MajorVersion = 4) and (Win32MinorVersion > 0)))) then
Result := IsDebuggerPresentForNT else
Result := IsDebuggerPresentForWindows;
end;

procedure EnumWindowsProc(Window: THandle; LParam: Integer); stdcall;
var
ClassName: string;
begin
// Allocate space for class name
SetLength(ClassName, 255);
// Retrieve window's class name
GetClassName(Window, PChar(ClassName), 255);
// Reallocate string length
SetLength(ClassName, StrLen(PChar(ClassName)));
// If window belongs to an instance of Delphi, add to list
if ClassName = 'TAppBuilder' then
TList(LParam).Add(Pointer(Window));
end;

function RunningUnderDelphi: Boolean;
var
List: TList;
i: Integer;
ID, ParentID: Integer;
begin
Result := False;
// Retrieve ID for the parent process
ParentID := GetParentProcessID;
// If ID found and being debugged, check for Delphi
if (ParentID <> 0) and (IsDebuggerPresent) then
begin
// Create a list of window handles
List := TList.Create;
// Fill list with window handles for instances of Delphi
EnumWindows(@EnumWindowsProc, Integer(List));
// Check Delphi instances
for i := 0 to List.Count - 1 do
begin
// Get process ID for the Delphi window
GetWindowThreadProcessID(Integer(List[i]), @ID);
// Compare IDs
if ID = ParentID then
begin
// The process parent ID is Delphi's process ID
Result := True;
Break;
end;
end;
// Free list
List.Free;
end;
end;

end.
Dirk Schauris
2004-11-11 15:15:11 UTC
Permalink
Wau, nicht schlecht.
Vielen Dank!
Dirk
Mario Rothacher
2004-11-11 15:19:17 UTC
Permalink
Post by Dirk Schauris
Wau, nicht schlecht.
Vielen Dank!
Dirk
Bitte gern geschehen... War auch mal froh dass mir das jemand geschickt
hatte...

cu
Mario
Andreas Kardin
2004-11-11 15:31:44 UTC
Permalink
Hi
Post by Dirk Schauris
ich möchte wissen, ob mein Programm aus der Delphi-Umgebung heraus
gestartet wurde oder nicht.
:) Ok, ich meinte aber eigentlich eher, warum Du das wissen willst bzw.
warum muss Dein Programm wissen, ob es auf einer Kiste mit oder ohne Delphi
oder aus Delphi oder nicht gestartet wurde?

Gruss
--
Andreas Kardin - Software Developer - E-Mail : ***@mephzara.com
- Main Web Site : www.mephzara.com
- Particle Systems Screen Saver : www.mephzara.com/particle-systems/
- XDreamity : www.xdreamity.de
Dirk Schauris
2004-11-11 17:19:44 UTC
Permalink
Post by Andreas Kardin
:) Ok, ich meinte aber eigentlich eher, warum Du das wissen willst bzw.
warum muss Dein Programm wissen, ob es auf einer Kiste mit oder ohne Delphi
oder aus Delphi oder nicht gestartet wurde?
Gruss
Mein Kollege möchte automatische Upates erstellen. Er startet seine Exe,
kopiert sie, benennt sie um, startet dann die Kopie und beendet sich selbst
wieder. Die Starter-Exe ist jetzt nicht mehr aktiv und kann überkopiert
werden. Beim nächten Start wird das Update gestartet.
Unter Delphi möchte er diesen Mechanismus unterdrücken.
Das ist der Grund

MfG, Dirk
Andreas Kardin
2004-11-11 19:26:56 UTC
Permalink
Hi
Post by Dirk Schauris
Mein Kollege möchte automatische Upates erstellen. Er startet seine
Exe, kopiert sie, benennt sie um, startet dann die Kopie und beendet
sich selbst wieder. Die Starter-Exe ist jetzt nicht mehr aktiv und
kann überkopiert werden. Beim nächten Start wird das Update gestartet.
Unter Delphi möchte er diesen Mechanismus unterdrücken.
Das ist der Grund
Freche Frage :) Würde ein Kompilerschalter, den man beim Entwickeln der IDE
setzt und den Mechanismus deaktiviert, nicht auch reichen?

Beim finalen Build für den Kunden/den produktiven Einsatz setzt man den
dann einfach nicht und alles ist gut - ohne IDE-Fenster-Titel-Handles-
Prozess-IDs oder andere "wüste" Geschichten abzufragen.

Grüsse
--
Andreas Kardin - Software Developer - E-Mail : ***@mephzara.com
- Main Web Site : www.mephzara.com
- Particle Systems Screen Saver : www.mephzara.com/particle-systems/
- XDreamity : www.xdreamity.de
Mario Rothacher
2004-11-12 10:01:50 UTC
Permalink
Post by Andreas Kardin
Freche Frage :) Würde ein Kompilerschalter, den man beim Entwickeln der IDE
setzt und den Mechanismus deaktiviert, nicht auch reichen?
Beim finalen Build für den Kunden/den produktiven Einsatz setzt man den
dann einfach nicht und alles ist gut - ohne IDE-Fenster-Titel-Handles-
Prozess-IDs oder andere "wüste" Geschichten abzufragen.
Solche Schalter vergisst man dann gerne umzuschalten...

Was automatisiert geht, geht dann eben auch nicht schief. Wir benutzen
bei uns das sogar noch etwas anders. Man darf unsere Applikation
*einmal* pro DB-Instanz (Prod, Test) starten. Aber als Entwickler ist
das mühsam. Du willst etwas korrigieren und schaust das aktuelle Exe
direkt ohne Delphi auf der Test-DB an, und mit der Korrektur mit
Delphi-Umgebung auch auf der Test-DB an. Also sieht es eigentlich so aus:

- Die Applikation darf pro DB-Instanz ohne Delphi-IDE nur einmal laufen.
- Aus der Delphi-IDE gibt es keine Beschränkung.

Und Test-User kriegen bei uns z.T. mehrmals täglich einen neuen Build
zum testen. Dann würde das mit dem Kompilerschalter aber ziemlich
umständlich...

cu
Mario
Andreas Kardin
2004-11-12 10:17:11 UTC
Permalink
Mario Rothacher wrote :

[...]
Post by Mario Rothacher
Und Test-User kriegen bei uns z.T. mehrmals täglich einen neuen Build
zum testen. Dann würde das mit dem Kompilerschalter aber ziemlich
umständlich...
Dann sieht die Situation schon etwas anders aus. Ich kenne die Problematik
auch. Vor allem wenn ich an meinen Shareware-Dingern gebastelt habe. Dort
sieht's allerdings so aus, dass ich nicht nur Kompilerschalter umzuschalten
habe, sondern für den finalen Build auch andere Compiler-Optionen (keine
Debug-Info, Optimierungen an usw.).

Wenn ich wieder mal an den Dingern weiter bastle, werd ich mir entweder ein
Tool zulegen, mit dem man Builds automatisieren kann (Name eines
interessanten Open-Source-Teils für Delphi ist mir entfallen, IIRC gibt's
da aber was) od. eine Batchdatei schreiben, welche den finalen Build mit
all den gewünschten Schaltern und Optionen durchrattert.

So kann dann wirklich nichts vergessen werden und es ist sogar bequem.
Delphi compiliert und linkt so schnell, dass man auch grössere Projekte mal
eben kurz voll durchkompilieren kann. Und aus Konfiguration-Management-
Sicht ist ein sauberer, automatisierter Build-Prozess sowieso sehr schön.

Grüsse
--
Andreas Kardin - Software Developer - E-Mail : ***@mephzara.com
- Main Web Site : www.mephzara.com
- Particle Systems Screen Saver : www.mephzara.com/particle-systems/
- XDreamity : www.xdreamity.de
Gerd Stuber
2004-11-12 10:27:23 UTC
Permalink
Post by Andreas Kardin
[...]
Wenn ich wieder mal an den Dingern weiter bastle, werd ich mir entweder ein
Tool zulegen, mit dem man Builds automatisieren kann (Name eines
interessanten Open-Source-Teils für Delphi ist mir entfallen, IIRC gibt's
da aber was) od. eine Batchdatei schreiben, welche den finalen Build mit
[...]
Diese "Open-Source-Teil" würde mich interessieren, hat ersatzweise jemand
Erfahrung mit FinalBuilder?
--
Gerd Stuber, Regensburg
Modellbahnprojekt Peißenberg : www.moddelbaan.de
Spams bitte an ***@abfalleimer.de :-)
Michael Winter
2004-11-13 21:02:22 UTC
Permalink
Post by Dirk Schauris
Mein Kollege möchte automatische Upates erstellen. Er startet seine Exe,
kopiert sie, benennt sie um, startet dann die Kopie und beendet sich selbst
wieder. Die Starter-Exe ist jetzt nicht mehr aktiv und kann überkopiert
werden. Beim nächten Start wird das Update gestartet.
Unter Delphi möchte er diesen Mechanismus unterdrücken.
Für diesen einfachen Fall ist ein simples IsDebuggerPresent völlig
ausreichend:

function IsDebuggerPresent: Bool; stdcall; external kernel32;

-Michael

Loading...