Aiuto! Avrei bisogno urgente di un file .exe "che non faccia niente"...

[Violator]

Ho risolto, grazie soprattutto a 71104!

Scusate la banalità del problema e la mia ignoranza in materia, grazie a tutti per la pazienza e la disponibilità.

[franksisca]

Figurati e scusaci per le battute, ma almeno, con questo caldo soprattutto, cerchiamo di scerzare su ogni così, in modo da tirarci un pò su......CIAO

[tglman]

Posso fare un po di spam, per fare queste cose ho un piccolo manualino sul mio sito, e un pò inconpleto ma questo problema e ben risolto ;-).
Ciao.

[mjordan]

Originariamente inviato da 71104

#include <windows.h>

int APIENTRY WinMain(HINSTANCE hInstance,
	HINSTANCE hPrevInstance,
	LPSTR lpCmdLine,
	int nShowCmd)
{
	return 0;
}

Mamma quanta merda si deve scrivere per un programma Windows...

#include <gtk/gtk.h>

int
main(int argc, char ** argv)
{
         gtk_init(&argc, &argv);
         return 0;
}

Programma GUI con GTK+ che non fa niente.
Non mi meraviglio che i geni di Adobe abbiano abbandonato le MFC a favore delle QT.

[71104]

Originariamente inviato da mjordan

Mamma quanta merda si deve scrivere per un programma Windows...

il prototipo della WinMain sembra strano perché è dettato da ragioni storiche: ad esempio, in Win16 il secondo parametro, hPrevInstance, era il base address dell'ultima istanza caricata dello stesso eseguibile... completamente senza senso oggi, per almeno due motivi:
1) l'HINSTANCE (o HMODULE, che è la stessa cosa) rappresenta un base address, cioè prima di tutto un indirizzo; Windows 3.1 non aveva ne' le LDT ne' il paging, ma Windows NT e Windows 9x ce li hanno, quindi l'indirizzo hPrevInstance, che sarebbe il base address di un modulo di un altro processo, non è valido nel processo corrente;
2) Windows lo setta sempre a NULL (mi pare) perché quel sistema per avviare istanze singole dei programmi non viene più usato: per impedire che l'utente avvii due istanze di un programma oggi si usano i mutex.
abbastanza inutile anche il primo parametro, hInstance: dal momento che il primo modulo ad essere caricato in un nuovo processo è proprio l'eseguibile non c'è possibilità di rilocamento, (non ce n'è bisogno: il base address predefinito è sicuramente libero), quindi hInstance risulta sempre uguale al base address predefinito dell'eseguibile (in genere 0x400000).
e poi se vogliamo dirla tutta non vengono quasi mai usati nemmeno gli altri due parametri: per la command line molti frameworks Win32 usano GetCommandLine, e nShowCmd si trova nelle STARTUPINFO che si possono ritrovare con un'apposita funzione (ora non ricordo il nome).

[mjordan]

Originariamente inviato da 71104

il prototipo della WinMain sembra strano perché è dettato da ragioni storiche: ad esempio, in Win16 il secondo parametro, hPrevInstance, era il base address dell'ultima istanza caricata dello stesso eseguibile... completamente senza senso oggi, per almeno due motivi:
1) l'HINSTANCE (o HMODULE, che è la stessa cosa) rappresenta un base address, cioè prima di tutto un indirizzo; Windows 3.1 non aveva ne' le LDT ne' il paging, ma Windows NT e Windows 9x ce li hanno, quindi l'indirizzo hPrevInstance, che sarebbe il base address di un modulo di un altro processo, non è valido nel processo corrente;
2) Windows lo setta sempre a NULL (mi pare) perché quel sistema per avviare istanze singole dei programmi non viene più usato: per impedire che l'utente avvii due istanze di un programma oggi si usano i mutex.
abbastanza inutile anche il primo parametro, hInstance: dal momento che il primo modulo ad essere caricato in un nuovo processo è proprio l'eseguibile non c'è possibilità di rilocamento, (non ce n'è bisogno: il base address predefinito è sicuramente libero), quindi hInstance risulta sempre uguale al base address predefinito dell'eseguibile (in genere 0x400000).
e poi se vogliamo dirla tutta non vengono quasi mai usati nemmeno gli altri due parametri: per la command line molti frameworks Win32 usano GetCommandLine, e nShowCmd si trova nelle STARTUPINFO che si possono ritrovare con un'apposita funzione (ora non ricordo il nome).

Ma perchè portarsi dietro tutta questa spazzatura?
IMHO, già il solo fatto di cambiare la standardissima main() in WinMain() lo trovo deprimente

[71104]

probabilmente l'unico motivo era quello di mantenere un po' di compatibilità tra sorgenti a 16 bit e a 32 bit, in modo da facilitare un po' il porting quando nacque Win32. credo che alla fine per portare un sorgente da Win16 a Win32, bisognasse cambiare poche cose (infatti Win32 contiene un bel po' di nonsenses; è infestato da questi HINSTANCE, che spesso vengono completamente ignorati, come nelle Window Classes).

[mjordan]

Originariamente inviato da 71104

probabilmente l'unico motivo era quello di mantenere un po' di compatibilità tra sorgenti a 16 bit e a 32 bit, in modo da facilitare un po' il porting quando nacque Win32. credo che alla fine per portare un sorgente da Win16 a Win32, bisognasse cambiare poche cose (infatti Win32 contiene un bel po' di nonsenses; è infestato da questi HINSTANCE, che spesso vengono completamente ignorati, come nelle Window Classes).

Immagino cosa succeda ora che si passerà da win32 a win64...

[71104]

Originariamente inviato da mjordan

Immagino cosa succeda ora che si passerà da win32 a win64...

mah, non lo so perché non ho mai visto l'interfaccia di Win64, ma a dire il vero Microsoft sembra essersi rotta della backward compatibility: in Windows XP a 64 bit hanno fatto le peggio assurdità, Win16 è stato eliminato, i drivers a 32 bit non vanno più bene (winxp64 è povero di drivers)... da un eccesso all'altro

[mjordan]

Originariamente inviato da 71104

mah, non lo so perché non ho mai visto l'interfaccia di Win64, ma a dire il vero Microsoft sembra essersi rotta della backward compatibility: in Windows XP a 64 bit hanno fatto le peggio assurdità, Win16 è stato eliminato, i drivers a 32 bit non vanno più bene (winxp64 è povero di drivers)... da un eccesso all'altro

Da un cesso ad un altro
WOW. Forse Longhorn allora avrà nuove caratteristiche con 20 milioni di righe di codice in meno... Questa è magia...

[71104]

Originariamente inviato da mjordan

WOW

l'hai detto!

[Fenomeno85]

Originariamente inviato da mjordan

Da un cesso ad un altro
WOW. Forse Longhorn allora avrà nuove caratteristiche con 20 milioni di righe di codice in meno... Questa è magia...

Vista che poi che azzo di nome è ...cmq interessante le gtk ... hai una guida?

~§~ Sempre E Solo Lei ~§~

[DanieleC88]

Originariamente inviato da mjordan

Forse Longhorn allora avrà nuove caratteristiche con 20 milioni di righe di codice in meno... Questa è magia...

Quale Longhorn! Windows Vista!

Originariamente inviato da Fenomeno85

Vista che poi che azzo di nome è ...cmq interessante le gtk ... hai una guida?

~§~ Sempre E Solo Lei ~§~

http://www.gtk.org/
Lì c'è tutto!

[Fenomeno85]

Originariamente inviato da DanieleC88

Quale Longhorn! Windows Vista!

http://www.gtk.org/
Lì c'è tutto!

grazie

~§~ Sempre E Solo Lei ~§~

[^TiGeRShArK^]

Originariamente inviato da 71104

mah, non lo so perché non ho mai visto l'interfaccia di Win64, ma a dire il vero Microsoft sembra essersi rotta della backward compatibility: in Windows XP a 64 bit hanno fatto le peggio assurdità, Win16 è stato eliminato, i drivers a 32 bit non vanno più bene (winxp64 è povero di drivers)... da un eccesso all'altro

i driver devono girare x forza in kernel mode...
e dato ke il kernel è a 64 bit i driver dovevano essere x forza descritti.
Lo strato WOW 64 (Windows On Windows) x fare girare i programmi a 32 bit se nn sbaglio funziona infatti solo in user-mode.
Anke x questo motivo si sono dovuti riscrivere tutti i programmi quali gli antivirus.

[71104]

Originariamente inviato da ^TiGeRShArK^

i driver devono girare x forza in kernel mode...

ne esistono anche in user mode e probabilmente non funzionano più nemmeno quelli.

e dato ke il kernel è a 64 bit i driver dovevano essere x forza riscritti.

potevano impegnarsi di più per supportare i vecchi drivers... buona parte del "vecchio" codice kernel mode a 32 bit avrebbe funzionato lo stesso sul kernel a 64 bit (i processori a 64 bit sono comunque un sovrainsieme di quelli a 32).

[Mark0]

Arrivo in ritardo mostruoso ma tant'è... avevo preparto l'EXE, fatto l'upload ma poi mi sono dimenticato il post!
Cmq eccolo, anche se ormai non serve più: Null.EXE (5KB).

Bye!

[mjordan]

Sono sicuro che dentro c'è un bel worm

[Mark0]

Uno solo? :-?
E che cavolo, almeno 3 o 4!!

Bye!