Non ho trovato nulla di utile su MSDN per questo caso. Utilizzando Dependency Walker, nell'elenco dei moduli, vedo un uso misto di Console e GUI.Effetti del passaggio da/SUBSYSTEM: CONSOLE a/SUBSYSTEM: WINDOWS in una DLL
Questo ha un impatto durante la compilazione di una DLL?
Questa opzione ha effetto solo sulle applicazioni (exe), non sulle librerie (dll).
sua documentation dice:
L'opzione
/SUBSYSTEMspecifica l'ambiente per l'eseguibile.La scelta del sottosistema influisce sul simbolo del punto di ingresso (o sulla funzione del punto di ingresso ) selezionata dal programma di collegamento.
Questo non ha effetto sulle librerie, che hanno il proprio (opzionale) entry point.
Ulteriori informazioni a seguito del commento di CyberShadow: Il campo del sottosistema stesso sembra essere ignorato quando viene caricata una DLL. This article about CSRSS dice (sottolineatura mia):
Inoltre, ogni processo è associato ad uno, certo sottosistema; questa proprietà viene impostata dal linker (durante la compilazione processo), e si trova nel seguente campo struttura del PE: [...]
il flag/sottosistema è messo nel file di immagine - exe, dll , sys, .... dal linker quando si costruisce un'applicazione. Questo flag esiste ESPLORA ENTRO le immagini EXE e DLL! Dai un'occhiata alle impostazioni di Link Studio di Visual Studio -> Sottotipo – mox
Questo flag ha effetto su QUALSIASI file immagine. Date un'occhiata a molti \ system32 \ *. Dll (ad esempio NTDLL.DLL contrassegnato con/SUBSYSTEM: CONSOLE) – mox
@mox, tutti i file di immagine contengono questo flag, ma non influisce sul punto di ingresso delle librerie. Come puoi vedere, 'ntdll.dll' può essere caricato nello spazio degli indirizzi di entrambi gli eseguibili di console e Windows senza effetti negativi. –