mboost-dp1

Wikimedia

Microsoft siger farvel til Internet Explorer

- , indsendt af Claus Jørgensen

Begyndende fra slut november, 2020, vil Microsoft selv stoppe med at supporte Internet Explorer.

I praksis betyder dette at Microsoft fra d. 30 november 2020, ikke længere vil supportere IE11 til deres eget Microsoft Teams.

Dernæst i stopper de med support for IE11, på tværs af hele Microsoft 365, d. 17 august 2021.

Det betyder dog ikke at Internet Explorer ikke længere kan blive brugt af de personer og virksomheder der i dag bruger browseren, men blot at de skal benytte et andet program til at tilgå netop Microsoft 365’s produkter online.

Microsoft anbefaler selv, at man skifter til Edge – og at Edge Legacy har EOL d. 9 marts 2021.





Gå til bund
Gravatar #1 - AppleSheep
21. aug. 2020 07:22
Sikke dog en trængsel der er for at komme til at kommentere på den artikel :D
Gravatar #2 - kriss3d
21. aug. 2020 12:14
Endelig. Den skulle have været lagt i graven for år siden. Stod det til mig kom der en opdatering der fjernede IE helt.
Og firmaer det stadig bruger den skal have smæk. Med en våd Søndags BT.
Gravatar #3 - Athinira
21. aug. 2020 12:56
Gravatar #4 - Claus Jørgensen
21. aug. 2020 13:10
#2

Hvis du læser kilden kan du se hvad problemerne er for visse virksomheder. Rigtige mange af snakker om SharePoint.

F.eks.

At some point in development will Edge natively support SharePoint "View in File Explorer"? Will Microsoft completely rewrite File Explorer access to SharePoint Online to work natively in Edge, removing the dependency on the ActiveX control.
Det er vildt hvor blinde folk er. Hvordan kan de nogensinde tro at en browser skal have direkte adgang til filsystemet?

Will this affect the WebBrowser OLE object? We use that to display and edit (with Design Mode) HTML in an application used by thousands of users.
like, wtf?!?

have a MFC application that I have maintained for a number of years and I have two specific areas of concern:

1. I use the CHtmlView web browser control for display reports in my software. I do allow the user to also preview externally in any installed browser but fundamentally for the mechanics of my editor it uses the internal CHtmlView browser. Is this going to still be supported or upgraded so that it does not break? Or will it be unaffected? I need a working way forward please. This is important to me and my users.

2. I use the standard Windows 10 mechanism for transforming XML / XSL files into HTML (which is used with my editor). I assume that this functionality will still work?
?!?!?

Jeg kan nemt forestille mig at mange af deres apps kunne laves i Electron/React og løse en million problemer deres brugere har klaget over i 20 år.

Men det ville jo kræve at dem som vedligeholder løsningen lærer noget nyt :p
Gravatar #5 - arne_v
21. aug. 2020 13:20
Claus Jørgensen (4) skrev:

At some point in development will Edge natively support SharePoint "View in File Explorer"? Will Microsoft completely rewrite File Explorer access to SharePoint Online to work natively in Edge, removing the dependency on the ActiveX control.


Det er vildt hvor blinde folk er. Hvordan kan de nogensinde tro at en browser skal have direkte adgang til filsystemet?


Jeg troede at de talte om "adgang til SP web site via Windows Explorer" ikke om "adgang til fil system via Internet Explorer"??

Gravatar #6 - Claus Jørgensen
21. aug. 2020 13:22
#5

Men hvis det er tilfældet, hvad har det så at gøre med IE? Mixer de up Windows Explorer og Internet Explorer?

Jeg har (heldigvis) ikke brugt SharePoint i over 10 år, så jeg ved ikke rigtig hvordan det virker.

Det lyder mere som om at de har "embedded windows explorer" i et web-view, i stedet for at bruge et rent HTML interface (ala. Google Drive / OneDrive på web)
Gravatar #7 - arne_v
21. aug. 2020 13:32
Claus Jørgensen (6) skrev:

Men hvis det er tilfældet, hvad har det så at gøre med IE? Mixer de up Windows Explorer og Internet Explorer?


Windows Explorer skal jo bruge noget til at tale med web site.

Man kunne jo godt forestille sig at Windows Explorer brugte en Internet Explorer komponent til dette.
Gravatar #8 - larsp
21. aug. 2020 14:19
#4 IE er jo tilbage fra de glade naive dage hvor alt var tilladt, og jo mere direkte komponenter kunne tage fat i andre komponenter, jo bedre. Hvorfor ikke activex og OLE direkte i en webbrowser?

Lave det hele forfra i electrum? Hvor mange nuller skal der mon på den konsulentregning? Og hvor mange år med bugs og forvirring vil det tage før det kører bare nogenlunde igen.

Jeg forstår udemærket kritikken fra virksomheder der i gennem årtierne har bygget og finpudset en masse integration op med de værktøjer der var på mode dengang.

Microsoft må bare finde en løsning.
Gravatar #9 - Claus Jørgensen
21. aug. 2020 14:23
#8

Hvis du ikke har opdateret dit software i 20 år, og det så pludselig ikke virker i 2020, så er du selv svar skyldig. Software udviklere der først begynder at starte forfra / opdatere deres teknologi når det er for sent er uansvarlige.

Software skal opdateres løbende. Hvis man bliver nød til at skifte teknologi, f.eks. at bruge HTML5 i stedet for Flash, så gør man jo det.

Microsoft må bare finde en løsning
Nope. 5 års varsel må altså være nok.
Gravatar #10 - larsp
21. aug. 2020 14:32
#9 Jeg er enig med dig, men som djævlens advokat vil jeg bare påpege at man ser igen og igen at gen-implementering af gammel special software ender med at være langsommere, ringere og fyldt med fejl.

Man skal ikke undervurdere business kode der er blevet finpudset igennem årtierne. Den der skrev den oprindelige kode var 99% en selvlært wizard som lavede det hele på en ekstremt smart måde. Når man så hyrer en bande moderne webudviklere laver de en masse standard crap der virker af h. til.

Ligesom en 100 år gammel skrivemaskine stadig virker, cobol kode stadig udfører bank beregninger, DOS kode kan køres i dosbox, bør Microsoft kunne finde ud af at sandboxe deres gamle frameworks så de kan køre en 10-20 år endnu...

:P
Gravatar #11 - arne_v
21. aug. 2020 14:43
larsp (8) skrev:

IE er jo tilbage fra de glade naive dage hvor alt var tilladt, og jo mere direkte komponenter kunne tage fat i andre komponenter, jo bedre. Hvorfor ikke activex og OLE direkte i en webbrowser?


Der er sagt meget grimt omkring IE of ActiveX. Men jeg kan ikke helt forstå kritikken.

IE havde brug for at kunne håndtere extensions. Java, Flash etc.. MS kunne opfinde en ny standard for interface mellem IE og komponenter eller de kunne genbruge deres standard komponent interface COM/ActiveX. Genbrug giver god mening.

Mozilla havde samme behov, men da de ikke kunne nøjes med en Windows only løsning så måtte de opfinde en ny standard XPCOM.

(XPCOM er fjernet idag og erstattet med noget der ligner Chromeøs måde at gøre det på, men de brugte XPCOM for 20+ år)
Gravatar #12 - arne_v
21. aug. 2020 14:56
larsp (10) skrev:

Jeg er enig med dig, men som djævlens advokat vil jeg bare påpege at man ser igen og igen at gen-implementering af gammel special software ender med at være langsommere, ringere og fyldt med fejl.

Man skal ikke undervurdere business kode der er blevet finpudset igennem årtierne. Den der skrev den oprindelige kode var 99% en selvlært wizard som lavede det hele på en ekstremt smart måde. Når man så hyrer en bande moderne webudviklere laver de en masse standard crap der virker af h. til.


Jeg er ikke så overbevist om at kode der skrives idag af professionelle er dårligere end kode der blev skrevet for 40 år siden af professionelle.

Man kunne godt få det indtryk, men jeg tror at det skyldes 2 "distraktioner":

1) Det er almindeligt at sprit ny kode har flere fejl en kode som har været i brug i mange år - fejl bliver fundet over tid og fikset. Det betyder at der naturligvis er færre fejl i den 40 gamle software end den nye erstatningsofwtare. Det er en OK sammenligning for at vurdere om man skal opdatere, men det er en forkert sammenligning for at vurdere kvaliteten af software udvikling. For det sidste skal man sammenligne fejl i det spritnye software med fejl i det gamle software for 40 år siden eller det spritnye software 40 år ude i fremtiden med det gamle software idag.

2) Man kan nemt komme til sat sammenligne kvaliteten af alle softwware udvilkere for 40 år siden (stort set alle professionelle) med alle softwware udvilkere idag (måske 1/3 professionelle og 2/3 amatører). De mange millioner af hobbyudviklere som idag sidde og skriver kode (typisk PHP med lidt JS tilsat) som er så ringe at man græder trækker meget ned på gennemsnittet idag.
Gravatar #13 - arne_v
21. aug. 2020 14:59
#10

Med hensyn til resource forbrug, så er det normalt at en ny løsning bruger langt flere resourcer (CPU, memory, disk plads) end den gamle løsning.

Og nogen gange er det ren frås.

Men sålænge at prisen for den nye HW er lavere end prisen for den gamle HW da den blev anskaffet, så er det sjældent et problem.
Gravatar #14 - Claus Jørgensen
21. aug. 2020 16:58
arne_v (12) skrev:
De mange millioner af hobbyudviklere som idag sidde og skriver kode (typisk PHP med lidt JS tilsat) som er så ringe at man græder trækker meget ned på gennemsnittet idag.
Minder mig lidt om ASP.NET (før ASP.NET MVC)

Der var Danske evangelister med Microsoft certificeringer som udgav bøger med kode så ringe at man burde græde.

Jeg kan huske at argumentere med min professor på datamatiker studiet om at POST requests til at load en ny side (et typisk GET request) var et idiotisk ide fordi at a) folk fik en popup ved reload b) ingen tilbageknap / state.

Webudvikling tiltrækker generelt massere af dårlige udviklere fordi at selv en dårlig udvikler kan lave noget der ser pænt ud.
Gravatar #15 - arne_v
21. aug. 2020 18:36
#14

Håbløse datamatikere fra den dårligste halvdel er stadig både færre og markant bedre end dem der mener at en halv times Youtube video er nok til at kunne programmere.
Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login