Discussione:
Modern UI e interfaccia Classica
(troppo vecchio per rispondere)
Bracco Baldo
2013-08-15 20:45:53 UTC
Permalink
Ho letto che su Windows 8 sono disponibili DUE interfacce grafiche,
la nuova interfaccia "Modern UI" (ex "Metro") e una interfaccia simile
alle interfaccie delle versioni precedenti (chiamiamola interfaccia
"Classica").

I programmi scritti per l'interfaccia Classica funzionano, oltre che su
Windows 8, ANCHE su Windows 7, Windows Vista e Windows XP?

Mentre invece i programmi per la Modern UI funzionano SOLO su Windows 8?
enoquick
2013-08-15 20:51:06 UTC
Permalink
Post by Bracco Baldo
Ho letto che su Windows 8 sono disponibili DUE interfacce grafiche,
la nuova interfaccia "Modern UI" (ex "Metro") e una interfaccia simile
alle interfaccie delle versioni precedenti (chiamiamola interfaccia
"Classica").
I programmi scritti per l'interfaccia Classica funzionano, oltre che su
Windows 8, ANCHE su Windows 7, Windows Vista e Windows XP?
Mentre invece i programmi per la Modern UI funzionano SOLO su Windows 8?
Non credo che debba parlare tanto di interfaccia grafica quanto di API
Se le API usate da un applicativo, anche sotto Modern UI, usa le stesse
API di windows 7,Vista e XP allora non dovrebbero esserci problemi
Se usa nuove API allora,come è ovvio, l' applicativo non puo girare
sugli OS di versioni precedenti
Raffaele Rialdi [MVP]
2013-08-16 12:37:37 UTC
Permalink
Post by enoquick
Non credo che debba parlare tanto di interfaccia grafica quanto di API
Se le API usate da un applicativo, anche sotto Modern UI, usa le stesse API
di windows 7,Vista e XP allora non dovrebbero esserci problemi
Se usa nuove API allora,come è ovvio, l' applicativo non puo girare sugli OS
di versioni precedenti
Gli applicativi "Windows Store" o "Modern UI" girano in una sandbox per
cui non è solo una questione di API.

Per fare degli esempi:
- le app nuove sono installate via package, non disponibile in Win7.
Ergo l'installazione non è mai compatibile

- l'exe contenuto dentro il package deve usare il Windows Runtime che
non è disponibile in Win7, ergo l'exe non è riutilizzabile as-is

- le dll contenute dentro il package possono essere di diverso tipo:
* .NET. Funzionano solo se sono confezionate come "portable class
library" che supportano entrambi i mondi
* API C. Funzionano su Win7 se le API usate sono quelle esistenti in
Win7. Attenzione che le Win8Apps possono usare un subset delle Win32
per motivi di sicurezza. MSDN riporta su ciascuna API dove è usabile.
* COM. Vedi punto precedente per le API. In più il componente deve
essere "registration free" (opzione disponibile dal 2005) che non
richiede regsvr32.

Alcune parti di WinRT sono usabili anche nel desktop (di Win8). Tutto
ciò che è UI è escluso, grosse porzioni del restante sono usabili.



Per dovere di cronaca, le App Win8 sono, per dirla in due parole, dei
COM server evoluti. Vengono attivati e dialogano con l'OS e con le
altre app via interfacce.
Il nuovo COM si chiama WinRT e ha super-semplificato lo sviluppo
cambiando tutto il type system e il modo di interoperare con i
linguaggi.
--
Raffaele Rialdi http://www.iamraf.net
Weblog: http://blogs.ugidotnet.org/raffaele
Microsoft MVP profile
https://mvp.support.microsoft.com/profile/raffaele
UGIdotNET - http://www.ugidotnet.org/
enoquick
2013-08-16 14:28:54 UTC
Permalink
Post by Raffaele Rialdi [MVP]
Post by enoquick
Non credo che debba parlare tanto di interfaccia grafica quanto di API
Se le API usate da un applicativo, anche sotto Modern UI, usa le
stesse API di windows 7,Vista e XP allora non dovrebbero esserci problemi
Se usa nuove API allora,come è ovvio, l' applicativo non puo girare
sugli OS di versioni precedenti
Gli applicativi "Windows Store" o "Modern UI" girano in una sandbox per
cui non è solo una questione di API.
Non credo che sia un obbligo usare una sandbox
Se lo fosse occorre portare anche la sandbox in win7 e xp
Post by Raffaele Rialdi [MVP]
- le app nuove sono installate via package, non disponibile in Win7.
Ergo l'installazione non è mai compatibile
Va bene,ma qui non si parla di installazione
Si spacca il package e si fa una installazione manuale
Post by Raffaele Rialdi [MVP]
- l'exe contenuto dentro il package deve usare il Windows Runtime che
non è disponibile in Win7, ergo l'exe non è riutilizzabile as-is
Il windows runtime è un componente lui stesso ed una volta caricato l'
applicativo in memoria diventa una estensione dell' applicativo
Quindi, lascio stare la dizione applicativo che non è appropriata e
passiamo al momento dell' esecuzione
A questo punto abbiamo un processo e se lui stesso usa le vecchie API
teoricamente potrebbe girare
Dubito comunque che Windows Runtime usi solo vecchie API
Post by Raffaele Rialdi [MVP]
* .NET. Funzionano solo se sono confezionate come "portable class
win7 e XP supportano .NET
Chiaramente anche qui vale lo stesso discorso delle API
Occorre una compatibilità di API .NET,meglio ancora la stessa versione
di .NET
Post by Raffaele Rialdi [MVP]
library" che supportano entrambi i mondi
* API C. Funzionano su Win7 se le API usate sono quelle esistenti in
Win7.
OK

Attenzione che le Win8Apps possono usare un subset delle Win32 per
Post by Raffaele Rialdi [MVP]
motivi di sicurezza.
Va bene, non è obbligatorio usarle tutte
Ma a questo punto mi chiedo,in win7 e precedenti si possono usare API
insicure ?

MSDN riporta su ciascuna API dove è usabile.
Post by Raffaele Rialdi [MVP]
* COM. Vedi punto precedente per le API. In più il componente deve
essere "registration free" (opzione disponibile dal 2005) che non
richiede regsvr32.
I COM esistono anche in win7 e XP, anche qui deve esistere la compatibilità
Post by Raffaele Rialdi [MVP]
Alcune parti di WinRT sono usabili anche nel desktop (di Win8). Tutto
ciò che è UI è escluso, grosse porzioni del restante sono usabili.
OK
Post by Raffaele Rialdi [MVP]
Per dovere di cronaca, le App Win8 sono, per dirla in due parole, dei
COM server evoluti. Vengono attivati e dialogano con l'OS e con le altre
app via interfacce.
Il nuovo COM si chiama WinRT e ha super-semplificato lo sviluppo
cambiando tutto il type system e il modo di interoperare con i linguaggi.
Del windows runtime ho già parlato

Riassunto:
In pratica un lavoraccio
Raffaele Rialdi [MVP]
2013-08-16 16:13:37 UTC
Permalink
Post by enoquick
Non credo che sia un obbligo usare una sandbox
Se lo fosse occorre portare anche la sandbox in win7 e xp
Tutte le app "Modern UI" (quelle full screen win8) possono solo girare
nella sandbox.
Il Windows Runtime non è trasportabile su altri OS perché è parte di
Windows. Il fatto che usa direttamente i servizi del kernel è uno dei
motivi per cui non è portabile.
Post by enoquick
Va bene,ma qui non si parla di installazione
Si spacca il package e si fa una installazione manuale
Non girerebbe comunque, oltre al fatto che le risorse contenute nel
package non sono riferite per folder locale ma per Uri ms-appx://
Post by enoquick
Il windows runtime è un componente lui stesso ed una volta caricato l'
applicativo in memoria diventa una estensione dell' applicativo
Il Windows Runtime non è un componente ma una infrastruttura composta
da core services e librerie.
Il runtime usa diversi processi a contorno che vengono usati dalle
applicazioni come broker.
Post by enoquick
Quindi, lascio stare la dizione applicativo che non è appropriata e passiamo
al momento dell' esecuzione
A questo punto abbiamo un processo e se lui stesso usa le vecchie API
teoricamente potrebbe girare
Dubito comunque che Windows Runtime usi solo vecchie API
Ripeto, non è solo una questione di API ma il fatto che WinRT è parte
integrante di Win8.
Oltre al fatto che è legato al kernel di Win8, in qualsiasi caso i
componenti di sistema non possono essere copiati per motivi legali.
Post by enoquick
win7 e XP supportano .NET
Chiaramente anche qui vale lo stesso discorso delle API
Occorre una compatibilità di API .NET,meglio ancora la stessa versione di
.NET
Ripeto, non è solo una questione di API.
Le Portable Class Library sono state fatte apposta per questo scopo.
Per esempio la INotifyPropertyChanged di WinRT è, come tutto il codice
WinRT, nativo (C++). Quando si crea una applicazione .NET per Win8
vengono generati in automatico dei wrapper che rimappano quella
interfaccia su quella .NET. Questo meccanismo si chiama Projection e
ovviamente fa molto di più (rimappa il type system etc. etc.).
Ergo la DLL deve essere differente affinché il CLR possa sapere se sono
necessarie le projection o meno.
Post by enoquick
Va bene, non è obbligatorio usarle tutte
Ma a questo punto mi chiedo,in win7 e precedenti si possono usare API
insicure ?
forse non ho capito la domanda, ma in Win7 non è cambiato nulla. Le API
sono sempre quelle e da desktop sono 'insicure' by design.
Le App nuove Win8 hanno limitato le API in modo da evitare che una app
possa danneggiare altre app, il sistema operativo o il profilo utente.
Questo è il motivo per la sandbox.
Post by enoquick
I COM esistono anche in win7 e XP, anche qui deve esistere la compatibilità
Si purché:
- siano prive di registrazione regsvr32 ("registration free")
- usino solo API Win32/COM che siano tra quelle ammesse per le app win8
--
Raffaele Rialdi http://www.iamraf.net
Weblog: http://blogs.ugidotnet.org/raffaele
Microsoft MVP profile
https://mvp.support.microsoft.com/profile/raffaele
UGIdotNET - http://www.ugidotnet.org/
enoquick
2013-08-16 16:53:30 UTC
Permalink
Post by Raffaele Rialdi [MVP]
Post by enoquick
Non credo che sia un obbligo usare una sandbox
Se lo fosse occorre portare anche la sandbox in win7 e xp
Tutte le app "Modern UI" (quelle full screen win8) possono solo girare
nella sandbox.
La sandbox è un applicativo come un altro, basterebbe portare quello,
come ho scritto
Post by Raffaele Rialdi [MVP]
Il Windows Runtime non è trasportabile su altri OS perché è parte di
Windows. Il fatto che usa direttamente i servizi del kernel è uno dei
motivi per cui non è portabile.
Infatti avevo fatto l' ipotesi che il windows runtime usasse le API
compatibili con i vecchi windows
Post by Raffaele Rialdi [MVP]
Post by enoquick
Va bene,ma qui non si parla di installazione
Si spacca il package e si fa una installazione manuale
Non girerebbe comunque, oltre al fatto che le risorse contenute nel
package non sono riferite per folder locale ma per Uri ms-appx://
Terribile
Post by Raffaele Rialdi [MVP]
Post by enoquick
Il windows runtime è un componente lui stesso ed una volta caricato l'
applicativo in memoria diventa una estensione dell' applicativo
Il Windows Runtime non è un componente ma una infrastruttura composta da
core services e librerie.
Il runtime usa diversi processi a contorno che vengono usati dalle
applicazioni come broker.
Quando ho parlato di componente non intendevo certo un sistema monolitico
Post by Raffaele Rialdi [MVP]
Post by enoquick
Quindi, lascio stare la dizione applicativo che non è appropriata e
passiamo al momento dell' esecuzione
A questo punto abbiamo un processo e se lui stesso usa le vecchie API
teoricamente potrebbe girare
Dubito comunque che Windows Runtime usi solo vecchie API
Ripeto, non è solo una questione di API ma il fatto che WinRT è parte
integrante di Win8.
Oltre al fatto che è legato al kernel di Win8, in qualsiasi caso i
componenti di sistema non possono essere copiati per motivi legali.
Quando un applicativo diventa processo usa solo API verso il kernel,
niente altro a parte i dati di configurazione
IL discorso è puramente tecnico, lasciamo stare le questioni legali
Post by Raffaele Rialdi [MVP]
Post by enoquick
win7 e XP supportano .NET
Chiaramente anche qui vale lo stesso discorso delle API
Occorre una compatibilità di API .NET,meglio ancora la stessa versione
di .NET
Ripeto, non è solo una questione di API.
Le Portable Class Library sono state fatte apposta per questo scopo.
Per esempio la INotifyPropertyChanged di WinRT è, come tutto il codice
WinRT, nativo (C++). Quando si crea una applicazione .NET per Win8
vengono generati in automatico dei wrapper che rimappano quella
interfaccia su quella .NET. Questo meccanismo si chiama Projection e
ovviamente fa molto di più (rimappa il type system etc. etc.).
Ergo la DLL deve essere differente affinché il CLR possa sapere se sono
necessarie le projection o meno.
Questo è un grosso ostacolo
Post by Raffaele Rialdi [MVP]
Post by enoquick
Va bene, non è obbligatorio usarle tutte
Ma a questo punto mi chiedo,in win7 e precedenti si possono usare API
insicure ?
forse non ho capito la domanda, ma in Win7 non è cambiato nulla. Le API
sono sempre quelle e da desktop sono 'insicure' by design.
Quindi confermi che in win7 si possono usare API insicure
Ad esempio gli hook verso altre applicazioni pur girando tutte a livello
di ugual privilegi e permessi,se ho capito bene
Post by Raffaele Rialdi [MVP]
Le App nuove Win8 hanno limitato le API in modo da evitare che una app
possa danneggiare altre app, il sistema operativo o il profilo utente.
Questo è il motivo per la sandbox.
Non poteva essere che cosi, altrimenti a cosa servirebbe una sandbox ?
Post by Raffaele Rialdi [MVP]
Post by enoquick
I COM esistono anche in win7 e XP, anche qui deve esistere la
compatibilità
- siano prive di registrazione regsvr32 ("registration free")
- usino solo API Win32/COM che siano tra quelle ammesse per le app win8
Ovviamente
Raffaele Rialdi [MVP]
2013-08-16 20:23:24 UTC
Permalink
La sandbox è un applicativo come un altro, basterebbe portare quello, come ho
scritto
La sandbox non è un applicativo ma una modalità usata dal sistema
operativo per diminuire i privilegi di un processo. Sono cose molto
diverse.
Il processo di una App Win8 gira con privilegi più bassi (Integrity
Level a low tanto per fare un esempio) che impedisce al codice
dell'applicazione, anche se nativo, di poter leggere/scrivere al di
fuori di quanto gli viene concesso. Quindi ristretto l'accesso al file
system, alla rete, al registro, etc.
Questo richiede che il security subsystem (kernel) del sistema
operativo.
Infatti avevo fatto l' ipotesi che il windows runtime usasse le API
compatibili con i vecchi windows
Ripeto, non basta portare le API perché l'infrastruttura necessaria è
parte del sistema operativo.
Terribile
De gustibus. La scelta mi piace perché evita di dover riferire a
percorsi su disco che è limitativo visto che un singolo file può
contenere più risorse.
Quando un applicativo diventa processo usa solo API verso il kernel, niente
altro a parte i dati di configurazione
IL discorso è puramente tecnico, lasciamo stare le questioni legali
API che richiedono delle condizioni al contorno (formato del token,
integrity level, process flags, etc.) che sono strettamente dipendenti
dalla versione del sistema operativo che le supporta.
Se fosse solo questione di API, il sistema operativo non farebbe
differenza tra XP e Win7 mentre non è così a livello di architettura
dell'OS.
Questo è un grosso ostacolo
Ci sono motivi dietro a questa scelta che richiedono molto tempo per
essere spiegati nel dettaglio.
Quindi confermi che in win7 si possono usare API insicure
Ad esempio gli hook verso altre applicazioni pur girando tutte a livello di
ugual privilegi e permessi,se ho capito bene
In Win7 e anche in Win8 (modalità desktop) nulla è cambiato riguardo
alle API classiche. Quello che può fare un processo dipende ovviamente
dipendono dal contesto di sicurezza in cui girano (token).
Non poteva essere che cosi, altrimenti a cosa servirebbe una sandbox ?
:)
--
Raffaele Rialdi http://www.iamraf.net
Weblog: http://blogs.ugidotnet.org/raffaele
Microsoft MVP profile
https://mvp.support.microsoft.com/profile/raffaele
UGIdotNET - http://www.ugidotnet.org/
enoquick
2013-08-16 21:05:51 UTC
Permalink
Post by Raffaele Rialdi [MVP]
Post by enoquick
La sandbox è un applicativo come un altro, basterebbe portare quello,
come ho scritto
La sandbox non è un applicativo ma una modalità usata dal sistema
operativo per diminuire i privilegi di un processo. Sono cose molto
diverse.
Il processo di una App Win8 gira con privilegi più bassi (Integrity
Level a low tanto per fare un esempio) che impedisce al codice
dell'applicazione, anche se nativo, di poter leggere/scrivere al di
fuori di quanto gli viene concesso. Quindi ristretto l'accesso al file
system, alla rete, al registro, etc.
Questo richiede che il security subsystem (kernel) del sistema operativo.
OK, non avendo win8 e non interessandomi più di tanto degli ambienti
win32/64 pur conoscendo dai vecchi tempi l' architettura win32/64 non
sapevo questo
Ma queste cose,la diminuzione dei privilegi di un processo esistono
anche in seven e xp, se ricordo bene
Un sandbox simile a quella di win8 credo sia possibile,teoricamente,
ingegnerizzarla
Chiaramente il porting diventa ancora più difficoltoso
Post by Raffaele Rialdi [MVP]
Post by enoquick
Infatti avevo fatto l' ipotesi che il windows runtime usasse le API
compatibili con i vecchi windows
Ripeto, non basta portare le API perché l'infrastruttura necessaria è
parte del sistema operativo.
Post by enoquick
Terribile
De gustibus. La scelta mi piace perché evita di dover riferire a
percorsi su disco che è limitativo visto che un singolo file può
contenere più risorse.
Non mi riferivo a quello che hai spiegato
Pensavo semplicemente al porting
Post by Raffaele Rialdi [MVP]
Post by enoquick
Quando un applicativo diventa processo usa solo API verso il kernel,
niente altro a parte i dati di configurazione
IL discorso è puramente tecnico, lasciamo stare le questioni legali
API che richiedono delle condizioni al contorno (formato del token,
integrity level, process flags, etc.) che sono strettamente dipendenti
dalla versione del sistema operativo che le supporta.
Allora in questo in questo caso non esiste portabilità di API
Converrai con me che per avere portabilità occorre che il comportamento
e l' interfaccia pubblica deve essere compatibile con il regresso
Post by Raffaele Rialdi [MVP]
Se fosse solo questione di API, il sistema operativo non farebbe
differenza tra XP e Win7 mentre non è così a livello di architettura
dell'OS.
Non è una questione di API in se
E' una scelta tecnica
M$ ha semplicemente scelto di rompere alcune compatibilità con il
passato ed in questo modo il comportamento di alcune API non è rimasto
uguale
Chiaramente sto parlando tra XP e win7
Post by Raffaele Rialdi [MVP]
Post by enoquick
Questo è un grosso ostacolo
Ci sono motivi dietro a questa scelta che richiedono molto tempo per
essere spiegati nel dettaglio.
Post by enoquick
Quindi confermi che in win7 si possono usare API insicure
Ad esempio gli hook verso altre applicazioni pur girando tutte a
livello di ugual privilegi e permessi,se ho capito bene
In Win7 e anche in Win8 (modalità desktop) nulla è cambiato riguardo
alle API classiche. Quello che può fare un processo dipende ovviamente
dipendono dal contesto di sicurezza in cui girano (token).
Se ho ben capito hanno solo aggiunto un nuovo subsystem* per gli
applicativi win8

* I subsystem in windows fino a win7 sono gli ambienti win32/64 e posix
Post by Raffaele Rialdi [MVP]
Post by enoquick
Non poteva essere che cosi, altrimenti a cosa servirebbe una sandbox ?
:)
Ricambio:

:)
Raffaele Rialdi [MVP]
2013-08-16 21:32:55 UTC
Permalink
OK, non avendo win8 e non interessandomi più di tanto degli ambienti win32/64
pur conoscendo dai vecchi tempi l' architettura win32/64 non sapevo questo
Ma queste cose,la diminuzione dei privilegi di un processo esistono anche in
seven e xp, se ricordo bene
Un sandbox simile a quella di win8 credo sia possibile,teoricamente,
ingegnerizzarla
Chiaramente il porting diventa ancora più difficoltoso
In XP non c'era nulla.
In Vista sono arrivati gli Integrity Level che permettono una parte di
Sandbox e il doppio token
In Win7 sostanzialmente è rimasto quanto c'era già in Vista
In Win8 il token è cresciuto parecchio aggiungendo le capabilities, i
SID per App e diverse altre cose. Inoltre a livello kernel è stata
aggiunta parecchia infrastruttura per blindare di più la sandbox.
Inoltre il processo di Win8, ma solo per le Win8App ha uno stato in più
nel quale non consuma CPU (sospensione).

Nel token di Win8 ho anche trovato cose relative ai device ma ancora
non sono documentate. Sembrerebbe un modo per legare una app ad uno
specifico device.
Allora in questo in questo caso non esiste portabilità di API
Converrai con me che per avere portabilità occorre che il comportamento e l'
interfaccia pubblica deve essere compatibile con il regresso
La portabilità dipende come sempre da interfaccia e contesto. Il
contesto di sicurezza e di processo sono cambiati parecchio e quindi la
faccenda è più complessa.
Non è una questione di API in se
E' una scelta tecnica
M$ ha semplicemente scelto di rompere alcune compatibilità con il passato ed
in questo modo il comportamento di alcune API non è rimasto uguale
Chiaramente sto parlando tra XP e win7
XP e Win7 (ma già Vista) sono abissalmente diversi dal punto di vista
architetturale, una vera rivoluzione.
Più che rottura di cose esistenti ci sono tantissime novità (sessione
0, doppio token, IL, oltre all'aggiunta di nuovi algoritmi di crypto, e
molto altro). D'altra parte sono passati 12 anni e meno male che quelle
cose sono arrivate. Speravo anche di più personalmente.
Se ho ben capito hanno solo aggiunto un nuovo subsystem* per gli applicativi
win8
* I subsystem in windows fino a win7 sono gli ambienti win32/64 e posix
No, non è un subsystem. Girano sempre nel subsystem Win32/64. Ma il
processo sandboxed è chiamato AppContainer e ha un trattamento
particolare a livello kernel.
:)
:))
--
Raffaele Rialdi http://www.iamraf.net
Weblog: http://blogs.ugidotnet.org/raffaele
Microsoft MVP profile
https://mvp.support.microsoft.com/profile/raffaele
UGIdotNET - http://www.ugidotnet.org/
enoquick
2013-08-16 21:59:40 UTC
Permalink
Post by Raffaele Rialdi [MVP]
Post by enoquick
OK, non avendo win8 e non interessandomi più di tanto degli ambienti
win32/64 pur conoscendo dai vecchi tempi l' architettura win32/64 non
sapevo questo
Ma queste cose,la diminuzione dei privilegi di un processo esistono
anche in seven e xp, se ricordo bene
Un sandbox simile a quella di win8 credo sia possibile,teoricamente,
ingegnerizzarla
Chiaramente il porting diventa ancora più difficoltoso
In XP non c'era nulla.
In Vista sono arrivati gli Integrity Level che permettono una parte di
Sandbox e il doppio token
In Win7 sostanzialmente è rimasto quanto c'era già in Vista
In Win8 il token è cresciuto parecchio aggiungendo le capabilities, i
SID per App e diverse altre cose. Inoltre a livello kernel è stata
aggiunta parecchia infrastruttura per blindare di più la sandbox.
OK
Post by Raffaele Rialdi [MVP]
Inoltre il processo di Win8, ma solo per le Win8App ha uno stato in più
nel quale non consuma CPU (sospensione).
La sospensione esiste anche in win7
Qui è stata ampliata ad un singolo processo, se è ho capito
Post by Raffaele Rialdi [MVP]
Nel token di Win8 ho anche trovato cose relative ai device ma ancora non
sono documentate. Sembrerebbe un modo per legare una app ad uno
specifico device.
OK
Post by Raffaele Rialdi [MVP]
Post by enoquick
Allora in questo in questo caso non esiste portabilità di API
Converrai con me che per avere portabilità occorre che il
comportamento e l' interfaccia pubblica deve essere compatibile con il
regresso
La portabilità dipende come sempre da interfaccia e contesto. Il
contesto di sicurezza e di processo sono cambiati parecchio e quindi la
faccenda è più complessa.
OK
Post by Raffaele Rialdi [MVP]
Post by enoquick
Non è una questione di API in se
E' una scelta tecnica
M$ ha semplicemente scelto di rompere alcune compatibilità con il
passato ed in questo modo il comportamento di alcune API non è rimasto
uguale
Chiaramente sto parlando tra XP e win7
XP e Win7 (ma già Vista) sono abissalmente diversi dal punto di vista
architetturale, una vera rivoluzione.
Più che rottura di cose esistenti ci sono tantissime novità (sessione 0,
doppio token, IL, oltre all'aggiunta di nuovi algoritmi di crypto, e
molto altro). D'altra parte sono passati 12 anni e meno male che quelle
cose sono arrivate. Speravo anche di più personalmente.
OK, le novità sono quelle che sono
E' ovvio che le nuove API non possono essere usate, a meno di riuscire
ad emularle, su un vecchio sistema
Post by Raffaele Rialdi [MVP]
Post by enoquick
Se ho ben capito hanno solo aggiunto un nuovo subsystem* per gli
applicativi win8
* I subsystem in windows fino a win7 sono gli ambienti win32/64 e posix
No, non è un subsystem. Girano sempre nel subsystem Win32/64. Ma il
processo sandboxed è chiamato AppContainer e ha un trattamento
particolare a livello kernel.
Chiaro tranne questo, sandboxes è un processo o no ?
Precedentemente avevi affermato che era solo una modalità per diminuire
i privilegi di un processo
Post by Raffaele Rialdi [MVP]
Post by enoquick
:)
:))
Se andiamo avanti a faccine poi riempiamo la pagina
Saluti
Raffaele Rialdi [MVP]
2013-08-17 07:55:51 UTC
Permalink
Post by enoquick
La sospensione esiste anche in win7
Qui è stata ampliata ad un singolo processo, se è ho capito
Si, è una cosa molto diversa.
La sospensione dell'intero OS viene fatta con gli stati S della CPU.
Qui invece il processo ha un nuovo stato di "Suspended" che non consuma
CPU.
I processi attivi hanno sempre un minimo consumo che si può vedere dal
task manager. Per queste nuove App il ciclo di vita è cambiato per
minimizzare il consumo di batteria sui device.
Post by enoquick
OK, le novità sono quelle che sono
E' ovvio che le nuove API non possono essere usate, a meno di riuscire ad
emularle, su un vecchio sistema
Buona fortuna a chi ci prova :)
Post by enoquick
Chiaro tranne questo, sandboxes è un processo o no ?
Precedentemente avevi affermato che era solo una modalità per diminuire i
privilegi di un processo
La sandbox è una condizione applicata al processo o meglio il contesto
in cui gira.
Se guardi la lista dei processi, troverai sempre e solo il processo
dell'applicazione, ma quell'applicazione è marcata in modo speciale
"AppContainer" e viene trattata dal sistema in modo diverso dalle
applicazioni desktop classiche.
Post by enoquick
Se andiamo avanti a faccine poi riempiamo la pagina
Saluti
LOL, ciao
--
Raffaele Rialdi http://www.iamraf.net
Weblog: http://blogs.ugidotnet.org/raffaele
Microsoft MVP profile
https://mvp.support.microsoft.com/profile/raffaele
UGIdotNET - http://www.ugidotnet.org/
Raffaele Rialdi [MVP]
2013-08-16 12:39:04 UTC
Permalink
Post by Bracco Baldo
Ho letto che su Windows 8 sono disponibili DUE interfacce grafiche,
la nuova interfaccia "Modern UI" (ex "Metro") e una interfaccia simile
alle interfaccie delle versioni precedenti (chiamiamola interfaccia
"Classica").
I programmi scritti per l'interfaccia Classica funzionano, oltre che su
Windows 8, ANCHE su Windows 7, Windows Vista e Windows XP?
Se parliamo solo di mondo desktop (interfaccia classica), purché le API
usate siano disponibili su tutte le piattaforme, la risposta è si.
(vedi msdn per la disponibilità delle API).
Post by Bracco Baldo
Mentre invece i programmi per la Modern UI funzionano SOLO su Windows 8?
esatto
--
Raffaele Rialdi http://www.iamraf.net
Weblog: http://blogs.ugidotnet.org/raffaele
Microsoft MVP profile
https://mvp.support.microsoft.com/profile/raffaele
UGIdotNET - http://www.ugidotnet.org/
Continua a leggere su narkive:
Loading...