mboost-dp1
Er du Windows admin ? Har du et job om 5 år?
I forbindelse med arbejde får jeg en masse kulørte blade.
Et af dem er "Redmond" som fokuserer på MS teknologi.
Seneste nummer indholdt følgende lille sætning på en ret fremtræden plads:
Kontant udmelding.
(jeg har erstattet IT pro med Windows admin, da det er hvad han mener)
Et af dem er "Redmond" som fokuserer på MS teknologi.
Seneste nummer indholdt følgende lille sætning på en ret fremtræden plads:
In five years, IT pros who aren't proficient in Windows PowerShell are going to be struggling to keep their jobs.
Kontant udmelding.
(jeg har erstattet IT pro med Windows admin, da det er hvad han mener)
MS : Vi rykker nu et stort skrit i Unix retningen, og hvis du ikke er med på det, så kommer du langt bagud.
Er det ikke lidt det samme som at indrømme at *nix altid har været et skridt foran.
Given enough time and money, Microsoft will eventually reinvent Unix.
Er det ikke lidt det samme som at indrømme at *nix altid har været et skridt foran.
Given enough time and money, Microsoft will eventually reinvent Unix.
Powershell er sådan set bare en forbedret version af bash, med flere muligheder, og bedre APIs.myplacedk (2) skrev:Er PowerShell ikke Microsofts forsøg på at gøre det muligt at administrere Windows på en unix-agtig måde?
Nej. Vi snakker om at Microsoft mener at powershell scripting bliver mere og mere et krav til administratoren.røvskæg (3) skrev:Er det ikke lidt det samme som at indrømme at *nix altid har været et skridt foran.
Både Windows og Linux har haft bash support i årtier. Powershell er bare "next gen", hvilket jo så må betyde at Microsoft er foran ;-)
Linux mener jo deres værktøjer fra midten af 90erne er "gode nok", og kunne aldrig forestille sig at udvikle et mere advanceret bash scripting sprog.
Powershell tillader COM og .NET interaktion. Ikke bare simpelt bash ligesom Linux.
Windcape (4) skrev:Linux mener jo deres værktøjer fra midten af 90erne er "gode nok", og kunne aldrig forestille sig at udvikle et mere advanceret bash scripting sprog.
Så er det godt at man kan skifte sin shell ud uden problemer.
Man kunne vel være pedantisk og sige, at udvikler man BASH, så det bliver mere awesome, så er det ikke bash længere.
Bash sproget dårligt, rimeligt dumt lavet på mange måder, og implementationen er langsom. På den anden side er det designet til at være både interaktivt, som i en shell, og bruges til scripting. Har aldrig helt bestemt mig for om det retfærdiggør dets særheder...
Anyway, bash er mit førstevalg når jeg lige skal lave en eller ting hurtigt. Eks. parse latex dokumenter, for at tjekke at forkortelser bliver indført i rigtig rækkefølge...
Det interessante ved PowerShell er at det er designet omkring et helt andet koncept end bash. Bash, og unix i det hele taget, er designet omkring et tekst interface. Det har man simpelthen ikke i Windows verdenen, så man var nødt til at gøre noget andet smart i stedet for.
Bash sproget dårligt, rimeligt dumt lavet på mange måder, og implementationen er langsom. På den anden side er det designet til at være både interaktivt, som i en shell, og bruges til scripting. Har aldrig helt bestemt mig for om det retfærdiggør dets særheder...
Anyway, bash er mit førstevalg når jeg lige skal lave en eller ting hurtigt. Eks. parse latex dokumenter, for at tjekke at forkortelser bliver indført i rigtig rækkefølge...
Det interessante ved PowerShell er at det er designet omkring et helt andet koncept end bash. Bash, og unix i det hele taget, er designet omkring et tekst interface. Det har man simpelthen ikke i Windows verdenen, så man var nødt til at gøre noget andet smart i stedet for.
#0
Min ærlige mening? Det manglede sguda også bare.
Mange uerfarne Windows admins kan ikke "se" det fantastiske i at kunne lære et script sprog (Ruby, Python, WSH m.v) og automatisere utroligt irriterende og repetitive opgaver og bruger opsætninger.
Det er en skrøne at man skal være super-programmør for at kunne smede et script sammen. Desuden bugner internettet med eksempler der er lige til at gå til. Det er altså ikke forbudt at kræve lidt af de ansatte.
In five years, IT pros who aren't proficient in Windows PowerShell are going to be struggling to keep their jobs.
Min ærlige mening? Det manglede sguda også bare.
Mange uerfarne Windows admins kan ikke "se" det fantastiske i at kunne lære et script sprog (Ruby, Python, WSH m.v) og automatisere utroligt irriterende og repetitive opgaver og bruger opsætninger.
Det er en skrøne at man skal være super-programmør for at kunne smede et script sammen. Desuden bugner internettet med eksempler der er lige til at gå til. Det er altså ikke forbudt at kræve lidt af de ansatte.
myplacedk (2) skrev:Hmm... Er PowerShell ikke Microsofts forsøg på at gøre det muligt at administrere Windows på en unix-agtig måde? (Men bedre...)
Så vi kan efterhånden vælge mellem et OS med en unix-shell, eller et OS med Microsofts alternativ/efterligning. Interessant.
Nu har Windows haft CMD siden 1993 og WSH siden 1998, så nyt er konceptet anbsolut ikke.
Det interessante er mere den manglende gennemslagskraft. Hvis jeg skulle gætte på hvad 100 Windows admins ville vælge til noget scripting så ville det være:
85% CMD
14% WSH
1% PS
#5
Linket siger:
Linket siger:
Windows PowerShell Is Not a Scripting Language
So, if Windows PowerShell isn't a scripting language, then what is it?
I submit that Windows PowerShell 2.0 is a text-based administrative automation solution. Through the simple connection of a few key cmdlets, even the greenest of IT pros can speed up the completion of the most difficult IT tasks.
That being said, I'll admit that this column's title isn't an entirely true statement. Windows PowerShell indeed comes equipped with some powerful scripting constructs that enable it to accomplish all the tasks you're used to seeing in a scripting language.
Benjamin Krogh (7) skrev:Det interessante ved PowerShell er at det er designet omkring et helt andet koncept end bash. Bash, og unix i det hele taget, er designet omkring et tekst interface. Det har man simpelthen ikke i Windows verdenen, så man var nødt til at gøre noget andet smart i stedet for.
PS er netop designet omkring et tekst interface.
#11 jeg mente programmerne der benyttes via shell, og ikke shell'en i sig selv. Dvs. at unix programmer ofte er designet omkring et "universalt" text interface, hvorimod programmer til windows er grafiske.
arne_v (10) skrev:#5
Linket siger:
Windows PowerShell Is Not a Scripting Language
So, if Windows PowerShell isn't a scripting language, then what is it?
I submit that Windows PowerShell 2.0 is a text-based administrative automation solution. Through the simple connection of a few key cmdlets, even the greenest of IT pros can speed up the completion of the most difficult IT tasks.
That being said, I'll admit that this column's title isn't an entirely true statement. Windows PowerShell indeed comes equipped with some powerful scripting constructs that enable it to accomplish all the tasks you're used to seeing in a scripting language.
Jeg undrede mig over hvorfor de ikke sagde hvad den var i stedet! Det lød som om at den mest skulle bruges til at lave jobs (oprette 100 brugere fra et excel ark) end f. eks. edite tekst eller sende email (eller whatnot).
Det er filosofien bag værktøjerne der blev lavet til Unix og Linux i 90erne, ja.Benjamin Krogh (12) skrev:#11 jeg mente programmerne der benyttes via shell, og ikke shell'en i sig selv. Dvs. at unix programmer ofte er designet omkring et "universalt" text interface, hvorimod programmer til windows er grafiske.
I dag er det anderledes på begge platforme. Jeg har ikke set nogle moderne projekter der kommer med brugerfladen som et seperat program, medmindre brugerfladen slet ikke var tænkt ind i første omgang.
Shell scripting bruges jo typisk til at løse opgaver i programmer som ikke var designet til den slags opgaver. Eller programmer med dårlige interfaces.
Vi bør stadigvæk ikke begynde at designe vores software så det faktisk kræver at brugeren kan powershell. Men powershell er en god udvidelse, for folk der skal bruge det til drift.
Windcape (16) skrev:Shell scripting bruges jo typisk til at løse opgaver i programmer som ikke var designet til den slags opgaver. Eller programmer med dårlige interfaces.
Hm. Jeg bruger ellers primært promptet til programmer som er designet til at gøre det jeg beder dem om, og de programmer har ofte et udemærket interface.
illishar (13) skrev:Er det en Bash-klon? Hm, så kunne det da være at man skulle kigge på den. MSYS og Cygwin er ikke ligefrem mesterværker, på den front.
Kun konceptuelt. Syntaxen er helt anderledes.
Mne jeg synes helt klar at du skal kigge på det.
Det er meget mere kraftfuldt end CMD.
Og mere moderne end WSH og COM.
Og den kendsgerning at hvis du vil lave udvidelser så skal det laves som .NET klasser er vel heller ikke en ulempe i din optik.
Prøv f.eks. at se følgende eksempel:
http://msdn.microsoft.com/en-us/library/ms714667.a...
Benjamin Krogh (12) skrev:jeg mente programmerne der benyttes via shell, og ikke shell'en i sig selv. Dvs. at unix programmer ofte er designet omkring et "universalt" text interface, hvorimod programmer til windows er grafiske.
Programmer der skal bruges i PS er også designet omkring et text interface.
onetreehell (14) skrev:Jeg undrede mig over hvorfor de ikke sagde hvad den var i stedet! Det lød som om at den mest skulle bruges til at lave jobs (oprette 100 brugere fra et excel ark) end f. eks. edite tekst eller sende email (eller whatnot).
PS kan uden tvivl også bruges til at edite en tekst eller udsende en email.
Men det er mest relevant hvis der skal edites mange filer/sendes mange email eller editeringen/email indhold skal afhænge af output fra scriptet.
Ellers er notepad og outlook oplagt.
Exchange 2007 og Exchange 2010 bruger rigtig rigtig meget Powershell. Nogle af funktionerne kan kun bruges igennem powershell, og jeg synes selv at det er lidt fjollet hvis man har et GUI og man ikke implenterer alle "knapperne".
Ved nærmere eftertanke er det jo ikke så galt igen, det er kun de mere specifikke (Unusual) opgaver der bliver klaret igennem powershell, så det er jo godt nok. Og PS er jo ikke sindsygt svært(Ikke at jeg kan skrive PS kode men jeg kan læse det og bruge det med lidt hjælp fra det store interweb).
Ved nærmere eftertanke er det jo ikke så galt igen, det er kun de mere specifikke (Unusual) opgaver der bliver klaret igennem powershell, så det er jo godt nok. Og PS er jo ikke sindsygt svært(Ikke at jeg kan skrive PS kode men jeg kan læse det og bruge det med lidt hjælp fra det store interweb).
Windcape (16) skrev:Det er filosofien bag værktøjerne der blev lavet til Unix og Linux i 90erne, ja.
I dag er det anderledes på begge platforme. Jeg har ikke set nogle moderne projekter der kommer med brugerfladen som et seperat program, medmindre brugerfladen slet ikke var tænkt ind i første omgang.
Shell scripting bruges jo typisk til at løse opgaver i programmer som ikke var designet til den slags opgaver. Eller programmer med dårlige interfaces.
Vi bør stadigvæk ikke begynde at designe vores software så det faktisk kræver at brugeren kan powershell. Men powershell er en god udvidelse, for folk der skal bruge det til drift.
Det er jo den traditionelle MS filosofi. Både user og admin skal bruge GUI.
Men MS har en anden filosofi idag. User skal bruge GUI, men admin er på vej over mod command line.
Windows Core og PowerShell er trin på vejen.
arne_v (21) skrev:PS kan uden tvivl også bruges til at edite en tekst eller udsende en email.
Men det er mest relevant hvis der skal edites mange filer/sendes mange email eller editeringen/email indhold skal afhænge af output fra scriptet.
Ellers er notepad og outlook oplagt.
Jeg kunne ikke forestille mig at det var praktisk at bruge notepad eller outlook over internettet. Jeg arbejder af og til på computere over internettet fordi jeg ikke har visse programmer på min egen computer af visse årsager. Så er det altså nemmere, synes jeg, at bruge eks. vim til at skrive koden og bruge mutt til at sende en email m. attachement på 'fjerncomputeren' end at skulle sidde at bøvle med måske sftp for at flytte filer så jeg kan skrive i notepad og sende emails i outlook.
Min pointe er vist at det kan være meget praktisk at kunne arbejde igennem en shell så man ikke behøver at være ved computeren/whatnot.
didriksen86 (22) skrev:Exchange 2007 og Exchange 2010 bruger rigtig rigtig meget Powershell. Nogle af funktionerne kan kun bruges igennem powershell, og jeg synes selv at det er lidt fjollet hvis man har et GUI og man ikke implenterer alle "knapperne".
Ved nærmere eftertanke er det jo ikke så galt igen, det er kun de mere specifikke (Unusual) opgaver der bliver klaret igennem powershell, så det er jo godt nok. Og PS er jo ikke sindsygt svært(Ikke at jeg kan skrive PS kode men jeg kan læse det og bruge det med lidt hjælp fra det store interweb).
Jeg synes det er uendeligt praktisk at have et CLI til sine programmer. Det gør det muligt at kunne automatisere ting nemt osv.
EDIT: Nogen der kan fortælle mig om man skal installere noget for at kunne bruge powershell? ellers googler jeg det...
Jeg tror du mener at admins skal BÅDE bruge GUI og CLI.arne_v (23) skrev:Det er jo den traditionelle MS filosofi. Både user og admin skal bruge GUI.
Men MS har en anden filosofi idag. User skal bruge GUI, men admin er på vej over mod command line.
Windows Core og PowerShell er trin på vejen.
Jeg tvivler på at Microsoft har nogen som helst intentioner om at gøre f.eks. Exchange ligeså besværligt at sætte op som en mailserver på Linux, hvor man skal være terminal-basher-guru eller lave pre-lavede shellscripts for at noget som helst er muligt.
Eller IIS for that sake.
At de vil give *muligheden* for mere terminal-baseret administration er jo fint. Men jeg tror tvivler stærkt på at det er et mål i sig selv.
Microsoft kan jo bare godt lide at lave værktøjer til deres brugere. Og de ser gerne folk bruger dem, derfor lidt pres på at få Powershell ud i verden.
Windcape (27) skrev:Hvis det er hurtigere at bruge CLI end GUI, så er GUIet ikke lavet ordenligt!
Prøv at lave et GUI for gcc som er hurtigere at bruge.
Windcape (28) skrev:
Jeg tvivler på at Microsoft har nogen som helst intentioner om at gøre f.eks. Exchange ligeså besværligt at sætte op som en mailserver på Linux, hvor man skal være terminal-basher-guru eller lave pre-lavede shellscripts for at noget som helst er muligt.
Du mener lige som de gjorde med exchange 2007? Hvor det først var med sp1 så vidt jeg husker at man fik grafiske værktøjer...
Windcape (27) skrev:Hvis det er hurtigere at bruge CLI end GUI, så er GUIet ikke lavet ordenligt!
Du er jo helt ufatteligt clueless.
Præcist denne diskution har vi haft før. Jeg gider ikke tage den igen, medmindre nogen direkte siger de er interesseret i at blive klogere.
Windcape (30) skrev:Det er hurtigere at trykke på F6 i mit IDE, for så at køre mit build-script, end det er at skrive det hele i CLI manuelt!
Easy, what's next?
Har du prøvet at læse man-pagen til gcc? De første ~1000 linier handler stortset kun om at liste de forskellige options. Og ved at trykke F6 kan din IDE på magisk vis regne ud hvilken arkitektur du vil compile til, hvilke flags osv.?
system type : Broadcom BCM5354 chip rev 3
processor : 0
cpu model : BCM3302 V2.9
BogoMIPS : 237.56
wait instruction : no
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : no
hardware watchpoint : no
VCED exceptions : not available
VCEI exceptions : not available
unaligned_instructions : 6
dcache hits : 0
dcache misses : 0
icache hits : 0
icache misses : 0
instructions : 0
Prøv at F6'e helloworld.c til min router.
Som jeg sagde, det er defineret i mit build script.onetreehell (33) skrev:Og ved at trykke F6 kan din IDE på magisk vis regne ud hvilken arkitektur du vil compile til, hvilke flags osv.?
Options i mit build script kan jeg så tilpasse via. mit IDE. Simple!
Nej, du nægter bare at acceptere at GUI faktisk er hurtigere, men af en eller anden religøs årsag, mener du at CLI er guds gave til verden, og GUI er ondskaben selv.myplacedk (32) skrev:Du er jo helt ufatteligt clueless.
Det er helt fint, sålænge dit mål i verden ikke er at bygge software der skal bruges af andre end inhouse nørder.
#34
Hvordan tilpasser du det? Det kunne jeg godt tænke mig at vide. Hvis det er så nemt, så kunne det være at jeg skulle bruge en (din) IDE til at crosscompile til min router...
Hvordan tilpasser du det? Det kunne jeg godt tænke mig at vide. Hvis det er så nemt, så kunne det være at jeg skulle bruge en (din) IDE til at crosscompile til min router...
Windcape (34) skrev:Som jeg sagde, det er defineret i mit build script.
Options i mit build script kan jeg så tilpasse via. mit IDE. Simple!Nej, du nægter bare at acceptere at GUI faktisk er hurtigere, men af en eller anden religøs årsag, mener du at CLI er guds gave til verden, og GUI er ondskaben selv.myplacedk (32) skrev:Du er jo helt ufatteligt clueless.
Det er helt fint, sålænge dit mål i verden ikke er at bygge software der skal bruges af andre end inhouse nørder.
... og hvad er så forskellen på at skrive et script i en prompt / terminal der kompilerer din kode, i forhold til at skrive et script i et IDE, som du kører derfra?
<ms-logic>
Så vidt jeg kan se er forskellen ens, det er bare farven der har en anden lyd - når man træder på den!
</ms-logic>
onetreehell (29) skrev:Prøv at lave et GUI for gcc som er hurtigere at bruge.
Selv om jeg kan lide prompten, så er det nu ikke så godt et eksempel, især ikke til Windcape.
Windcape elsker sit IDE, og kan ikke forestille sig andet. Han vil ingen glæde have ud af at kalde gcc via prompten, og kan ikke forestille sig at du har.
#37
På en måde ikke, nej (man skal lede man-page igennem efter de options man skal bruge).
Men hvis jeg ved hvilke flags jeg skal bruge, så tager det kun den tid det tager at skrive det ind (eller køre mit build-script). I et GUI skulle man enten lede efter sine 'flags' i et stort menu-system (mange museklik), hvilket kan tage lang tid, eller man kunne skrive det ind i et tekstfelt. Sidstnævnte vil sådanset bare være et CLI pakket ind i pænt papir.
På en måde ikke, nej (man skal lede man-page igennem efter de options man skal bruge).
Men hvis jeg ved hvilke flags jeg skal bruge, så tager det kun den tid det tager at skrive det ind (eller køre mit build-script). I et GUI skulle man enten lede efter sine 'flags' i et stort menu-system (mange museklik), hvilket kan tage lang tid, eller man kunne skrive det ind i et tekstfelt. Sidstnævnte vil sådanset bare være et CLI pakket ind i pænt papir.
myplacedk (32) skrev:Du er jo helt ufatteligt clueless.
Præcist denne diskution har vi haft før. Jeg gider ikke tage den igen, medmindre nogen direkte siger de er interesseret i at blive klogere.
Har du et link til den debat? Jeg kunne umådeligt godt tænke mig at se hvad en udvikler der efter eget udsagn ikke har nogen nævneværdig driftserfaring bruger som argument for at gui er hurtigere end cli
Jeg tror ikke at Visual Studio har support for den arkitektur du skal bruge ;-) Men nu beskæftigere jeg mig ikke med programmering af firmware.onetreehell (35) skrev:Hvis det er så nemt, så kunne det være at jeg skulle bruge en (din) IDE til at crosscompile til min router...
F.eks. at der er dropdown med mulige konfigurationer til den valgte option (måske endda med beskrivelse fra dokumentationen), frem for at du skal lede dokumentationen igennem efter valgmuligheder, og sikre dig du ikke taster forkert osv...Corholio (36) skrev:og hvad er så forskellen på at skrive et script i en prompt / terminal der kompilerer din kode, i forhold til at skrive et script i et IDE, som du kører derfra?
Fordi drift er alting GUI bruges til? Du spiller du bare dum.Hubert (39) skrev:Jeg kunne umådeligt godt tænke mig at se hvad en udvikler der efter eget udsagn ikke har nogen nævneværdig driftserfaring bruger som argument for at gui er hurtigere end cli
Selv mainframes har et terminal baseret GUI. Hvor man kan tabbe mellem felter. Du mener måske at terminal baseret GUI på en AS/400 er mindre effiktivt end at skrive kommandoer direkte i en promt?
Visual Studio 2010 - Konfiguration af Linker til C++
http://dl.dropbox.com/u/1744224/Upload/vsconfigcpp...
Og du kan også skrive custom values ind, og bruge allerede konfiguerede værdier, hvis du har flere at vælge imellem.
Hvis i f.eks. havde 3 forskellige, ville i så manuelt skrive 3 linjer, og udkommentere 2 af dem, ikke? Plus i skal skrive meget mere, slå det op først, osv.
Ja, det er nemlig hurtigere at gøre alting i hånden ja. I bruger også Lynx ikke? :P
http://dl.dropbox.com/u/1744224/Upload/vsconfigcpp...
Og du kan også skrive custom values ind, og bruge allerede konfiguerede værdier, hvis du har flere at vælge imellem.
Hvis i f.eks. havde 3 forskellige, ville i så manuelt skrive 3 linjer, og udkommentere 2 af dem, ikke? Plus i skal skrive meget mere, slå det op først, osv.
Ja, det er nemlig hurtigere at gøre alting i hånden ja. I bruger også Lynx ikke? :P
Windcape (40) skrev:Fordi drift er alting GUI bruges til? Du spiller du bare dum.
Selv mainframes har et terminal baseret GUI. Hvor man kan tabbe mellem felter. Du mener måske at terminal baseret GUI på en AS/400 er mindre effiktivt end at skrive kommandoer direkte i en promt?
Nej fordi det viser dit erfarings niveau. At du kan bruge en gui i dit IDE betyder ikke at det er hurtigere eller smartere med en gui.
Jeg kan ikke udtale mig vildt meget om os/400. Men så vidt jeg ved fra min sparsomme tid med en AS/400 maskine så er der som standard ikke en gui til bruger oprettelse og password management..?
Lad os give et mere kompliceret eksempel:
Du skal åbne en liste af brugere, for at finde en bestemt bruger, og rette nogle oplysninger.
Brugerne er listed i et DataGridView med en søgemulighed (der søger på alle mulige properties).
Du finder personen du leder efter, trykker på "rediger", får et nyt skærmbillede, og retter informationerne, og klikker på "gem".
Vil i på nogen som helst måde mene at overstående operation ville være smartere i CLI?
Du skal åbne en liste af brugere, for at finde en bestemt bruger, og rette nogle oplysninger.
Brugerne er listed i et DataGridView med en søgemulighed (der søger på alle mulige properties).
Du finder personen du leder efter, trykker på "rediger", får et nyt skærmbillede, og retter informationerne, og klikker på "gem".
Vil i på nogen som helst måde mene at overstående operation ville være smartere i CLI?
Ellers skal Hubert, som jo er "oh så erfarn med drift" give et eksempel på hvor han mener at GUI ikke kan løse en opgave bedre end et script :-)
Scripts/macroer er til at løse gentagende opgaver, som sker sjældent. "Daglig drift", altså alm. gentagende opgaver, vil altid have fordel af et GUI frem for at være CLI baseret.
Scripts/macroer er til at løse gentagende opgaver, som sker sjældent. "Daglig drift", altså alm. gentagende opgaver, vil altid have fordel af et GUI frem for at være CLI baseret.
Windows CE findes til ARM. Kan du vise mig hvordan man compiler til Windows CE på ARM i visual studio? Gad godt at se hvor nemt det er...
Windcape (47) skrev:Nej, men jeg skrev at hvis en opgave var hurtigere at løse i CLI end i GUI, så var GUIet ikke lavet ordenligt.
Det var ikke det, jeg svarede på.
Windcape (47) skrev:Du giver jo udtryk for at du hellere vil bruge CLI til at løse alle opgaver, selv hvis det er muligt i GUI.
Nej. Jeg siger at det er ukorrekt at ALLE opgaver løses bedst af ALLE i GUI. Det betyder ikke at min holdning er præcist modsat.
Så skal jeg installere deres Windows Embedded CE SDK først.onetreehell (46) skrev:Windows CE findes til ARM. Kan du vise mig hvordan man compiler til Windows CE på ARM i visual studio? Gad godt at se hvor nemt det er...
Måske lidt senere :-)
Jeg kan dog relativt nemt skippe mellem x86, x64 og Itanium som standard.
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.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund