Request for C version of asmlock.s

Request for C version of asmlock.s

Troels K

Member #4,252

January 2004

Hi,
If you provided MSVC project (.dsp/.dsw) files in the Allegro distribution - and translated asmlock.s to C - then MSVC users would be able to build Allegro without installing anything else...and without going over http://www.allegro.cc/files/install-msvc.html !

I've created a MSVC project for Allegro, with
ALLEGRO_NO_ASM and ALLEGRO_USE_C. Sadly it's a no-go until asmlock.s gets translated...
http://code.trak.dk/allegro_msvc.zip

makefiles isn't everybody's cup of tea.

/Troels

Oscar Giner

Member #2,207

April 2002

that zip only contains the MSVC project and workspace and a file contrib/initguid.c

--
[Website | e-mail]
[Tetris Unlimited] [AllegAVI | AlText]

Troels K

Member #4,252

January 2004

The rest is here:
http://prdownloads.sourceforge.net/alleg/all4112.zip?download

Evert

Member #794

November 2000

If you build Allegro using only C (ie, ALLEGRO_USE_C), then you shouldn't need a C version of any assembler file. What do you need a C version of asmlock.s for? Why doesn't it work with ALLEGRO_USE_C?

On a side note, this was discussed a long time ago and there was some talk of trying to get the C only version of teh library to compiel with MSVC. I'm glad someone is now looking into that.
That said, the C only version of the library is considerably slower than the optimized version, so I don't think this is particularly useful in itself.

Troels K

Member #4,252

January 2004

>If you build Allegro using only C (ie, ALLEGRO_USE_C),
>then you shouldn't need a C version of any assembler file.
This seems to be almost true.

>What do you need a C version of asmlock.s for? Why doesn't it work with ALLEGRO_USE_C?
What do I know?! The linker barks over these unresolved externals, all implemented in asmlock.s:

allegro.lib(wgdi.obj) : error LNK2001: unresolved external symbol _gfx_gdi_unwrite_bank
allegro.lib(wgdi.obj) : error LNK2001: unresolved external symbol _gfx_gdi_write_bank
allegro.lib(wddwin.obj) : error LNK2001: unresolved external symbol _gfx_directx_write_bank_win
allegro.lib(wddwin.obj) : error LNK2001: unresolved external symbol _gfx_directx_unwrite_bank_win
allegro.lib(wddwin.obj) : error LNK2001: unresolved external symbol _gfx_directx_unlock_win
allegro.lib(wddwin.obj) : error LNK2001: unresolved external symbol _gfx_directx_write_bank
allegro.lib(wddbmp.obj) : error LNK2001: unresolved external symbol _gfx_directx_write_bank
allegro.lib(wddwin.obj) : error LNK2001: unresolved external symbol _gfx_directx_unwrite_bank
allegro.lib(wddraw.obj) : error LNK2001: unresolved external symbol _gfx_directx_unwrite_bank

>C only version of the library is considerably slower...
>I don't think this is particularly useful in itself.
While developing and debugging - using the IDEs integrated debugger - it's good to have only C code to singlestep into. Especially when using a code library new to you. When deploying, you can switch to using the official dll (which have no debug information inside).
Ensuring that your app works both when linking with the static+debug+C version of Allegro, as well as when linking with the official 'retail' dll, is one good success criteria, I think. C programming is not without pitfalls....

>trying to get the C only version of teh library to compiel with MSVC.
Consider it done, albeit slightly unsuccessfully.
Here's the project I'm trying to build, complete with Allegro source and all.
http://code.trak.dk/download/allegro_cpcem.zip (3.5MB)
It yields the aforementioned unresolved external errors. If anybody finds a remedy...

/Troels

Evert

Member #794

November 2000

Quote:

This seems to be almost true.

No, it is completely true. Allegro runs on Apples and I've run it myself on Sun computers.
However, I think I spot the problem. Those are all non-Windows ports, and build process probably figures that Windows => Intel => assembly versions can be used.
Regardless of wether or not doing a full build with MSVC, requiring assembly files to beprocessed even when ALLEGRO_USE_C is defined seems like a bug or oversight to me though. If noone can confirm or check this (I'm not in Windows, so I can't try it), I'll post it on the developer mailing list.

Quote:

While developing and debugging - using the IDEs integrated debugger - it's good to have only C code to singlestep into. Especially when using a code library new to you. When deploying, you can switch to using the official dll (which have no debug information inside).

Unless you're developing Allegro (in which case MSVC alone is not going to suit your purposes) you shouldn't need to single step into Allegro code. In fact, you probably don't want to.

Troels K

Member #4,252

January 2004

>No, it is completely true. Allegro [C only version] runs on Apples...non-Windows ports
Yes, it appears to be a shortcoming of the Windows port.

>If noone can confirm or check this (I'm not in Windows, so I can't try it),
>I'll post it on the developer mailing list.
Thanks.

>Unless you're developing Allegro (in which case MSVC alone is not going to suit your purposes)...
I agree.

>...you shouldn't need to single step into Allegro code. In fact, you probably don't want to.
Do you really advocate using this library as a black box?! An unusual point of view.
Linux users might have a thing or two to say on black boxes. Such as Windows.

>>While developing and debugging - using the IDEs integrated debugger
>>Ensuring that your app works ...is one good success criteria
One more argument for the C only version (as supplement):
A library that compiles right out of the box makes a very favourable first impression.
(A library that doesn't compile right out of the box does not.)

Evert

Member #794

November 2000

Quote:

Do you really advocate using this library as a black box?!

For the purpose of programming and debugging your own game or application, yes. I certainly don't want to step through an Allegro function when debugging my own code.
If there's a problem, Allegro's code in probably not the reason. Besides, Allegro's code itself can be complicated if you're unfamiliar with it, and it's not generally helpful to single step through code you do not understand.

Quote:

Linux users might have a thing or two to say on black boxes.

I am a Linux/UNIX user.

Quote:

A library that compiles right out of the box makes a very favourable first impression.

Sure. But Allegro does compile out of the box and always has - just not with MSVC, but that's because it wasn't originally designed for that particular compiler.
You just need to follow the instructions.

Troels K

Member #4,252

January 2004

>I certainly don't want to step through an Allegro function when debugging my own code.
If one happens to be uncertain about the meaning/interpretation of some parameter you're passing to some function, you can either grep for the function - or debug into it.
With an IDE debugger, debugging is quick and easy - and you get live data!

>But Allegro does compile out of the box and always has - just not with MSVC
...which is very popular, to put it mildly. Naturally I'm all for free tools, but if a library is going to be successful, it must facilitate mainstream (curious, new) users to some extent.
The MSVC project/workspace would be a boon to Allegro...

Evert

Member #794

November 2000

Quote:

If one happens to be uncertain about the meaning/interpretation of some parameter you're passing to some function, you can either grep for the function - or debug into it.

I think the manual would be the place to look, personally. Stepping into a function just to find out what some of the parameters do seems to me a strange way to go about this.

Quote:

...which is very popular, to put it mildly.

Which is why there is an end-user package for MSVC.
The average new user won't be interested in compiling his own library (at least I wasn't when I started to learn about programming and could just about get my own projects to compile).
For experienced MSVC programmers, this might be a bit different, but even then, building Allegro isn't that hard for an experienced user. There are tradeoffs for a cross-platform library, and in the case of Allegro, it's an involved way to build on one very platform-specific compiler.
There'd be a way to alleviate the problem though - convert all of Allegro's assembly to intel syntax so that MSVC can use it directly. But unless someone is willing to sit down and actually do that, it's not going to happen.

Anyway, I posted the question on the mailing list, pointing to this thread. Depending on how much work it is to rewrite the Windows drivers in C, someone may or may not want to work on this.

Troels K

Member #4,252

January 2004

It's not like I want to have the last word or anything. But!

>>If one happens to be uncertain about the meaning/interpretation of some parameter
>I think the manual would be the place to look, personally.
Documentation and code constantly gets out of sync, that's the way it goes in an
imperfect world. You get burned by documentation occasionally. The debugger tells it like it is. The debugger is a great tool...

>The average new user won't be interested in compiling his own library
I'm not so sure. The sceptical new user (and I hope he is) will ask questions
like, is the entire source code for this library included as promised, does this library pull in other libraries, and if so, are the other libraries included - or otherwise accessible; if I include all4112.zip in my backup scheme, do I really have all I need to rebuild everything years on (using MSVC or whatever's at hand), everything being my app and the library itself. The documentation might say sure, yes, everything's good and safe, and that might satisfy the trustful programmer. To other programmers, seeing is believing...

>I posted the question on the mailing list, pointing to this thread.
I for one appreciate it. Thanks!

>how much work it is to rewrite the Windows drivers in C,
>someone may or may not want to work on this.
Apparantly all that is needed for a clean MSVC compilation/linking of Allegro is a C version of src\win\asmlock.s. I'm sorry I'm not the one to do it...

Evert

Member #794

November 2000

Quote:

Documentation and code constantly gets out of sync, that's the way it goes in an
imperfect world.

Have you looked at Allegro's documentation? It's rather thorough and it is something that is very closely monitored whenever a change is made or a feature is added.
Sure, there are things that are not documented, but those are mostly internal things that shouldn't concern the average programmer.

Quote:

The documentation might say sure, yes, everything's good and safe, and that might satisfy the trustful programmer. To other programmers, seeing is believing...

In other words, you don't trust the docs?

Quote:

Apparantly all that is needed for a clean MSVC compilation/linking of Allegro is a C version of src\win\asmlock.s. I'm sorry I'm not the one to do it...

Nor me obviously. And as long as noone with the ability to do that actually does it, it's not going to happen.
Anyway, there is a more serious problem here.

Eric, in reply to my e-mail said said:

> It seems that Allegro still needs to build .s files on Windows, even if
> the C only version of the library is requested - or am I missing
> something?

No, you're right.

> It is no big deal for me personally, but it seems to me inconsistent.

Sort of. The docs say "Allows you to build the library using C drawing code
instead of the usual asm routines".

> The main benefit would probably be insignificant - it would be possible to
> build Allegro with MSVC only, but without the hand-optimized code and
> therefore likely slower.

Yes, and the C-only DLL would be incompatible with the regular DLL because of simplified asm calling conventions for bitmaps.

> On the other hand, it may be easier for newbies who insist on compiling the
> library themselves but can't be bothered to install MinGW.

There is a trickier dependency on GCC: the makefiles use very long command
lines that regular Win32 apps can't grok. You need a stub compiled with GCC
to properly handle them.

(my emphasis) So I guess a true MSVC-only port isn't really feasable with just C code, as I'd hoped it might be.

Troels K

Member #4,252

January 2004

>Yes, and the C-only DLL would be incompatible with the regular DLL because of >simplified asm calling conventions for bitmaps.

ALLEG41.DLL and say ALLEG50.DLL needn't have identical interfaces.

>the makefiles use very long command lines that regular Win32 apps can't grok

The MSVC scenario is completely without makefiles.
(http://code.trak.dk/download/allegro_cpcem.zip)

Apparantly all that is needed for a clean MSVC compilation/linking of Allegro is a C version of src/win/asmlock.s.

Evert

Member #794

November 2000

Quote:

ALLEG41.DLL and say ALLEG50.DLL needn't have identical interfaces.

We're not talking about different versions of Allegro here, we're talking about the same version and hence (in principle) the same DLL, but compiled differently, resulting in incompatibilities. That is bad, because a program expecting the C-version DLL will die on the asm version and vice versa.

Either the DLL would have to be named differently, or the MSVC C only library should be static link only.

Troels K

Member #4,252

January 2004

I'm proposing to change 'simplified asm calling conventions' to __cdecl or Pascal, projectwide, in upcoming versions.
A tedious job that would bring the library in step with the rest of the world...

Fallout2man

Member #4,279

January 2004

I too would like to have an MSVC project file (DSP/DSW or VCPROJ/SLN) for building the library. The main reason I want to do this is so I can use the MSVC's options to easily specify what optimizations and such I want run to compile the DLL.

I'm not entirely sure what all was said, but what exactly is needed to make a project? I tried myself but kept getting compile errors about non-constant initializers and such.

It seems just a bit inconsistent to claim MSVC support yet require additional software to compile it.

Nothing against the MinGW implementation of the GCC, it's good and all, but frankly don't hold a candle to the MSVC in terms of making fast and optimized code.

Evert

Member #794

November 2000

Quote:

I'm not entirely sure what all was said, but what exactly is needed to make a project? I tried myself but kept getting compile errors about non-constant initializers and such.

An assembler that can assemble AT&T style assembler files, which MSVC's cannot.

Quote:

It seems just a bit inconsistent to claim MSVC support yet require additional software to compile it.

Allegro is a cross-platform and cross-compiler library. Since the default Windows toolset is very limited and the MSVC one is mostly incompatible with others, that kind of thing is more or less inevitable anyway.

Quote:

Nothing against the MinGW implementation of the GCC, it's good and all, but frankly don't hold a candle to the MSVC in terms of making fast and optimized code.

The MSVC version uses the commandline version of MSVC to compile C code and MinGW (or DJGPP) to handle the hand-optimized assmebly.

There is noone who says MSVC support could not be improved, but it will require a rewrite of all hand-written assembly code in Allegro to do it properly. And unless someone is willing to do that, theentrire discussion is rather pointless.

Fallout2man

Member #4,279

January 2004

The problem with the command line MSVC is I can't reinstall it and my current MSVC directory has spaces in it. This is why I hoped for a project file of some kind, as the only other option would be someone smart adding support for spaces in names to the windows ports of the GNU tools (which is something that also would be very nice).

I could always just take a pre-built DLL but as I said I wanted to get a fully optimized MSVC version with compile flags I intended, not something someone else made. Just a bit stringent on that, heh. So as you can see I'm dependent entirely on another way to get allegro to compile on my box. Thanks for explaining the assembly issue.

Troels K

Member #4,252

January 2004

>MSVC support...will require a rewrite of all hand-written assembly code in Allegro
Still, the minimum requirement for compiling Allegro using MSVC seems to be a C version of only the file asmlock.s

Evert

Member #794

November 2000

Quote:

Still, the minimum requirement for compiling Allegro using MSVC seems to be a C version of only the file asmlock.s

Resulting in a slower version because you can't use the hand-optimized assembler. That means that you'd need to prevent people from distributing the C only DLL, even if it were binary compatible with the optimized one, or only allow it to build a static link library.

Again, I think it'd be a neat idea and a step closer to native MSVC support, but it is not on the same level asa full native port.

Fallout2man

Member #4,279

January 2004

I tried simply renaming the .s files to .C in the MSVC then adding __asm { at the start of assembly code, closing with } at the end. Yet for some strange reason using either _asm or __asm on these files generates a syntax error.

Here's a snippet from the build log

Quote:

ispr8.c
c:\allegro\src\i386\ispr8.c(25) : error C2059: syntax error : '__asm'
ispr32.c
c:\allegro\src\i386\ispr32.c(23) : error C2059: syntax error : '__asm'
ispr24.c
c:\allegro\src\i386\ispr24.c(23) : error C2059: syntax error : '__asm'
ispr16.c

Strangely it always says __asm even if I use _asm in the code. Any reason why exactly this seems to occur and these assembly files can't simply use the inline assembler? I also remember there being an example on the MSDN about how to use Assembly files in tandem with C files in a project, probably will need to look that up.

One other note: With how highly optimized (current) MSVC code is, as well as the fact it can be set to use specific instructions such as SSE or MMX, why should speed be such an issue, it might even be faster then the hand-made code because it can take advantage of more hardware capabilities across the board, and can also be built to use SSE2.

Evert

Member #794

November 2000

Quote:

Don't bother. Allegro's assembler code is written in AT&T syntax. MSVC uses Intel syntax. If either were different, then there'd be no problem and MSVC could compile Allegro on its own just fine.
As it stands, you need an AT&T style assembler (ie, the GNU one) and then link the resulting object files with MSVC.

Quote:

With how highly optimized (current) MSVC code is, as well as the fact it can be set to use specific instructions such as SSE or MMX, why should speed be such an issue, it might even be faster then the hand-made code because it can take advantage of more hardware capabilities across the board, and can also be built to use SSE2.

I think Allegro uses SSE2 if available already. It certainly uses MMX and SSE.

Don't underestimate the ability of good programmers (ie, Bob) to optimize assember code - no compiler is capable of the level of optimization that a human can do.

Fallout2man

Member #4,279

January 2004

Not necessarily, not saying that's true in this case but eventually computers are going to pretty much do everything better then we can :p

and where can I find something that'd list the differences between AT&T and Intel syntax? I'm no assembly coder but if it's just syntax issues I imagine that with enough time I could at least convert asmlock.s and then maybe try the other files later.

Evert

Member #794

November 2000

Quote:

eventually computers are going to pretty much do everything better then we can

Dream on

Quote:

where can I find something that'd list the differences between AT&T and Intel syntax?

A quick google turned up this: [url http://www.astrolox.com/?text=attintel]; you may be able to find more.

Fallout2man

Member #4,279

January 2004

It's true, they already have computers that can process faster then the human brain. Once we make the right algorithms they'll do everything better, it's just making those algorithms will take a very, very long time.

Anyway, just finished my first try at porting asmlock.s to intel syntax, remember I know nothing of how to truly do assembly programming, just used http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/gnu-assembler/i386-syntax.html as a reference and went from there.

1/*         ______   ___    ___
2 *        /\  _  \ /_ \  /_ \
3 *        \ \ \L\ \//\ \ //\ \      __     __   _ __   ___ 
4 *         \ \  __ \ \ \ \  \ \ \   /'__`\ /'_ `/\`'__/ __`\
5 *          \ \ /\ \ _\ _ _\ _/\  __//\ \L\ \ \ //\ \L\ \
6 *           \ _\ _/____/____\ ____\ ____ \ _\\ ____/
7 *            /_//_//____//____//____//___L\ /_/ /___/
8 *                                           /____/
9 *                                           _/__/
10 *
11 *      Asm functions for Windows bitmap locking.
12 *
13 *      By Isaac Cruz.
14 *
15 *      Improved dirty rectangles mechanism by Eric Botcazou.
16 *
17 *      See readme.txt for copyright information.
18 */
19 
20 
21#include "src/i386/asmdefs.inc"
22 
23 __asm {
24.text
25 
26 
27/* gfx_directx_write_bank:
28 *  edx = bitmap
29 *  eax = line
30 */
31FUNC (gfx_directx_write_bank)
32 
33      /* check whether bitmap is already locked */
34      test BMP_ID[edx], dword ptr BMP_ID_LOCKED
35      jnz Locked
36 
37      /* lock the surface */
38      push dword ptr ecx
39      push dword ptr eax
40      push dword ptr edx
41      push dword ptr edx  /* argument */
42      call GLOBL(ptr_gfx_directx_autolock)
43      pop dword ptr edx
44      pop dword ptr edx
45      pop dword ptr eax
46      pop dword ptr ecx
47 
48   Locked:
49      /* get pointer to the video memory */
50      mov eax, dword ptr BMP_LINE[edx,eax,4]
51 
52      ret
53 
54 
55 
56 
57/* gfx_directx_unwrite_bank:
58 *  edx = bmp
59 */
60FUNC (gfx_directx_unwrite_bank)
61 
62      /* only unlock bitmaps that were autolocked */
63      test BMP_ID[edx], dword ptr BMP_ID_AUTOLOCK
64      jz No_unlock
65 
66      /* unlock surface */
67      push dword ptr ecx
68      push dword ptr eax
69      push dword ptr edx
70      push dword ptr edx  /* argument */
71      call GLOBL(ptr_gfx_directx_unlock)
72      pop dword ptr edx
73      pop dword ptr edx
74      pop dword ptr eax
75      pop dword ptr ecx
76 
77      /* clear the autolock flag */
78      and BMP_ID[edx], dword ptr ~BMP_ID_AUTOLOCK
79 
80   No_unlock:
81      ret
82 
83 
84 
85 
86/* gfx_directx_write_bank_win:
87 *  edx = bitmap
88 *  eax = line
89 */
90FUNC (gfx_directx_write_bank_win)
91      push dword ptr ecx
92 
93      /* clobber the line */
94      mov ecx, dword ptr GLOBL(wd_dirty_lines)
95      add ecx, dword ptr BMP_YOFFSET[edx]
96      mov [ecx,eax], byte ptr 1   /* wd_dirty_lines[line] = 1; (line has changed) */
97 
98      /* check whether bitmap is already locked */
99      test BMP_ID[edx], dword ptr BMP_ID_LOCKED
100      jnz Locked_win
101 
102      /* lock the surface */
103      push dword ptr eax
104      push dword ptr edx
105      push dword ptr edx  /* argument */
106      call GLOBL(ptr_gfx_directx_autolock)
107      pop dword ptr edx
108      pop dword ptr edx
109      pop dword ptr eax
110 
111   Locked_win:
112      pop dword ptr ecx
113 
114      /* get pointer to the video memory */
115      mov eax, dword ptr BMP_LINE[edx,eax,4]
116 
117      ret
118 
119 
120 
121/* gfx_directx_unwrite_bank_win:
122 *  edx = bmp
123 */
124FUNC (gfx_directx_unwrite_bank_win)
125 
126      /* only unlock bitmaps that were autolocked */
127      test BMP_ID[edx], dword ptr BMP_ID_AUTOLOCK
128      jz No_unlock_win
129 
130      push dword ptr ecx
131      push dword ptr eax
132 
133      /* unlock surface */
134      push dword ptr edx
135      push dword ptr edx  /* argument */
136      call GLOBL(ptr_gfx_directx_unlock)
137      pop dword ptr edx
138      pop dword ptr edx
139 
140      /* clear the autolock flag */
141      and BMP_ID[edx], dword ptr ~BMP_ID_AUTOLOCK
142 
143      /* update dirty lines: this is safe because autolocking
144       * is guaranteed to be the only level of locking.
145       */
146      mov edx, dword ptr GLOBL(forefront_bitmap)
147      call update_dirty_lines
148 
149      pop dword ptr eax
150      pop dword ptr ecx
151 
152   No_unlock_win:
153      ret
154 
155 
156/* gfx_directx_unlock_win:
157 *  arg1 = bmp
158 */
159FUNC(gfx_directx_unlock_win)
160 
161      /* unlock surface */
162      mov edx, dword ptr 4[esp]
163      push dword ptr edx 
164      push dword ptr edx  /* argument */
165      call GLOBL(ptr_gfx_directx_unlock)
166      pop dword ptr edx
167      pop dword ptr edx
168 
169      /* forefront_bitmap may still be locked in case of nested locking */
170      mov edx, dword ptr GLOBL(forefront_bitmap)
171      test BMP_ID[edx], dword ptr BMP_ID_LOCKED
172      jnz No_update_win
173 
174      /* ok, we can safely update */
175      call update_dirty_lines
176 
177   No_update_win:
178      ret
179 
180 
181 
182/* update_dirty_lines
183 *  edx = dd_frontbuffer
184 *  clobbers: %eax, %ecx
185 */
186 
187#define RECT_LEFT   [esp]
188#define RECT_TOP    4[esp]
189#define RECT_RIGHT  8[esp]
190#define RECT_BOTTOM 12[esp]
191 
192update_dirty_lines:
193      push dword ptr ebx
194      push dword ptr esi
195      push dword ptr edi
196      sub esp, dword ptr 16  /* allocate a RECT structure */
197 
198      mov RECT_LEFT, dword ptr 0
199      mov ecx, dword ptr BMP_W[edx]           /* ecx = dd_frontbuffer->w */
200      mov RECT_RIGHT, dword ptr ecx
201      mov ebx, dword ptr GLOBL(wd_dirty_lines) /* ebx = wd_dirty_lines   */
202      mov esi,dword ptr BMP_H[edx]           /* esi = dd_frontbuffer->h */
203      mov edi, dword ptr 0  
204 
205   _align_
206   next_line:
207      mov al, byte ptr [ebx,edi]  /* al = wd_dirty_lines[edi] */
208      test al, byte ptr al         /* is dirty? */
209      jz test_end            /* no ! */
210 
211      mov RECT_TOP, dword ptr edi
212   _align_
213   loop_dirty_lines:
214      mov [ebx,edi], byte ptr 0   /* wd_dirty_lines[edi] = 0  */
215      inc dword ptr edi
216      mov al, byte ptr [ebx,edi]   /* al = wd_dirty_lines[edi] */
217      test al, byte ptr al         /* is still dirty? */
218      jnz loop_dirty_lines   /* yes ! */
219 
220      mov RECT_BOTTOM, dword ptr edi
221      lea eax, dword ptr RECT_LEFT
222      push dword ptr eax
223      call GLOBL(update_window) 
224      pop dword ptr eax
225 
226   _align_
227   test_end:   
228      inc dword ptr edi
229      cmp esi, dword ptr edi  /* last line? */
230      jge next_line    /* no ! */
231 
232      add  esp, dword ptr 16
233      pop dword ptr edi
234      pop dword ptr esi
235      pop dword ptr ebx
236      ret
237 
238 
239 
240/* gfx_gdi_write_bank:
241 *  edx = bitmap
242 *  eax = line
243 */
244FUNC (gfx_gdi_write_bank)
245      push dword ptr ecx
246 
247      /* clobber the line */
248      mov ecx, dword ptr GLOBL(gdi_dirty_lines)
249      add ecx, dword ptr BMP_YOFFSET[edx]
250      mov [ecx,eax], byte ptr 1   /* gdi_dirty_lines[line] = 1; (line has changed) */
251 
252      /* check whether bitmap is already locked */
253      test BMP_ID[edx], dword ptr BMP_ID_LOCKED
254      jnz Locked_gdi
255 
256      /* lock the surface */
257      push dword ptr eax
258      push dword ptr edx
259      push dword ptr edx  /* argument */
260      call *GLOBL(ptr_gfx_gdi_autolock) 
261      pop dword ptr edx
262      pop dword ptr edx
263      pop dword ptr eax
264 
265   Locked_gdi:
266      pop dword ptr ecx
267 
268      /* get pointer to the video memory */
269      mov eax, dword ptr BMP_LINE[edx,eax,4]
270 
271      ret
272 
273 
274 
275/* gfx_gdi_unwrite_bank:
276 *  edx = bmp
277 */
278FUNC (gfx_gdi_unwrite_bank)
279 
280      /* only unlock bitmaps that were autolocked */
281      test BMP_ID[edx], dword ptr BMP_ID_AUTOLOCK
282      jz No_unlock_gdi
283 
284      /* unlock surface */
285      push dword ptr ecx
286      push dword ptr eax
287      push dword ptr edx
288      push dword ptr edx  /* argument */
289      call GLOBL(ptr_gfx_gdi_unlock) 
290      pop dword ptr edx
291      pop dword ptr edx
292      pop dword ptr eax
293      pop dword ptr ecx
294 
295      /* clear the autolock flag */
296      and BMP_ID[edx], dword ptr ~BMP_ID_AUTOLOCK
297 
298   No_unlock_gdi:
299      ret
300}

Edit: How the hell do you make a link and specify a name for it other then the URL? it's really annoying having it showthe long URL when I wanted to add a simple this as the name.