Windows XP Service Pack 2

[Tom Salter]

I've been eyeing this up for a while, and it's looking very interesting. However, there's one thing that's going to be a bit of a ****ter...

Applications that attempt to violate execution protection will receive an exception with status code STATUS_ACCESS_VIOLATION (0xC0000005). If an application requires executable memory, it must explicitly set this attribute on the appropriate memory by specifying PAGE_EXECUTE, PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE or PAGE_EXECUTE_WRITECOPY in the memory protection argument of the Virtual* memory allocation functions. Heap allocations using the malloc() and HeapAlloc() functions are non-executable.

****, there goes most of my uni work. :\

[Valken]

All 3 people who can fully understand MS' convoluted text feel your pain :P

Perhaps a little more background info?

[Tom Salter]

From what I can gather, I think old C-style malloc'd programs may need recompiling - possible with a new implementation of malloc to specify where you actually malloc to.

Still, from reading through the spec sheets, seems like we might have lots of problems with 3rd party apps.

RPC service has many security updates, if people can be arsed to use them

[Valken]

Ah, understood.

I know enough Windows programming to know I'm glad I stuck to Unix based stuff in both college and my career!

*continues in blissful ignorance*

Still though, regarding your predicament

[Tom Salter]

Yeah - good job it uses GLUT rather than Win32 so I can still compile it on Lunix machines

Can anyone else confirm this though? It seems that malloc may take more parameters to ensure you allocate it in the right section of the heap.

[Valken]

It's an OpenGL project eh?

How do you find using GLUT? It's a great little framework for making graphics stuff without worrying about Win32 or X11 programming but I found it a little restrictive for making anything more than little demos.

I'm an SDL fan myself... another nicely platform independant library.

What's the project anyway?

I dunno about what extra parameters you might need for malloc... surely they'll make the changes as transparent as possible though :S

[Tom Salter]

Nah, it's nothing I'm doing at the moment, I was thinking about some older work of mine I'd done. Especially a bump-mapper engine I'd written - implementing the complete pipeline in software, so it used LOTS of mallocs, especially after textures/maps.

I quite like GLUT when you get used to it, and learn how to use the different screen modes such as GLUT_GAME_MODE (read: fullscreen mode). It's quite tidy, but like you say, not great for anything but demos (which most of my uni projects were).

I hear SDL's nice, I'll have to learn more about that.

My DirectX stuff though...I'll have to read more into this problem.

I dunno about what extra parameters you might need for malloc... surely they'll make the changes as transparent as possible though :S

This IS Microsoft

In the end though, I don't have to use SP2 :P I was thinking more about how this could possibly affect the millions of programs out there.

[Valken]

Indeed GLUT game mode is quite handy and it's a nice little api but after spending a few years using SDL I've grown quite fond of it.

It's much more versatile and much more low level in many way.

It also lets you directly access the framebuffer if you wish... kind of useful for rendering huds in 2D with alpha blending without having to switch modelview and projection matrices to draw in 2D using OpenGL

It's also got additions image, network and audio libraries that I find attractive... think of it like a low-level directx style api without the nastyness (IMO) of using microsofts COM+ architecture (which I find a little unintuitive tbh)

This IS Microsoft

I know, I know... I guess I'm always too optimistic for my own good. Still, I haven't actually upgraded to XP when running in Windows

[Tom Salter]

Yeah, I should learn how to use SDL.

I even got into QT a while back, when I tried to write a level editor, which was quite nice.

Hmm, I'm sure there was a command in standard OpenGL to access the framebuffer? Or am I being really, really forgetful?

[Valken]

Yeah, you can indeed do it in OpenGL using getpixel or readpixel or something... it's a little fiddly and can hurt performance.

With SDL you can just blit other "surfaces" directly into the framebuffer much quicker than doing it pixel by pixel yourself.

It's useful for render to texture stuff though.

[Tom Salter]

Yeah, glReadPixels the one I was thinking of

Blitting could be handy - especially for creating cool effects. Again, I'll have to look into that.

[Papercut]

From what I can gather, I think old C-style malloc'd programs may need recompiling - possible with a new implementation of malloc to specify where you actually malloc to.

nah, from what I understand they're talking about killing nasty performance kludges that involve manipulating the working set to avoid paging.

if they had broken mallocs then most of the software out there would stop working.

It affects the win32 Virtual* memory allocation functions as mentioned, nothing else I'd have thought.

... unless you're loading machine code into malloc'd memory space and trying to execute it.

* digs around *

It won't affect you unless you're doing some nasty low level hacking, see here:

http://msdn.microsoft.com/security/productinfo/XPSP2/memoryprotection/execprotection.aspx

[Tom Salter]

... unless you're loading machine code into malloc'd memory space and trying to execute it.

Yeah, I dug around last night and I see what it does now.

Basically, some worms work by malloc'ing memory, then putting binary code into it, then incrementing the CPU's Program Counter to the memory space of the code you inserted. You can't execute code in the page file now (or so I think).

*phew* :P

However, we just installed this at work (the beta) and it's b0rked some of our in-house programs. :\

[Papercut]

Basically, some worms work by malloc'ing memory, then putting binary code into it, then incrementing the CPU's Program Counter to the memory space of the code you inserted.

no, no, no. The services being attacked do the memory allocation, a worm just takes advantage of a buffer overrun bug to inject machine code.

You can't execute code in the page file now (or so I think).

Of course you can! You just can't dynamically generate code on the fly and run it without flagging the memory space used as executable. It should really only affect driver coders and nasty performance hacks, as mentioned.

It took me 5 mins to figure this out, n00b

[Tom Salter]

No, you can only do this by setting the appropriate flags.

If an application requires executable memory, it must explicitly set this attribute on the appropriate memory by specifying PAGE_EXECUTE, PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE or PAGE_EXECUTE_WRITECOPY in the memory protection argument of the virtual memory allocation functions.

And my worm explanation was massively smiplifed :P