2010-02-01 19 views
16

Sto integrando un SDK di terze parti basato su C nella mia applicazione .NET. L'applicazione verrà eseguita come servizio Windows su un server, quindi non dovrebbe interagire con l'utente in alcun modo.Come posso impedire a una libreria di terze parti di visualizzare un MessageBox?

Sfortunatamente, in determinate condizioni di errore, insiste nel chiamare MessageBoxA, presumibilmente per segnalare che qualcosa di brutto è successo. Quando ciò accade, il servizio si blocca. Immagino che stia aspettando che qualcuno prema Ok?

Non è possibile che il fornitore modifichi il proprio codice per me.

C'è un modo per rendere questa chiamata su un no-op in modo che il mio codice possa gestire automaticamente la situazione?

MODIFICA: Potrebbe essere importante menzionare che nel mio caso particolare il servizio si riavvierà automaticamente in caso di arresto anomalo. Una grazia (il più possibile) e l'uscita improvvisa sono probabilmente la migliore risoluzione per una situazione in cui un MessageBox viene visualizzato nel mio caso.

+9

Non è una risposta reale, lo so, ma trovare una libreria/servizio migliore. Se una biblioteca ha questo tipo di problema, è probabile che ne abbia di più. –

+0

Ricordo che un mio ex collaboratore idiota mise in una finestra di messaggio un codice che era noto per essere un servizio.Gli ho detto di rimuoverlo ma l'ha lasciato comunque e abbiamo dovuto ri-rilasciare il software ... non andava bene. – Tim

+0

No, dite che non è così un MessageBox da una libreria !!!! Buona domanda –

risposta

10

Check out Detours from Microsoft Research. Ti permette di deviare arbitrarie funzioni API di Windows. La programmazione in C/C++ è necessaria per farlo funzionare. Non ti servirà molto.

+0

Wow, non sapevo che avresti potuto farlo. – Jeremy

+2

@nobugz Sei come una biblioteca. Sul serio. –

+0

Ho letto le risposte di nobugz qui e i forum MSDN, e sono convinto che sia Dave Cutler. –

3

È possibile utilizzare un editor per trovare la posizione di questo e rimuovere la chiamata dal loro binario. Ma questo può o non può essere consentito in base alle limitazioni d'uso con il software. Certamente se lo ridistribuisci potrebbe causare problemi - dovresti chiedere al venditore e segnalarlo come un difetto e suggerire di avere una soluzione alternativa per il tuo uso personale.

Per le persone abituate a fare questo genere di cose (cracking licenze o altro reverse engineering) questo è piuttosto semplice, ma la vera domanda è, cosa succede se viene ignorata - continua a funzionare?

+1

In questo caso lo schianto è ok. È molto peggio che il servizio si blocchi come fa. – Jeremy

+0

Bene, allora, se sai che è ok, puoi anche uscire dal processo e usare un altro watchdog per riportarlo su se non è stato trovato in esecuzione. Eviterei quella complessità se potessi e vedessi se riesci a farla franca con NO-OP-it. Quindi ovviamente il problema legale con la distribuzione/l'uso? Se non conosci nessuno che abbia capacità, conosco qualcuno che mi ha segnalato a chi ama creare i binari del reverse engineer. – Tim

+0

C'è già un watchdog di un tipo - se il programma dovesse bloccarsi, sarebbe riavviato automaticamente. Ecco perché è così frustrante per me che si blocca! :) Non conosco ancora i problemi legali. – Jeremy

0

Questo non è molto facile. Penserei che l'unico modo è di scrivere un hook di messaggio per intrappolare messaggi pompati attraverso tutti i loop di messaggi di Windows sul sistema. Ma non sono nemmeno sicuro che un servizio possa creare un hook di messaggio dato che non ha accesso alla stazione finestra predefinita con le sue credenziali di default (LocalSystem). Quindi il compito n. 1 sarebbe vedere se funzionasse effettivamente.

Ma qui è un abbozzo di come vorrei provare a farlo al di fuori di un contesto di servizio e si può vedere se si applica:

  1. Creare una finestra hook per messaggi trap da tutte le code finestre di messaggio su il sistema.
  2. Trap di tutti i messaggi WM_CREATE e sondare il parametro CREATESTRUCT per i messaggi che potrebbero essere originati dalla libreria di terze parti. Potrebbe essere necessario registrare tutti i messaggi WM_CREATE e quindi analizzare i dati per vedere come è possibile differenziare la finestra di dialogo della libreria da qualsiasi altra finestra di dialogo sul sistema. (Molte volte il membro "lpszName" differisce tra le implementazioni di dialogo)
  3. se si crede che il particolare WM_CREATE provenga dalla libreria, restituisca una risposta "gestita" dal proprio hook di messaggio e non chiami il successivo gestore di messaggi nella catena .

Questo è tutto molto rischioso, ma è il percorso che sembra abbia qualche possibilità per me.

Problemi correlati