Xref: news-dnh.mv.net comp.os.msdos.djgpp:351
Path: news-dnh.mv.net!mv!news.sprintlink.net!simtel!harbinger.cc.monash.edu.au!dino.eng.monash.edu.au!junaid
From: junaid AT dino DOT eng DOT monash DOT edu DOT au (Junaid A. Walker)
Newsgroups: comp.os.msdos.djgpp
Subject: STACK BLITTING
Date: 14 Jun 1995 07:24:27 GMT
Organization: Monash University
Lines: 36
Nntp-Posting-Host: dino.eng.monash.edu.au
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Dj-Gateway: from newsgroup comp.os.msdos.djgpp

	Well congratulations to Charles on cwsdpmi!

	I recently ported my sprite library from linux to djgpp V2.
Works like a charm. Actually it compiles pixel maps into 386 machine 
code, puts it into a malloced buffer and executes it to blit data
to a frame buffer.
	Anyway for reasons of efficiency, stack push's are used to
blit even faster, and save space. This all works flawlessly with
cwsdpmi.

	Unfortunately MS Windows 3.11 doest let %esp (the stack pointer)
to point into malloced data (ie into data in the data segment).
Instead i get a stack fault .

	From discussions a while back, i recall that MS Win has
the a downward expanding stack. (ie the downward expand bit is set
for the ss descriptor). However the selector value for ss is the same
as ds. Surely the ds segment isnt downward expanding?


	What i was thinking was to create an alias descriptor for
ss and reseting the downward expand bit. This would give us a fixed
sized stack (perhapse we can enlarge it beforehand by lots of pushes),
which any sane program can handle.
	What are people's thoughts and experiences? What cludges
can be done to get around this 'problem'?

	Thank goodness that the data (=> stack) segements are 
executable. It turns out that gdb creates a dummy function call
on the stack before calling inferior functions. The mind boggles!

	Also i will release a demo of my sprite library in the
near future so people can get a feel for its speed.

Junaid