'Crashes vermeden door herallocatie geheugen'

Een Microsoft-onderzoeker en een informaticus hebben een programma genaamd DieHard uitgebracht dat computercrashes en bepaalde soorten aanvallen kan afwenden door de manier te wijzigen waarop applicaties het geheugen benaderen.

Volgens de makers van het programma, dat voor niet-commerciële doeleinden gratis is, worden veel programmeerfouten veroorzaakt doordat programmeurs nog steeds code schrijven alsof geheugen schaars is. Dat leidt, vooral in talen zoals C en C++, tot fouten zoals bijvoorbeeld het meerdere malen of te vroeg vrijgeven van geheugen. Het systeem, ontwikkeld door informaticus Emery Berger en Microsoft-onderzoeker Ben Zorn, moet voorkomen dat het door dergelijke fouten met de executie van programma's gedaan is, door de geheugenallocaties te herleiden naar een zogeheten randomized memory manager. Deze benadert op probabilistische wijze een 'infinite heap memory manager', door het geheugen zo te herindelen dat de kans dat er op plekken geschreven en gelezen wordt waar dat niet zou moeten, geminimaliseerd wordt.

Het programma, dat is ontwikkeld met financiële steun van Microsoft, Intel en de National Science Foundation, is beschikbaar voor Windows XP, Windows Vista en Linux. De Windows-versies beschermen op dit moment echter enkel de Firefox-browser - de Linux-versie kan willekeurige applicaties onder zijn hoede nemen. Uiteraard wordt er extra systeemgeheugen door DieHard geclaimd; volgens Berger zou de toename ongeveer 50 tot 75 procent zijn. De prestaties van applicaties zouden daar, mits er inderdaad voldoende geheugen aanwezig is, niet merkbaar onder lijden. Technische details over geheugenmanagement met DieHard zijn in pdf-formaat van Bergers website te downloaden.

Reacties (104)

[ReLexEd]

"DieHard helps buggy programs run correctly
and protects them from a range of security vulnerabilities."


Alleen het eerste gedeelte al....
Hoe uitnodigend wil je het programmeurs maken om nog luier te worden dan de meeste al zijn!

En ja, ik heb recht van spreken, aangezien ik er zelf eentje ben

Het tweede gedeelte klinkt wel aangenaam!

[Verwijderd]

Ik denk juist dat het aanzet om minder buggy code te schrijven. Het kan makkelijker fouten opsporen, zonder dat je applicatie telkens volledig crasht. Dit maakt het makkelijker om te debuggen en zorgt voor een stabieler programma voor de eindgebruiker.

[ATS]

Als een applicatie niet crasht en steeds een andere memory dump laat zien (daar lijkt het op in het artikel), dan wordt debuggen helemaal niet makkelijker! In tegendeel.

[Verwijderd]

Eén gedetailleerde dump is voldoende. Als het de programmalijnen geeft waar de fouten gebeuren is dat al waar je naar moet kijken. Ok je kent niet de volledige context maar mét geheugenadressen was je toch niet veel wijzer. In ieder geval heb je veel meer informatie dan zonder deze tool.

[Blorgg]

Dus als ik het goed begrijp vinden ze het maar niets dat programmeurs code zo efficient mogelijk schrijven, en willen ze dit programma toepassen omdat er toch geheugen zat is waardoor een geheugen gebruik toename van 50 tot 75% prima goed is?

Wat voor gare filosofie is dat nou weer?
Prima als je crashes vanwege nare bugs wilt voorkomen, maar ga dan zo'n toepassing niet aanprijzen met dit soort onzin. Veel programmatuur wordt al van verdacht niet al te best geoptimaliseerd te zijn, en tools als deze zullen dat alleen maar in de hand spelen als je er zo'n denkwijze op na gaat houden.

[engelbertus]

het is niet efficient om een geheugenplek t evroeg vrij te geven je programma leest dan de waarde die een ander programma op die plek heeft geschreven of krijgt niets te zien omdat de memory manager weet dat er niets meer staat.

als je het tweemaal vrijgeeft heb je grote kans dat het dus geheugen vrijgeeft dat door een ander programma wordt gebruikt.

wat ze dus bedoelen met "alsof geheugen schaars is" betekent dat men denkt dat men eerst geheugen moet aloceren, en dan meteen weer vrijgeven. alsof het bijna het sluiten van je tags is, automatisch. dat moe je dan wel op de juiste momenten doen, en niet zo snel mogelijk met deze bugs als gevolg.
later vrijgeven kan best. als je het maar doet. je heft er ook geen dag mee te wachtennatuurlijk.

en als je het vergelijkt met vroeger in de tijd van 512 kb geheugen, dan is geheugen helemaal niet schaars, het is alleen jammer dat we er zoveel van nodig hebben. je plaatje of ruwe data mag je ook best weer uit het geheugen gooien hoor, maar bijvoorbeeld bij spelletjes vindt men het toch wel prettig als bijvoorbeeld alles gecached wordt want diskacces is duur. het wordt alleen jammer als je dan geheugen is schaars-eficient gaat programeren. doe een beetje relaxed, en kijk wat je programma nu werkelijk gebruikt als je wat mindergeheugen vrijgeeft. gebruik het eens gewoon opnieuw. je programma an sich zal er geen meer gheugen door gaan gebruiken, en als je geheugengebruik standaard al boven de 50% is zit je al erg hoog, plus dat als je daaronder zit kan het geen kwaad om de rest ook eens te gebruiken. dat programma zal heus wel swappen als dat nodig mocht zijn.
het doet immer probabiliteitsvoorspellingen. en volgens de schrijvers doet ie dat dus niet slecht. programmas zouden er geen hindr van ondervinden.

ik heb liver een gig mer in mijn pc dan dat mijn pc twee keer zovaak om wat voor reden dan ook opnieuw opgestart moet worden.

en voor wat die programeurs betreft, het gaat er dus om dat ze beter gaan programeren, immers het zijn diezelfdeprogrameurs die er voor zorgen dat er geheugen wordt gelekt ( geheugen dat dus helemaal niet meer vrij wordt gegeven. dat noem ik ook niet bijster efficient.)

[Verwijderd]

als je het tweemaal vrijgeeft heb je grote kans dat het dus geheugen vrijgeeft dat door een ander programma wordt gebruikt.

Dat is ook onmogelijk. Het besturingssysteem zal nooit geheugen van het ene programma laten beheren door een ander programma. Die genereert gewoon een exceptie voor het programma dat geheugen probeert vrij te geven dat niet (meer) aan dat programma is toegewezen.

[Frank-L]

Sterker nog, door het gebruik van de MMU van de CPU (sinds de NT versies van Windows) krijgt elk user-space proces (dus feitelijk elk programma) zijn eigen memory-map waardoor je geheugen van andere applicaties niet kunt overschrijven, vrijgeven of zelfs maar lezen.

Het gaat hier waarschijnlijk alleen om geheugen dat door de applicatie zelf wordt overschreven terwijl het nog (op een andere plek in dezelfde applicatie) in gebruik is.

[engelbertus]

ok, maar dan alsnog -> bug and crash...

en wat dan als hetzelfde programma , maar andere code op die plek iets heeft geschreven ?
dat lijkt me wel toegestaan door het os

[Verwijderd]

Als je geheugen vrij geeft, dan doe je dat omdat de gegevens op die geheugenplaats niet meer nodig/actueel zijn (lees: obsolete). Als elders in jouw code dan toch dat geheugen nog gebruikt wordt, dan is dat gewoon een kwestie van slordig programmeren. Als ik dergelijke code oplever, dan ben ik blij dat mijn programma crasht, dan kan ik tenminste de fout opsporen. Dat is toch beter dan dat het programma vrolijk doorwerkt met corrupte/obsolete data?

[Verwijderd]

Als ik dergelijke code oplever, dan ben ik blij dat mijn programma crasht, dan kan ik tenminste de fout opsporen.

Je bent blij indien dit gebeurt op je ontwikkelsysteem. Indien het gebeurt bij de eindgebruiker ben je er niks mee. Beter neutraliseren dan laten crashen dan.

Deze tool lijkt dan ook twee (positieve) zijden te hebben. Het kan het debuggen vergemakkelijken (genereert een log van de fouten), en voorkomt crashes in vrijgegeven versies.

[humbug]

Het grote probleem is dat de code niet efficient is. Vaak wordt er geheugen niet vrijgegeven (memory leaks) en vaak wordt geheugen gebruikt wat al vrijgegeven is. (Crashes)

Het is gewoon moeilijk om als sterveling goed bij te houden of een object al is vrijgegeven of niet. Zeker als je met grote projecten werkt en meerdere programmeurs. Vandaar dat "moderne" talen als C# en java gewoon zelf de rommel opruimen. Een goede garbage collection kost niet zo heel veel extra geheugen maar spaart ontzettend veel ontwikkeltijd a 100 euro het uur en maakt het programma robuster. Tel uit je winst.

[BarôZZa]

Klinkt als een soort garbagecollector zoals we die kennen van Java(en wat volgens de meeste mensen een regelrechte ramp is). Bovendien vind ik het idee van een randomized memory manager al helemaal niet zo jofel. Grote kans dat wanneer er zich dan een geheugenfout voordoet, je helemaal niet meer kan herleiden waar deze vandaan komt.

Al met al zorgt dit vooral voor een vieze programmeermethode en symptoombestreiding in plaats van het probleem aan te pakken: slechte programmeerwijze danwel programmeurs. Zelf vind ik het al jammer dat er tegenwoordig gewoon zoveel matig tot slechte programmeurs zijn. Simpelweg omdat het zo makkelijk wordt gemaakt(Visual Basic, PHP anyone?) en er veel dan al zoiets hebben van 'het werkt toch?'.

[Verwijderd]

Grote kans dat wanneer er zich dan een geheugenfout voordoet, je helemaal niet meer kan herleiden waar deze vandaan komt.

Indien DieHard alle geheugen beheert en mooi bijhoudt wat waar aangemaakt of vrijgegeven wordt dan zou het juist heel makkelijk kunnen zijn om te zien waar de fout vandaan komt! Deze tool lijkt mij dan ook het meest nuttig voor het debuggen en voor betaversies.

Ik vrees wel dat het mogelijks de kloof tussen goede en minder goede programmeurs kan vergroten. Goede programmeurs kunnen het gebruiken om fouten op te sporen en daadwerkelijk op te lossen. Minder goede programmeurs zouden het kunnen misbruiken als excuus om minder te debuggen en de fouten niet op te lossen omdat ze toch minder kwaad aanrichten...

[Parody]

Die tool is er, en heet Valgrind. Programma's die met foutieve pointers werken crashen (terecht) nog steeds, maar programma's die iets fout doen met geheugenallocatie blijven gewoon werken omdat Valgrind geen geheugen weggooit.

[Verwijderd]

Valgrind is enkel voor Linux. Windows equivalenten bestaan maar zijn veelal bijzonder duur (e.g. IBM Rational Purify for Windows).

DieHard zou een waardig alternatief kunnen bieden, en gaat bovendien verder door ook na een release fouten op te vangen. Je kan argumenteren dat die tijdens het debuggen moeten opgelost worden, maar het is nooit volledig te garanderen dat het foutloos is. Een vangnet is voor kritieke software of beta releases nog steeds zeer nuttig.

[Left]

Klinkt als een soort garbagecollector zoals we die kennen van Java(en wat volgens de meeste mensen een regelrechte ramp is)

Nou programmeer ik al een jaar of 10 in Java maar volgens de meeste mensen die ik tegenkom is de garbagecollector geen ramp, maar juist een pluspunt van Java. Ok er zijn gevallen waarin je het geheugenmanagement liever 100% in eigen hand zou willen hebben, maar dan moet je je afvragen of je niet beter je programma in C of zo zou kunnen schrijven.

Bovendien vind ik het idee van een randomized memory manager al helemaal niet zo jofel. Grote kans dat wanneer er zich dan een geheugenfout voordoet, je helemaal niet meer kan herleiden waar deze vandaan komt.

Deze memory manager is er nou juist om 'traditionele' programma's stabieler te maken die geheugenfouten verzoorzaken die erg moeilijk te traceren zijn.

Zelf vind ik het al jammer dat er tegenwoordig gewoon zoveel matig tot slechte programmeurs zijn. Simpelweg omdat het zo makkelijk wordt gemaakt

Waarom wordt het zo makkelijk gemaakt? Omdat programmeurs niet hun hele leven te besteden hebben voor het maken van het Perfercte Programma. Er zit namelijk altijd een werkgever op hun te wachten die hun uurloon moet betalen.
En als je het programmeurs minder makkelijk maakt, zoals jij lijkt te willen, gaan ze ook weer meer fouten maken.

[engelbertus]

jullie beginnen over overflows terwijl in het artikel juist geschreven wordt dat geheugen te snel wordt vrijgegeven, en te vaak.
geheugen dat niet vrij is wordt zo overschreven terwijl het mogelijk nog vrij is. ook het vrijgeven kan problemen met zich meebrengen als het al vrij is, en misschien zelfs meer tijd in beslag nemen, of bijvoorbeeld geheugen vrijgeven dat door een ander programma wordt gebruikt.

dat is dus niet slim, als dat toch gebeurt doet die infinite memory manager dus net alsof ie het geheugen vrijgeeft, en als er dan een programma geheugen nodig heeft dan schrijft ie het niet op de zojuist vrijgegeven plek, maar op een plek die allang geleden vrij is gegeven, en waarschijnlijk ook vrijgegeven zou moeten zijn, omdat bijvoorbeeld de bijbehorende bewerking al voltooid is.
dat is dus die probabiliteit. maar dar hadden ze best een nederlands woord voor kunnen bedenken. of een beter engels woord


het heeft ds niks te maken met bufferoverflows, en zodoende vindt ik dat jullie voorstraf alle nutteloze posts die daar toch overgaan 100 keer moeten overschrijven.

[Ché Mig]

Je bedoelt letterlijk overschrijven of met (al dan niet door het geheugen vrijgegeven) hoofdletters en correcte leestekens?

[Verwijderd]

Ik zie de grootste toepassing in beta-versies van applicaties. DieHard zorgt ervoor dat het niet zomaar crasht door fouten in het geheugenbeheer, maar kan ze wel detecteren en zo de ontwikkelaars verwittigen van bugs. De finale versie kan dan zonder DieHard werken met optimaal en (hopelijk) bugvrij geheugengebruik.

Trouwens, die 50-75% is denk ik enkel voor de applicatie die er gebruik van maakt. Dus voor een beta versie van een nieuwe applicatie is dat wel aanvaardbaar.

[cHoc]

mja, maar dan 50-75% kwijt zijn enkel en alleen voor de geheugen allocatie voor Firefox op Windows.....

Dan houd ik liever de ruimte vrij op mijn geheugen, al heb ik zat (2GB) en niet in de laatste plaats omdat ik geen wisselbestand gebruik met 2GB.

[WinL]

Maar wat ik dan niet snap, het geheugen in moderne besturingssystemen is toch zodanig geschreven dat de ene applicatie niet bij de andere kan? Namelijk door de i386 architectuur en de (Windows) kernel.
Als hier gesuggereerd wordt dat ik per ongeluk iets van een andere applicatie kan lezen, zou dit in wezen altijd kunnen, dit is gevaarlijk en absurd. Of wordt hier geduid op fouten van de kernel memory manager?

[BumEyes]

Het klopt wat je zegt, maar programma's geven zelf dus min of meer aan welk gedeelte van het geheugen ze gebruiken. Als een programma A te snel zegt dat hij een gedeelte van het geheugen niet meer nodig heeft, kan het dus zijn dat een programma B dit overschrijft. B heeft hier geen last van, maar A kan hierdoor crashen.
Het programma uit het artikel zorgt er dus voor dat B niet zo snel onterecht vrijgegeven geheugen van A zal gebruiken.

Naar mijn mening moet je als programmeur er gewoon voor zorgen dat je programma goed werkt en niet van zulke geheugenproblemen heeft. Als je dat niet kan of daar geen tijd voor hebt moet je maar in c# of java gaan programmeren.

[.oisyn]

maar programma's geven zelf dus min of meer aan welk gedeelte van het geheugen ze gebruiken.

Dit klopt ongeveer. Ze zeggen niet zozeer dat ze de geheugenadressen X tot Y willen gebruiken, maar meer "geef mij een geheugen blok van Z bytes", waarop het OS een stuk geheugen alloceert en dat teruggeeft.

Als een programma A te snel zegt dat hij een gedeelte van het geheugen niet meer nodig heeft, kan het dus zijn dat een programma B dit overschrijft. B heeft hier geen last van, maar A kan hierdoor crashen

Dit klopt niet. Processen hebben ieder hun eigen address space, en programma B kan derhalve niet zomaar het geheugen van programma A overschrijven. Hij kan natuurlijk wel buiten z'n buffers schrijven of een stuk geheugen te vroeg vrijgeven en daardoor (zelf) crashen, maar A zal hier nooit last van hebben.

[Darkvater]

door het geheugen zo te herindelen dat de kans dat er op plekken geschreven en gelezen wordt waar dat niet zou moeten - bijvoorbeeld daar waar een andere applicatie bezig is - geminimaliseerd wordt.

Moeten we hier nu blij mee zijn?

Dus mijn buffer overflow overschrijft nu telkens een andere applicatie op een andere plek ipv dat hij dat altijd doet op dezelfde plek...

Daar zijn we blij mee hoor

Ik vind dit maar nonsens, sorry hoor.

Volgens de makers van het programma, dat voor niet-commerciële doeleinden gratis is, worden veel programmeerfouten veroorzaakt doordat programmeurs nog steeds code schrijven alsof geheugen schaars is.

WTF? Wat wil je dan dat een programma doet? Lekker maar een GB geheugen claimen en er dan maar een soort java-memory mee spelen? Belachelijk.

[Verwijderd]

Dus mijn buffer overflow overschrijft nu telkens een andere applicatie op een andere plek ipv dat hij dat altijd doet op dezelfde plek...

Buffer overflows kunnen geen geheugen van andere applicaties overschrijven. De CPU detecteert dit en genereert een interrupt (exceptie).

[Verwijderd]

s/CPU/MMU

[Webdoc]

Het lijkt me duidelijk dat dit programma niet delen gaat overschrijven die reeds bezet zijn he...

En wat betreft je tweede opmerking - ben jij ook al zo een type die vooral wil dat als ie 2 GB memory in zijn PC heeft er zo veel mogelijk vrij geheugen in Task Manager te zien is... ? waarom koop je dan al dat geheugen???

[Darkvater]

Zodat programma's die dat geheugen ECHT nodig hebben die ook krijgen? Ik snap het nieuwe denken niet: "oh we hebben toch zat [geheugen/disk/cpu krach], laten we er lekker laks mee omgaan, als die langzaam is koopt die smuck wel een nieuw pc".

[onox]

Op zich is het wel aardig bedacht. Ik stel echter mijn vraagtekens bij de werking wanneer de hoeveelheid vrij geheugen zeer minimaal is. Dan lijkt me dat programma's dan alsnog crashen. Deze oplossing voelt naar mijn mening dan ook aan als een lapmiddel en ik denk dat je het probleem gewoon bij de root moet aanpakken en gewoon netjes en veilig moet programmeren.

[tvdijen]

Mee eens... Je moet geen onnodig geheugen gebruiken.
Af en toe vraag je je af waarom programma's zoveel nodig hebben...

[increddibelly]

Helemaal mee eens Darkvater.

veel programmeerfouten veroorzaakt doordat programmeurs nog steeds code schrijven alsof geheugen schaars is.

Dit vind ik een heel kwalijke opmerking. Aan de ene kant zitten we te mauwen dat software tegenwoordig bergen ram, disk space en cpu power vreet - maar als een developer z'n troep achter zich opruimt, dan is dat achterhaald en overdreven?
make up your bloody mind!

* increddibelly vindt dat deze quote thuishoort op fok! en niet op tweakers

[d-snp]

WTF? Wat wil je dan dat een programma doet? Lekker maar een GB geheugen claimen en er dan maar een soort java-memory mee spelen? Belachelijk.

Waarom niet? Als je een GB beschikbaar hebt (gebeurt vaak genoeg tijdens het worddocumentje schrijven) dan is dat het wel waard voor de stabiliteit die dit blijkbaar geeft.

Dus mijn buffer overflow overschrijft nu telkens een andere applicatie op een andere plek ipv dat hij dat altijd doet op dezelfde plek...

Daar zijn we blij mee hoor

Misschien ben ik goedgelovig, maar heb jij hun pdf gelezen? Het lijkt me dat als ze het zo publiceren dat het ook daadwerkelijk iets nuttigs doet..

[SuperDre]

Uhm... Omdat je een GB tot je beschikking zou hebben, wil dus echt niet zeggen dat je dat dan ook maar moet gebruiken..

Dat is dus juist 1 van de redenen waarom programma's steeds trager/logger worden, veel programmeurs houden er helemaal geen rekening meer mee en gaan er maar vanuit dat de gebruiker dan maar extra geheugen erbij moet prikken..

maar de OSsen worden ook steeds meer memoryhungry, en mensen draaien ook steeds vaker meer programma's tegelijk..

Tja, en dan maar klagen dat je computer zo langzaam is... pfff....

[Verwijderd]

Uhm... Omdat je een GB tot je beschikking zou hebben, wil dus echt niet zeggen dat je dat dan ook maar moet gebruiken..


Ik koop een game-pc met 4 GB RAM geheugen en een dikke Hardeschijf. Maar Oh-wee als WoW (voorbeeld) meer dan 512MB van mijn RAM opslurpt! Komop zeg - ik koop niet voor niets 4 GB! Ik wil geheugen in mijn PC hebben dat niets doet!

..idiote opmerking

De prestaties van applicaties zouden daar, mits er inderdaad voldoende geheugen aanwezig is, niet merkbaar onder lijden.

Het staat zelfs in het artikel, als je genoeg geheugen heb, kan je het installeren, werkt je pc stabieler.. anders laat je het toch liggen? Ik zie jullie probleem niet..

[SPee]

Zware applicaties, mogen ook veel geheugen eisen.
Maar vindt jij het normaal als bv. je Wordpad bij een leeg bestand al > 128MB gaat eisen bij wijze van vb

[houseparty]

@RichardHoman87

Ik denk dat je 'm verkeerd begrijpt.

Je wilt juist geheugen vrij hoeden voor een app die het echt nodig heeft, zoals een Game.

Laat dan evt andere apps die op de achtergrond blijven draaien dan gewoon zo weinig mogelijk geheugen gebruiken. Outlook, Zonealarm/Outpost, Anti-Virus, p2p programmatje, Speedfan, FRAPS, Daemon Tools, etc, etc, etc.

Als al dat spul tot 75% meer geheugen gaat opsnoepen, dan blijft er op een gegven moment mischien te weinig over voor je Game. Je Game moet dan gaan Swappen, waardoor jij naar een WoW diavoorstelling zit te kijken.

[TheCapK]

@superdre:

Was ook nog al verbaasd dat het mensen van MS waren die dit claimen. Daar hebben ze bij MS echt geen last van, geen gebruik maken van het aanwezige geheugen. Kijk maar naar de eisen om Vista soepel te kunnen draaien.
Niet voor niets gaf MS Acer Ferrari's weg met Vista pre-installed in de hoop goede reviews op de diverse blogsites te kunnen krijgen!

[engelbertus]

heel erg blij zie het als de prullenbak van je geheugen. jeprogramma kan toch ng die moeilijke uitkomst van die bereknening van gehuegenplek zus en zo vinden terwijl die plek al per abuis was vrijgegeven vanwege een bug.

ook de dan opgehaald waarde is dan juist, in plaats van een verkeerde waarde,ingevoged door een derde toepassing.

ik zie hier dus ook al een mogelijkheid om te exploiten.je laad een programma, zonder foute code die van plek x leest. vervolgens geef je dat vrij. dan laad je een plaatje op plek x, met daarin verborgen een fout commando. vervolgen lees je programmatje weer van plek x en opeens crasht je pc omdat de foute code nu eenmaal opdracht gaf weer plek y vrij te geven, en te overschrijven, en laat dat nou net bijvoorbeeld de driver van je grafische kaart zijn. of van de harddisk en zijn er een berg bestanden corrupt.

[Verwijderd]

Ondersteund door MS en ondersteund enkel Firefox-browser, dan denk ik dat MS niet te ondersteunend zal zijn.

[EN-IS]

er staat nergens dat het programma wordt ondersteund door Microsoft. Het is door een Microsoft-Onderzoeker gemaakt, niet door Microsoft...

Dat terzijde, wel een slimme oplossing, zo had ik het nog niet eerder bekeken, ben zelf een amateur programmeur, maar ik begrijp zeer goed wat ze hiermee bedoelen en willen bereiken...

[Verwijderd]

Ik beschouw mijzelf niet als amateur programmeur , maar ik begrijp absoluut niet wat ze bedoelen.

er op plekken geschreven en gelezen wordt waar dat niet zou moeten - bijvoorbeeld daar waar een andere applicatie bezig is - geminimaliseerd wordt.

Sorry, maar hallo, is het niet zo dat elke applicatie zijn eigen adress-space heeft en dat dit door 'paging' mbv de CPU gemapped wordt naar het juiste adress. Ik heb vroeger extreem veel assembly geprogrammeerd en programmeer nu uitsluitend Java. Ik moet zeggen dat ik hier toch de voordelen voor Java zie met zijn enorme verloop van Objecten

[.oisyn]

Trainers werken door code te injecteren in een process door een dll te laden of middels de Read/WriteProcessMemory API calls. Je kunt niet zomaar in het geheugen van een ander proces poken door per ongeluk een verkeerd adres te gebruiken. En de functionaliteit om dat af te schermen bestaat al sinds de 286, om de opmerking van the_sticky ook maar gelijk te ontkrachten. DikkeDouwe heeft het dus gewoon bij het rechte eind en verdient derhalve wel een hogere score dan een 0. De regel uit het artikel die hij quote is onzin.

[Verwijderd]

@c0d1f1ed: jij hebt zeker nog nooit een trainer voor een game gebruikt? Hoe denk je dat die (doorgaans) werken? Zolang we geen volledig NGSCB hebben vanaf moederbord tot aan OS-HAL zal je altijd het geheugen van een andere applicatie kunnen beïnvloeden.

Tot die tijd kunnen we het wel lastiger maken, maar het zou mij niets verbazen als een McAfee weer eens bij een Kroes aan de mouw zou trekken als een Microsoft het té lastig gaat maken...

[the_stickie]

neen, maar geheuegen wordt wel geadresseerd. door op de juiste adressen in het ram geheugen waardes te schrijven kan je de werking van draaiende programma's beïnvloeden en mogelijk dus ook fouten uitlokken of zelfs code injecteren.

[Verwijderd]

the_stickie: Onzin. Je kan niet het geheugen dat aan andere applicaties is toegewezen lezen of schrijven. De CPU en het besturingssysteem controleren de toegang.

[the_stickie]

de cpu doet daar nog maar sinds kort actief aan mee afaik, en het besturingssysteem kan je/kon je omzeilen. dat dit nu langzamerhand moeilijker en moeilijker wordt, is maar goed, maar het kàn heus wel hoor

[HanslH]

Zelden een zin gelezen die zo het belang aantoont van je d's en t's goed gebruiken in verband met begrijpelijkheid.

[Verwijderd]

Het werd hierboven al even vermeld, maar met Java heb je hier als programmeur geen last van. En ook daar kan je efficiënt met het geheugen omgaan.
In de onlangs gereleaste Java 1.6, werd de garbage collector (het gedeelte dat geheugen vrijgeeft als het nodig is en het systeem wat tijd over heeft) geoptimaliseerd.

[Left]

met Java heb je hier als programmeur geen last van.

Dat is onzin, ook in Java kun je met Object Pools werken, vooral als je efficiënt met je geheugen wil omgaan, en daar kun je vervolgens weer net zoveel fouten mee maken als je wilt.

[Verwijderd]

Alsof ik in mijn eerste post niet heb bijgezet dat je met java efficiënt met geheugen kunt omgaan. Feit blijft dat je met java nooit of te nimmer geheugen zal uitlezen dat reeds door jezelf werd overschreven met totaal andere data.

@SuperDre: Blijkbaar heb jij nog niet (veel) in Java geprogrammeerd. De VM houdt bij welke objecten nog gebruikt worden en welke niet, dus als je objecten wilt bijhouden dan doe je dat zo lang je wil, maar van zodra de garbage collector door heeft dat een object niet meer gebruikt wordt, zal deze het automatisch voor je opruimen als deze daar tijd en zin voor heeft. En een object wordt bijvoorbeeld niet meer gebruikt als je een variabele in een method hebt gedeclareerd en de method is volledig uitgevoerd. De garbage collector zal deze dan nadien voor u opruimen en dit wordt dus steeds efficiënter.

edit: reactie op .oisyn:
Ik ben reeds meer dan 5 jaar fulltime java programmeur, dus ik weet heus wel dat je met java slechte code KAN schrijven en dat je best je files afsluit nadat je deze opent. Dit heeft echter minder met het geheugen te maken, maar gewoon met het vrijgeven van de resource zelf. En in alle zaken die ik al gedaan heb met java, heb ik nog niet echt de behoefte gehad om een eigen implemenatie van een Collection of zo te schrijven.
De garbage collector runt inderdaad niet altijd en dat komt juist de performantie ten goede. De Virtual Machine bepaalt zelf wanneer het systeem 'tijd' heeft om verouderde objecten op te ruimen (en het geheugen dus terug vrij te geven). En dat is een beetje de filosofie erachter: Als het systeem bezig is, gaat de VM het niet belasten met vrijgeven van geheugen, zodat de applicatie sneller uitgevoerd kan worden. Echter: Als het beschikbare geheugen bijna opgebruikt is, dan zal de GC toch uitgevoerd worden om het programma niet te laten vastlopen. Daarom is het dus sowieso aangeraden om efficiënt te programmeren.
Of om het in twee zinnen samen te vatten: Het is niet omdat je in Java programmeert, dat je u van het geheugen niets moet aantrekken. Je zal echter geen ongeldige info uitlezen die reeds overschreven is met nieuwe data.

Voila... dit gezegd zijnde...

[.oisyn]

Blijkbaar heb jij ook nog nooit serieuze applicaties in Java ontwikkeld die veel met verschillende resources doen, want in Java kun je net zo goed leaken, of wil je juist helemaal niet wachten tot de VM besluit of een object niet meer nodig is zodat de resource opgeruimd kan worden.

Zo is het bijvoorbeeld niet nodig maar wel handig om files te closen voor je de referentie ernaar weggooit, als je applicatie met heel veel verschillende files werkt. De GC runt ook niet altijd, dus als je het niet doet zit je binnen de kortste keren met een gigantische shitload aan nog geopende files wat best veel systeemresources in kan nemen. Of je schrijft bijvoorbeeld je eigen implementatie van een ArrayList, die intern een Object[] bijhoudt om alle entries in op te slaan, en je vergeet een entry die eruit gehaald wordt op null te zetten zodat de referentie naar dat object gewoon blijft bestaan zonder dat de gebruiker van jouw ArrayList implementatie daar ergen in heeft (en dat object dus nooit wordt opgeruimd). En zo zijn er nog veel meer voorbeelden te bedenken.

.edit op jouw edit:

Of om het in twee zinnen samen te vatten: Het is niet omdat je in Java programmeert, dat je u van het geheugen niets moet aantrekken

Exact, en dat is precies wat SuperDre probeerde duidelijk te maken maar wat jij leek te ontkrachten

[SuperDre]

Dat zal wel, maar een fatsoenlijke programmeur ruimt gewoon zijn eigen rommel op en laat dat niet over aan anderen..

[Verwijderd]

die gozur op het plaatje ken ik!
Was een systeembeheer die in slaap gevallen was bij Mazda in Den Haag! Zal z'n naam maar niet noemen (weet niet of ie er nog werkt)

[Verwijderd]

Ik snap nog steeds niet dat je zo kunt slapen.

1. Het doet pijn aan je hoofd.
2. Het doet pijn aan je rug.
3. Het is onnatuurlijke houding.

Tja... verklaart vast ook WAAROM zo iemand zo in slaap kan vallen

/me weet dit niet uit ervaring trouwens

[Verwijderd]

het gaat hier toch ook niet over slapen... het gaat hier over crashen...

[DarkTemple]

Ik weet niet of een foetushouding zo onnatuurlijk is.

[Verwijderd]

Als jij op je 35ste nog voor 80% uit kraakbeen bestaat....

[Cameleon73]

4. En als je wakker wordt staat er QWERTY op je voorhoofd

[MaxxBass]

Nee, er staat dan : YTREWQ op je voorhoofd.. en dan nog in spiegelschrift...

[Verwijderd]

Echt niet dat ik het ben.
Heb beste uren gemaakt bij Mazda.
Maar kan me niet herinderen dat ik ooit in deze pose terechtgekomen ben.

[beany]

Ad, kijk eens goed naar dat kapsel en die zwarte gympie's. Jij bent het! Wees er blij mee... nu kent iedereen(heel tweakend NL) je!

[BamSlam_]

Wordt je zo afgebeuld als je bij Mazda werkt dan?

[Verwijderd]

nee, de foto is precies op de man zijn deadline genomen.

[beany]

He!! is dat Adje dan?

Dan was dit zeker de keer dat ie 36 uur achter elkaar door was gegaan? Maar ze beulen je niet af hoor bij Mazda, viel best wel mee