4716 risposte a questa discussione

[trallallero]

Non c'entra, il problema è il CAMBIO di API (WinRT).

 

Windows 8-8.1-successivi non sono più windows "di una volta". FINE.

 

Appunto

[TigerShark]

Non c'entra, il problema è il CAMBIO di API (WinRT).

 

Windows 8-8.1-successivi non sono più windows "di una volta". FINE.

Le api WinRT vengono usato per le applicazioni del windows store e non c'e' la benche' minima relazione con il driver model che non gira certo in un sandboxed user space.

E' ovvio che da una release all'altra del SO ci possano essere dei cambiamenti a livello di interfaccia del kernel, ma tra 8 e 8.1 la compatibilita' DEVE essere mantenuta, stiamo parlando di un cazzo di service pack di un SO di merda.

Messaggio modificato da TigerShark il 20 ottobre 2013 - 20:45

[lowenz]

Appunto

Non è questione di mancata documentazione, è questio che gli sviluppatori non possono passare di colpo alle nuove API, e questo spesso inficia l'efficienza di tantissime cose. E' un problema strutturale.

 

Esempio: i driver di Creative delle schede fino a 2 anni fa hanno come base l'architettura driver di Win2000, e NESSUNO si sogna di riscriverli da capo. Nessuno. Quindi si mettono pezze qui e là per "tirare avanti" fino a quando verranno abbandonate.

[lowenz]

Le api WinRT vengono usato per le applicazioni del windows store e non c'e' la benche' minima relazione con il driver model che non gira certo in un sandboxed user space.

E' ovvio che da una release all'altra del SO ci possano essere dei cambiamenti a livello di interfaccia del kernel, ma tra 8 e 8.1 la compatibilita' DEVE essere mantenuta, stiamo parlando di un cazzo di service pack di un SO di merda.

E' un esempio dell'inerzia nello sviluppo. Non si può pretendere che tutti facciano subito il salto.

Messaggio modificato da lowenz il 20 ottobre 2013 - 20:47

[:dissident:]

Ma non penso sia il caso di win8.

Anche perché ci sono più driver funzionanti che il contrario..

[lowenz]

il driver model che non gira certo in un sandboxed user space.

 

Ah, già che ci siamo.

Precisazione sull'argomento "driver": l'interfaccia utente (che gira in user space) di molti driver (i vari pannelli di controllo per agire sulle impostazioni) opera in .NET in windows (Forceware, Catalyst, ecc.), e già questo crea un bel po' di problemi con varie versioni attuali di .NET (3.5 -> 4 -> 4.5).

Non è poi rarissimo che si impalli tutto a livello utente costrigendo comunque ad un logout (quando l'input risponde ancora).

Messaggio modificato da lowenz il 20 ottobre 2013 - 20:58

[:dissident:]

Le api WinRT vengono usato per le applicazioni del windows store e non c'e' la benche' minima relazione con il driver model che non gira certo in un sandboxed user space.
E' ovvio che da una release all'altra del SO ci possano essere dei cambiamenti a livello di interfaccia del kernel, ma tra 8 e 8.1 la compatibilita' DEVE essere mantenuta, stiamo parlando di un cazzo di service pack di un SO di merda.

Infatti chi ha problemi di compatibilità con l'8.1 ce li aveva anche con l'8 a quanto vedo, non sono sorti con questo update.

[lowenz]

Infatti chi ha problemi di compatibilità con l'8.1 ce li aveva anche con l'8 a quanto vedo, non sono sorti con questo update.

Infatti.

[toyo]

no ma spiegami che problemi dovrebbero avere i vari frontend in .NET

[lowenz]

no ma spiegami che problemi dovrebbero avere i vari frontend in .NET

Che a volte si impallano di brutto e con loro l'interfaccia di Windows (quindi diventa un pochino difficile accedere al task manager e killare il processo)

[toyo]

si ma lì al 99% è colpa del toyo di turno, no del framework

[toyo]

mai visto impiantare tutta l'interfaccia di win per colpa di un'app in .NET btw, secondo me parli a vanvara

[G-DannY]

secondo me parli a vanvara

 

NON FARLO DIO CANE

Messaggio modificato da G-DannY il 20 ottobre 2013 - 21:29

[toyo]

più probabile che il frontend in .NET faccia partire qualcosa di unmanaged e quello si che con un po' d'impegno inchioda tutto

[lowenz]

più probabile che il frontend in .NET faccia partire qualcosa di unmanaged e quello si che con un po' d'impegno inchioda tutto

 

si ma lì al 99% è colpa del toyo di turno, no del framework

Sono cose collegate, il fatto è che capita.

Quindi si dà colpa all'OS ma in realtà il problema risiede in .NET (difficilmente uno su WinXP mette .NET recenti perchè è più propenso a cambiare OS, quindi "WinXP è perfetto!!!11111", grazie al cazzo) o se preferisci in cosa permette di "sporco".

Messaggio modificato da lowenz il 20 ottobre 2013 - 21:40

[toyo]

bah, discorso da bar

[G-DannY]

fake, lowenz al bar non ci va.

[energy+]

Poi dicono degli applefag, ma vi leggete finestrafag?

[TigerShark]

Infatti chi ha problemi di compatibilità con l'8.1 ce li aveva anche con l'8 a quanto vedo, non sono sorti con questo update.

ma dove? C'era coso qualche pagina prima col BSOD x driver power failure nel passaggio da 8 ad 8.1.

[TigerShark]

Sono cose collegate, il fatto è che capita.
Quindi si dà colpa all'OS ma in realtà il problema risiede in .NET (difficilmente uno su WinXP mette .NET recenti perchè è più propenso a cambiare OS, quindi "WinXP è perfetto!!!11111", grazie al cazzo) o se preferisci in cosa permette di "sporco".

porco dio, torna a parlare di unz unz e della tua musica di merda che ė meglio.
Un'applicazione .Net col cazzo che ti fa impallare pure dio a meno di non usare codice nativo.
E in quel caso il .net c'entra un beneamato cazzo
Di tutti i bug che ho visto nel .net framework ovviamente nei casi più gravi crashava solo l'applicazione.

Messaggio modificato da TigerShark il 20 ottobre 2013 - 22:53