ReactOS utvilkling kan noen fortelle meg strukturen?

[LMH1]

http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/taskmgr/

 

http://img825.imageshack.us/img825/2316/utennavng.png

 

Har noen peiling på hva som skal til å få ReactOS å støtte "Multitreading" slik på bilde?

Altså både ram/prosessor viser treading og memory DIMM

Er det bare å endre tastmgr eller må man gjøre langt større endringer i DDL bibloteket?

 

Eventuelt kan noen gi med en guide på hvordan man komplierer X64 bits kode i en ISO fil?

 

ReactOS Build Environment for Windows NT-compatible OS - Version 1.4 beta 2 er ikke tilgjengelig merkelig nok.

 

Hvordan er "Avslutt/Reboot" programmert?

 

Takk for alt dere kan hjelpe til med, har jobbet litt med c++, men er ikke så flink å forstå utvikler strukturen i windows, bruker virtualbox/vmware. Så en innføring i hvordan man får en mere teknisk forståelse av hvordan ReactOS virker ville vært bra.

 

Eventuelt hva slags verktøy som bør brukes? Microsoft virtual basic C++/C# funger nok dårlig her desverre.

 

Vet noen om en utviklingemulator, som i tillegg funger som virtualbox, men også sier litt hva programmer gjør (kode) så ville det også vært flott.

Endret 6. desember 2011 av LMH1

[GeirGrusom]

ReactOS blir kompilert med MinGW (hvordan dette skal gjøres forklares i mappen til versjonskontrollen)

ReactOS er multi-threaded, du trenger ikke kompilere noe spesielt for å få til det. Det den derimot viser på bildet er at det er flere prosessorer tilgjengelig på systemet. Ettersom det er 8 kjerner, går jeg utifra at dette ble kjørt på en quad core Intel prosessor med hyper-threading.

 

Skal du kompilere ReactOS må du ha to ting:

- SVN

- MinGW

Du kan kompilere med Visual C++ (eller egentlig hvilken compiler du vil) men de har brukt MinGW i utviklingen, så det er en fordel å bruke det samme som alle andre her.

Det heter forøvrig Visual Basic, ikke Virtual Basic.

 

Avslutt/reboot er en omstendelig prosess. I DOS dager var det bare snakk om å kalle et interrupt, men i moderne operativsystemer så må ressurser frigjøres, og operativsystemet må påse at alle programmer er klare for å avslutte når den faktiske restarten skjer. Hvordan dette er implementert kan du se nøyere i kildekoden (det er definert et sted i ntoskrnl).

[LMH1]

Så man trenger bare å utvikle taskmgr å vise trådene?

 

Nå har jeg endret bilde i paint for å se ut som windows oppgavebehandler.

Nå vet jeg lite hvor mye "tread" som kan kjøres før det ikke vises?

 

Å kompliere fra SVN kildekoden vil bety problemer, jeg har forsøkt det et par ganger vet ikke hva utviklerne kaller SVN (Kilden) eller noe annet.

 

Men det stopper som regel opp eller ender med en ustabil build, beste er nok å ta fra "Release" eller noe slikt, da går det mye enklere.

 

SVN er vel bare for utvikle.

 

MinGW støtter vel ikke hypertreading? Og optimalisert å bruke ram isteden under bygging?

Så kunne den prosessen gått mye raskere, syns det går tregt å bygge en ISO fil jeg med forhåndvis rask maskinvare.

 

Er det ikke slik av avsluttning så skriver alt fra RAM til harddisken? Så derfor må man i noentilfelle restarte maskinen for at nye instillinger skal tre i kraft, hadde man slått av med power knappen kan datene gå tapt.

Angående prosesser, tror jeg den bare dropper ut.

 

Angående det å programmere linux/ReactOS tror jeg neppe man lærer det på skolen for å si det slik, folk har nok hatt erfaringer med det tidligere, siden det er nok en kravstor prosess.

Endret 7. desember 2011 av LMH1

[oelbox]

Nå tror jeg du blander noe veldig her.

 

Så man trenger bare å utvikle taskmgr å vise trådene?

 

Hvis jeg forstår deg rett fra den originale posten din så kjører du react os i virtualbox? Og at du tydeligvis bare ser 1 cpu i taskmanager? Hvis det er tilfelle må du sjekke om du har gitt react os vm'en din i virtualbox tilgang til mer enn en cpu.

 

Nå har jeg endret bilde i paint for å se ut som windows oppgavebehandler.

Nå vet jeg lite hvor mye "tread" som kan kjøres før det ikke vises?

 

Dette forstod jeg ikke - hva har et bilde og paint med dette å gjøre må du nesten forklare litt nærmere.

 

MinGW støtter vel ikke hypertreading? Og optimalisert å bruke ram isteden under bygging?

Så kunne den prosessen gått mye raskere, syns det går tregt å bygge en ISO fil jeg med forhåndvis rask maskinvare.

 

Hyperthreading er en intel cpu-teknologi for paralellisering av oppgaver. HT må støttes av operativsystemet og har ikke så mye med MinGW å gjøre. Hvor ISO fil kommer inn i dette skjønner jeg ikke helt - og det har heller ingenting med MinGW å gjøre.

 

MinGW er i praksis en windows port av kompilator pakken Gnu Compiler Collection og Gnu Binutils, og kan lage exe-filer og dll-filer for windows kompatible operativsystemer fra diverse programmeringsspråk.

 

Er det ikke slik av avsluttning så skriver alt fra RAM til harddisken? Så derfor må man i noentilfelle restarte maskinen for at nye instillinger skal tre i kraft, hadde man slått av med power knappen kan datene gå tapt.

 

Igjen er jeg veldig usikker på hva du mener her, men når man kompilerer noe så vil det nødvendigvis lastes inn og ut av ram, og skrives til disk. Men denne prosessen har på ingen måte noe med behov for omstart av maskinen. Når windows krever omstart, er det fordi det er en oppdatering av system-filer som er låst, og man ikke får oppdater disse før windows har sluppet restriksjonene på disse filene.

 

 

Angående prosesser, tror jeg den bare dropper ut.

 

Hvilken prosess er det du mener som dropper ut?

 

Denne diskusjonen har kansje ikke så mye med C/C++ å gjøre, med mindre jeg har misforstått hva du egentlig spør om. Kansje et react-os forum er bedre å spørre på, ettersom det der sikkert er folk som har mer inngående kjenskap til systemet.

[GeirGrusom]

Så man trenger bare å utvikle taskmgr å vise trådene?

 

Nå har jeg endret bilde i paint for å se ut som windows oppgavebehandler.

Nå vet jeg lite hvor mye "tread" som kan kjøres før det ikke vises?

 

Å kompliere fra SVN kildekoden vil bety problemer, jeg har forsøkt det et par ganger vet ikke hva utviklerne kaller SVN (Kilden) eller noe annet.

 

Men det stopper som regel opp eller ender med en ustabil build, beste er nok å ta fra "Release" eller noe slikt, da går det mye enklere.

 

SVN er vel bare for utvikle.

 

MinGW støtter vel ikke hypertreading? Og optimalisert å bruke ram isteden under bygging?

Så kunne den prosessen gått mye raskere, syns det går tregt å bygge en ISO fil jeg med forhåndvis rask maskinvare.

 

Er det ikke slik av avsluttning så skriver alt fra RAM til harddisken? Så derfor må man i noentilfelle restarte maskinen for at nye instillinger skal tre i kraft, hadde man slått av med power knappen kan datene gå tapt.

Angående prosesser, tror jeg den bare dropper ut.

 

Angående det å programmere linux/ReactOS tror jeg neppe man lærer det på skolen for å si det slik, folk har nok hatt erfaringer med det tidligere, siden det er nok en kravstor prosess.

Jeg tror du roter sammen MinGW, ReactOS og programmer som kjører på ReactOS sammen til en merkelig suppe. MinGW kan ikke støtte hyperthreading, ettersom det overhode ikke er kompilatorens jobb. Operativsystemet (ReactOS) må derimot skrives for å støtte hyperthreading. Jeg bare nevne hyper-threading her fordi jeg ser at taskmanageren du viste bilde av viser 8 logiske prosessorer, som tyder på at det mest sannsynlig er en quad core Intel prosessor som kjører ReactOS i det tilfellet.

 

MinGW er en samling av GNU programvaresom skaø gjøre arbeidsmetoden under GNU/Linux tilgjengelig for Windows brukere (Minimalist GNU for Windows) og i den pakken ligger kompilatoren, GCC, tilgjengelig som er et av verktøyene som brukes for å bygge ReactOS. Hvordan du selv skal kompilere ReactOS ligger forklart i en tekstfil i SVN trunk. Du kan kompilere dette i Linux også, og du kan velge en annen kompilator enn GCC under MinGW, men det vil garantert føre til en del ekstra jobb.

 

Når det gjelder bygging, så går kompilering under GCC vesentlig tregere på Windows enn på Linux. Det tar mye lenger tid å starte et program i Windows enn det tar under Linux, som er ganske uheldig med tanke på kompilering under GCC i Cygwin eller MinGW. Men filer som ikke blir endret skal kun bli kompilert én gang (den sjekker om tilsvarende objektfil er eldre enn kildefilen for om den gidder å kompilere på nytt)