was macht System.IsMultiThread genau?

[EWeiss]

Kann mir jemand erklären was der aufruf

Delphi-Quellcode:

System.IsMultiThread := true;

im System genau bewirkt?

Mein problem ist das jemand nicht in der lage ist BassVis mit seiner anwendung vernünftig zu debuggen.
Wäre es möglich, das, wenn diese zeile sich nicht in der DLL befindet es beim Debuggen
in fremden Anwendungen zu problemen kommen kann?

Alles funktioniert zu 98% nur jetzt nervt mich jemand mit diesen Problem.

Ich habs mal eingefügt .. nur lößt das mein problem ?

Delphi-Quellcode:

  procedure LibraryProc(Reason: integer);
  begin
    case (Reason) of
      DLL_PROCESS_ATTACH:
      begin
        BassHandle := LoadLibrary('bass.dll');
        if (BassHandle = 0) then
        begin
          MessageBox(0, 'Unable to load ''bass.dll''' + #13#10 + 'Halting the library process', 'Fatal Error!!', MB_ICONERROR);
          ExitCode := 1;
          Exit;
        end;

        BassFuncs := GetProcAddress(BassHandle, '_');
        if (BassFuncs = nil) then
        begin
          FreeLibrary(BassHandle);
          BassHandle := 0;

          MessageBox(0, 'Unable to load add-on functions from ''bass.dll''' + #13#10 + 'Halting the library process', 
         'Fatal Error!!', MB_ICONERROR);
          ExitCode := 1;
          Exit;
        end;
        System.IsMultiThread := true;
      end;
      DLL_PROCESS_DETACH:
      begin
        if (BassHandle <> 0) then
        begin
          FreeLibrary(BassHandle);
          BassHandle := 0;
        end;

        if (FindPluginsPtr <> nil) then
          StrDispose(FindPluginsPtr);
      end;
    end;
  end;

gruss Emil

[Klomeister]

IsMultiThread wird auf true gesetzt, um anzugeben, dass der Speichermanager mehrere Threads unterstützen soll. IsMultiThread wird von BeginThread und Klassengeneratoren auf true gesetzt

[EWeiss]

Zitat:

Zitat von Klomeister

IsMultiThread wird auf true gesetzt, um anzugeben, dass der Speichermanager mehrere Threads unterstützen soll. IsMultiThread wird von BeginThread und Klassengeneratoren auf true gesetzt

Das bedeutet ?
Es dürften dann eigentlich keine kompatibilitätsprobleme mit bsp.. Delphi 7
oder anderen sprachen mehr auftreten und das Debuggen würde fehlerfrei funktionieren?

Sorry ! Habe mich damit noch nicht richtig beschäftig.

Wie kann ein solches problem noch auftreten ?
obwohl die DLL Fehlerfrei läuft bei mir unter D06 auch beim debuggen
hat der user mit D7 immer abstürze sobald er debuggen will.

Ohne Debuggen funktioniert es einwandfrei!

Zitat:

I'll convince him to add exclusion to madCodeHook.

My will is to fix Bass_Vis.dll becouse it gives me a headache not using Delphi's built in debug mode, if it is needed give me the source code for Bass_Vis and I try to fix it. Or fix it somehow!

My problem is that I can't debug any projects under Delphi 7 (not even Turbo Delphi Explorer) when Bass_Vis.dll is loaded in the process space.

MP3 Stream Editor of course uses natively Filesystem Dialogs, and not hooked. Why should I hook when I load it with LoadLibrary()?

It's really indifferent weather a wrapper .dll is issuing LoadLibrary() or the main executable or whatever, as they are running in the same process space as of NT, as WindowsXP is a multiple - single process space architecture, not as Windows 98 where bunch of the .dlls are shared by all the processes, and a .dll failure can bring down the whole system.

Filesystem Dialogs's sources are totally freely available from the site.

I know that it works 100% without debugging, it works perfectly really, the only problem is when trying to debug an application with Bass_Vis.dll loaded, with my operating system, as you wrote it, that it works ok there.

My only aim is to fix the bug that makes problems here, and that means that it can give problems to other peoples too.

BassVis ist kein opensource und wird auch keiner daher habe ich nun das problem den Fehler so zu finden.

gruss Emil

[EWeiss]

Kann mein problem nicht lösen!
Hat jemand eine Idee warum manchmal beim debuggen unter Delphi 7 AVS auftreten und unter D06 nicht ?

Weiss mir da keinen rat mehr.

gruss Emil

[SirThornberry]

kommen die AV's beim Debuggen auch bei dir wenn du mit D7 debuggst oder nur beim Kunden?
Gründe für AV's können Dingen in den Watches etc. sein die Funktionen aufrufen oder anderweitig den Speicher verändern.

[EWeiss]

Zitat:

Zitat von SirThornberry

kommen die AV's beim Debuggen auch bei dir wenn du mit D7 debuggst oder nur beim Kunden?
Gründe für AV's können Dingen in den Watches etc. sein die Funktionen aufrufen oder anderweitig den Speicher verändern.

Bisher bei allen die D7 verwenden..
Habe es gerade mal installiert und will schauen ob es bei mir auch auftritt.
Ist aber schon seltsam keine probs in d06 und d7 macht ärger.

Fertige Anwendungen laufen ohne probleme nur debuggen kann man nicht.

gruss Emil

[SirThornberry]

würde ich dir auch empfehlen, dann siehst du auch an welchen Stellen die AV in der DLL kommt und kannst schauen an welcher Stelle im Source das ist.

[EWeiss]

Zitat:

Zitat von SirThornberry

würde ich dir auch empfehlen, dann siehst du auch an welchen Stellen die AV in der DLL kommt und kannst schauen an welcher Stelle im Source das ist.

Jo ..
Vielleicht ne dumme frage ;)
Hat IsMultiThread irgendeinen einfluss darauf ?
ob es sich nun debuggen läßt oder nicht ?

bzw.. sollte ich die AVS unterdrücken in der procedure wo das problem auftaucht ?

Saved8087CW := Default8087CW;
Set8087CW($133f);

gruss Emil

[SirThornberry]

Ob isMultiThread einen Einfluss darauf hat weiß ich nicht, sollte aber nicht wenn es in einem extra Modul steckt.
Und Fehler unterdrücken ist der falsche Ansatz. Eine Zugriffsverletzung kommt schließlich weil an einer falschen Speicheradresse auf Speicher zugegriffen werden soll. Im Schlimmsten fall kommt also mal keine Zugriffsverletzung und Speicher wird an falschen Stellen gelesen oder geschrieben. Es gilt also - Fehler finden!

[EWeiss]

Zitat:

Zitat von SirThornberry

Ob isMultiThread einen Einfluss darauf hat weiß ich nicht, sollte aber nicht wenn es in einem extra Modul steckt.
Und Fehler unterdrücken ist der falsche Ansatz. Eine Zugriffsverletzung kommt schließlich weil an einer falschen Speicheradresse auf Speicher zugegriffen werden soll. Im Schlimmsten fall kommt also mal keine Zugriffsverletzung und Speicher wird an falschen Stellen gelesen oder geschrieben. Es gilt also - Fehler finden!

Jo ist wohl der sinnvollste weg..
Nur konnte bisher keinen finden bei mir läuft das durch ohne zicken.
Vielleicht die compileroption zu stark eingestellt bei den anderen...

Hmm versteh das nicht!

Das wäre vielleicht mein ansatz gewesen.

Delphi-Quellcode:

  procedure LibraryProc(Reason: integer);
  begin
    case (Reason) of
      DLL_PROCESS_ATTACH:
      begin
        BassHandle := LoadLibrary('bass.dll');
        if (BassHandle = 0) then
        begin
          MessageBox(0, 'Unable to load ''bass.dll''' + #13#10 + 'Halting the library process', 'Fatal Error!!', MB_ICONERROR);
          ExitCode := 1;
          Exit;
        end;

        BassFuncs := GetProcAddress(BassHandle, '_');
        if (BassFuncs = nil) then
        begin
          FreeLibrary(BassHandle);
          BassHandle := 0;

          MessageBox(0, 'Unable to load add-on functions from ''bass.dll''' + #13#10 + 'Halting the library process', 'Fatal Error!!', MB_ICONERROR);
          ExitCode := 1;
          Exit;
        end;
        System.IsMultiThread := true;
        Saved8087CW := Default8087CW;
        Set8087CW($133f);
      end;
      DLL_PROCESS_DETACH:
      begin
        if (BassHandle <> 0) then
        begin
          FreeLibrary(BassHandle);
          BassHandle := 0;
        end;

        if (FindPluginsPtr <> nil) then
          StrDispose(FindPluginsPtr);

        Set8087CW(Saved8087CW)
      end;
    end;
  end;

um den Fehler der meistens hier auftritt wie berichtet zu umgehen..

Delphi-Quellcode:

function BASS_VIS_FindPlugins(vispath: PChar; flags: DWORD): PChar; stdcall;
var
  fPath: PChar;
  i, z: Integer;
  Plugins: String;
  DllHandle: THandle;
  VisList: TStringList;
  sSonique, sWinamp, fRecursive: Boolean;

  procedure SearchDir(const dPath: String);
  var
    x: Integer;
    sRec: TSearchRec;
  begin
    if (sSonique) then
    begin
      x := FindFirst(dPath + '*.svp', faAnyFile, sRec);
      while (x = 0) do
      begin
        if (FileExists(dPath + sRec.Name)) then
          VisList.Add(dPath + sRec.Name);

        x := FindNext(sRec); .....

Nur wie gesagt bei mir tritt keiner auf.
Auch unter D7 nicht.

gruss Emil