[C++]Unire più file .exe

[cionci]

Originariamente inviato da cdimauro

Scusa, ma come hai fatto a "ridurre" CPU-Z e farlo diventare il "tuo" CPU View? Qualche conoscenza di programmazione dovresti averla, no?

Ha semplicemente usato un resource editor

Originariamente inviato da cdimauro

Fissato? Non mi pare. Più precisamente, non mi pare di aver pisciato fuori dal seminato, per così dire: non ho proposto Python per scrivere un s.o...

Io capisco che se uno chiede "voglio imparare a programmare, quale linguaggio posso usare?" tu gli risponda Python. E' una scelta valida come primo linguaggio.
Ma se uno chiede "Voglio imparare a programmare perché ho come obiettivo creare un programma che si interfaccia direttamente con l'hardware su SO Windows" sicuramente Python è l'ultima scelta nella mia lista e scommetto anche in quella di tutti gli altri che frequentano questa discussione. Prima ci sono C, C++ e tutti i linguaggi .Net.

Originariamente inviato da cdimauro

Se vuoi imparare a programmare, usa Python.

Perché, con gli altri linguaggi non si impara a programmare ? Magari (e non è detto) ci si mette di più, ma conta che se parte da Python dopo dovrebbe impararsi anche un altro linguaggio per eventualmente scriversi un driver, quindi alla fine dei conti la scelta Python è assolutamente deleteria, anche perché per passare da Python ad un linguaggio C-Style il passo è ben più complesso che passare da un linguaggio C-Style ad un altro.

[71104]

Originariamente inviato da Mazda RX8

a casa al momento ho un bel libro di C++, ke faccio??

vendilo a 75 euro

[Mazda RX8]

Lol!
Te lo vendo a te così mi fai il lavoro...

[cdimauro]

Originariamente inviato da Mazda RX8

beh, devo dire grazie a quei meravigliosi EDIT EXE ke mi han permesso di trafsormare e tradurre molti programmi (anke Cpu-Z)

Originariamente inviato da cionci

Ha semplicemente usato un resource editor

OK, tutto chiaro. Programmazione: zero.

Io capisco che se uno chiede "voglio imparare a programmare, quale linguaggio posso usare?" tu gli risponda Python. E' una scelta valida come primo linguaggio.
Ma se uno chiede "Voglio imparare a programmare perché ho come obiettivo creare un programma che si interfaccia direttamente con l'hardware su SO Windows" sicuramente Python è l'ultima scelta nella mia lista e scommetto anche in quella di tutti gli altri che frequentano questa discussione. Prima ci sono C, C++ e tutti i linguaggi .Net.

Avevo già detto che fra tutti i linguaggi .Net c'è pure IronPython: come la mettiamo?

Avevo anche detto che per recuperare le informazioni che gli servono sono già presenti librerie a cui è facilissimo interfacciarsi.

Aggiungo che la maggior parte del lavoro che dovrà fare sarà quello di presentare i dati.

Bastano come motivazioni?

Perché, con gli altri linguaggi non si impara a programmare ?

No, mai detto questo, lo sai.

Magari (e non è detto) ci si mette di più, ma conta che se parte da Python dopo dovrebbe impararsi anche un altro linguaggio per eventualmente scriversi un driver, quindi alla fine dei conti la scelta Python è assolutamente deleteria, anche perché per passare da Python ad un linguaggio C-Style il passo è ben più complesso che passare da un linguaggio C-Style ad un altro.

Scrivere un driver non è cosa affatto banale: richiede parecchia esperienza. Quando ne avrà abbastanza passare da un linguaggio a un altro (se proprio sarà necessario) sarà una bazzecola.

Ma... intanto deve partire, e con Python la partenza è molto comoda e moooolto meno traumatica rispetto a tanti altri linguaggi di programmazione.

[cionci]

Originariamente inviato da cdimauro

OK, tutto chiaro. Programmazione: zero.

Avevo già detto che fra tutti i linguaggi .Net c'è pure IronPython: come la mettiamo?

Che futuro può avere un linguaggio .Net non supportato da Microsoft ?

Originariamente inviato da cdimauro

Avevo anche detto che per recuperare le informazioni che gli servono sono già presenti librerie a cui è facilissimo interfacciarsi.

Aggiungo che la maggior parte del lavoro che dovrà fare sarà quello di presentare i dati.

Non credo assolutamente che gli bastino quei dati, se non sbaglio parlava anche di voltaggi.

Originariamente inviato da cdimauro

Scrivere un driver non è cosa affatto banale: richiede parecchia esperienza. Quando ne avrà abbastanza passare da un linguaggio a un altro (se proprio sarà necessario) sarà una bazzecola.

Passare da un linguaggio come Python ad un linguaggio C-Style è una bazzecola ? Non credo proprio.

Originariamente inviato da cdimauro

Ma... intanto deve partire, e con Python la partenza è molto comoda e moooolto meno traumatica rispetto a tanti altri linguaggi di programmazione.

Questo lo dici te. Per me è solo uno spreco di tempo ed è un linguaggio, per come la vedo io, assurdo.

[cionci]

Poi ritornando alla questione librerie: credi che non ci siano librerie equivalenti anche per C++ e C# ?

[cdimauro]

Originariamente inviato da cionci

Che futuro può avere un linguaggio .Net non supportato da Microsoft ?

Riccardo, MS ha INGAGGIATO il tizio che ha iniziato il porting di Python per .NET.

Il futuro per Python su .NET è a dir poco roseo: infatti è fra i linguaggi che MS supporta pienamente per SilverLight, ad esempio.

Non credo assolutamente che gli bastino quei dati, se non sbaglio parlava anche di voltaggi.

Sì, chiaro: per dati mi riferivo a tutti quelli che bisogna recuperare, e lo si può fare agevolmente con le librerie di cui parlavo (che si interfacciano col s.o. per ottenere i permessi di accesso alle porte di I/O, oppure per utilizzare istruzioni come CPUID).

Passare da un linguaggio come Python ad un linguaggio C-Style è una bazzecola ? Non credo proprio.

Se hai sufficiente esperienza per poter scrivere un driver, non vedo perché dovresti avere difficoltà.

Questo lo dici te. Per me è solo uno spreco di tempo ed è un linguaggio, per come la vedo io, assurdo.

Opinabile.

Originariamente inviato da cionci

Poi ritornando alla questione librerie: credi che non ci siano librerie equivalenti anche per C++ e C# ?

Mai detto questo, lo sai.

Le librerie servono a smazzarti un bel po' di lavoro per accedere a quelle informazioni, e chiaramente sono utili per qualunque linguaggio. Anche per Python, quindi, che sulla carta era dato per spacciato visto che per compiti come questi si lavora a livello molto basso.

[71104]

Originariamente inviato da cdimauro

Scrivere un driver non è cosa affatto banale: richiede parecchia esperienza. Quando ne avrà abbastanza passare da un linguaggio a un altro (se proprio sarà necessario) sarà una bazzecola.

scrivere un driver richiede parecchia esperienza in cose che non hanno nulla a che vedere con Python se non un misero 1% di concetti di base di programmazione (variabili, funzioni, statements...); richiede esperienza invece con gli internals del sistema operativo, e adesso non venirmi a cantare che per imparare quelli sarebbe molto più comodo partire con Python, con tutta la documentazione MSDN del kernel che ti presenta prototipi e strutture in C brutto, crudele e pieno di macro

[cionci]

Originariamente inviato da 71104

scrivere un driver richiede parecchia esperienza in cose che non hanno nulla a che vedere con Python se non un misero 1% di concetti di base di programmazione (variabili, funzioni, statements...); richiede esperienza invece con gli internals del sistema operativo, e adesso non venirmi a cantare che per imparare quelli sarebbe molto più comodo partire con Python, con tutta la documentazione MSDN del kernel che ti presenta prototipi e strutture in C brutto, cattivo e pieno di macro

Appunto

[fek]

Originariamente inviato da cionci

Che futuro può avere un linguaggio .Net non supportato da Microsoft ?

IronPython (purtroppo) e' molto supportato da Microsoft.

[cionci]

Originariamente inviato da fek

IronPython (purtroppo) e' molto supportato da Microsoft.

Ci sta circondando

[cdimauro]

Originariamente inviato da 71104

scrivere un driver richiede parecchia esperienza in cose che non hanno nulla a che vedere con Python se non un misero 1% di concetti di base di programmazione (variabili, funzioni, statements...); richiede esperienza invece con gli internals del sistema operativo, e adesso non venirmi a cantare che per imparare quelli sarebbe molto più comodo partire con Python, con tutta la documentazione MSDN del kernel che ti presenta prototipi e strutture in C brutto, crudele e pieno di macro

1) L'esperienza con gli "internal" te la puoi fare DOPO che sarai diventato un ottimo programmatore.

2) Un ottimo programmatore può passare da Python a qualunque altro linguaggio (compreso quello schifo di C), e viceversa.

3) Per diventare un ottimo programmatore devi prima imparare a programmare, e farti le ossa.

Chiaro?

[cionci]

Originariamente inviato da cdimauro

1) L'esperienza con gli "internal" te la puoi fare DOPO che sarai diventato un ottimo programmatore.

2) Un ottimo programmatore può passare da Python a qualunque altro linguaggio (compreso quello schifo di C), e viceversa.

3) Per diventare un ottimo programmatore devi prima imparare a programmare, e farti le ossa.

Chiaro?

Se vuoi triplicare il tempo per arrivare al tuo obiettivo, sicuramente

[cdimauro]

Originariamente inviato da fek

IronPython (purtroppo) e' molto supportato da Microsoft.

Originariamente inviato da cionci

Ci sta circondando

Rassegnatevi: sarete assimilati.

P.S. Buonanotte a tutti.

Originariamente inviato da cionci

Se vuoi triplicare il tempo per arrivare al tuo obiettivo sicuramente

Coi segmentation fault, i double delete, ecc. ne perderai molto di più.

[cionci]

Originariamente inviato da cdimauro

Rassegnatevi: sarete assimilati.

Escono dalle fottute pareti !!! (cit.)

Notte

[fek]

Originariamente inviato da cdimauro

Rassegnatevi: sarete assimilati.

Non credo finche' avro' un po' di senso critico.
Cesare, ormai consigli Python per tutto e questo dovrebbe farti suonare un campanello d'allarme. E' come se consigliassi di usare sempre un martello perche' ti ci trovi bene a piantare chiodi. Ma se provi a tagliartici le unghie dei piedi ti fai male

[cionci]

Originariamente inviato da cdimauro

Coi segmentation fault, i double delete, ecc. ne perderai molto di più.

Infatti ho consigliato C#

[morskott]

Originariamente inviato da cionci

Infatti ho consigliato C#

C# o Java, due ottime basi per imparare a programmare.
Basi fatte poi su 2 linguaggi molto potenti.
Senza scatenare flames io consiglierei a tutti di iniziare o con uno o con l'altro.

[71104]

Originariamente inviato da cdimauro

1) L'esperienza con gli "internal" te la puoi fare DOPO che sarai diventato un ottimo programmatore.

2) Un ottimo programmatore può passare da Python a qualunque altro linguaggio (compreso quello schifo di C), e viceversa.

3) Per diventare un ottimo programmatore devi prima imparare a programmare, e farti le ossa.

non capisco ora come sia saltata fuori questa cosa dell'ottimo programmatore, comunque:

1) non hai la minima idea delle proporzioni dei vari tratti della curva d'apprendimento; se per imparare a programmare in paradigma procedurale basta una settimana, per imparare a scrivere drivers sensati e che non diano schermata blu appena caricati... ma che dico, anche solo per caricare un driver nel kernel di Windows, servono un paio d'anni; se credi che sia un'esagerazione ti sbagli.

viste le proporzioni ed ipotizzando un niubbo (cioè uno a digiuno totale) che si ponga come obiettivo la realizzazione di un driver funzionante, consigliare di partire da Python è completamente fuor di luogo, è un allungamento inutile dei tempi; gli stai consigliando di imparare qualcosa che non gli servirà e che si potrebbe forse identificare come ciò che tu definisci l' "essere un ottimo programmatore".

2, 3) embè?

Chiaro?

chiarissimo: non hai mai scritto drivers per Windows.
(e ora mi spara "per Windows no, ma su <esotica architettura anni '70 di un mondo che non c'è più, stile bus dati a 4 bit> programmavo col generatore di segnali digitali: davo in input uni e zeri e costruivo man mano gli opcode del codice macchina ")

Originariamente inviato da cionci

Se vuoi triplicare il tempo per arrivare al tuo obiettivo, sicuramente

era per questo che l'ha diviso in 3 punti

[71104]

Originariamente inviato da cdimauro

Coi segmentation fault, i double delete, ecc. ne perderai molto di più.

un driver è un programma strano: è totamente privo di logica se non per un paio (a dir proprio tanto) d'algoritmi che può capitare di dover implementare in qualche routine e che sono descritti passo passo su MSDN in una maniera a prova di deficiente (praticamente leggi la descrizione del codice in inglese: "chiama questo passandogli questo e quest'altro, chiama quell'altro..."). un driver è solo un sacco di entry points che ti vengono chiamati e all'interno dei quali devi fare determinate cose, dettagliatamente descritte nello stile di cui sopra.

stando così le cose i segmentation fault e le doppie delete sono praticamente impossibili, purché al programmatore sia chiaro quale routine di deallocazione vada associata a quale routine di allocazione (e questo Python non te lo insegna).