Hi All,

I have a problem with 4.3.10. Al programs seem to build ok on my system (DJGPP and Win XP), but crash on startup. I think it is a problem with linear framebuffer, my own VESA code finds that linear framebuffer is not possible but it seems like Allegro is trying to use it anyway. Here is a stacktrace..

I havent used this forum before, normally I would send to the developers mailing list, but sometimes the mailing list webpage (search/browse) is unusabely slow for me.

Best regards,

Doug Eleveld

General Protection Fault at eip=0009fa8d
eax=0014de01 ebx=000000fe ecx=00000004 edx=0014de58 esi=00000054 edi=000cd200
ebp=0014d038 esp=0014d038 program=D:\COMPILER\DJGPP\CONTRIB\ALLEGRO\TESTS\TEST.E
XE
cs: sel=01a7 base=02ac0000 limit=0016ffff
ds: sel=01af base=02ac0000 limit=0016ffff
es: sel=01af base=02ac0000 limit=0016ffff
fs: sel=0000
gs: sel=01bf base=00000000 limit=0010ffff
ss: sel=01af base=02ac0000 limit=0016ffff
App stack: [0014d200..000cd200] Exceptn stack: [000cd158..000cb218]

Call frame traceback EIPs:
0x0009fa8d __farnspokeb+9
0x00068705 __linear_putpixel8+184
0x00019349 _putpixel+53
0x0002283e __handle_mouse_input_end+166
0x000239ec _install_mouse+835
0x000126ee _main+737
0x0009e378 ___crt1_startup+176

Can't we have the piece of code that produce all that shit ?

Do you know if the problem appears in older versions? The only change to vesa.c in the last two years was to silence some gcc warnings, which I was a bit wary to commit but the submitter said it worked for him. It's attached. It could be something else, though.

Sorry, I hadn't been more explicit, the stack trace is from the tests/test.exe program. It crashes at startup.

Earlier version of Allegro, I used to use 4.2.2, didnt have this problem.

I just checked that it doesnt seem to be a problem with dos/vesa.c. If I replace the 4.3.10 dos/vesa.c with that from 4.2.2, I still get the same crash.

Any suggestions as where to look?

There really weren't many changes in 4.3.10 relative to 4.2.2, as far as the Allegro library was concerned (it was mainly integrating the addons). So I really don't know. Have you compiled 4.2.2 with a recent toolchain just to check that it isn't a problem introduced by using a newer compiler?

Maybe it happens because ASM is disabled in 4.3?

Last I checked, DJGPP and XP didn't play very well together...

Disabling ASM shouldnt cause crashes on XP, should it? I tried to re-enable ASM by rooting around in makefile.dj but never got anything to build. I guess there has been some bit-rot of the ASM code so trying to re-enable is rather pointless.

I'll keep looking around, but really dont understand Allegro internals that much.
- I noticed between 4.2.2 and 4.3.10 the GFX_TABLE is has gotten bigger.
- Also the cdefsXXX.h files have changed. This would affect putpixel I assume.

Gnolam is right. Stop using DJGPP.

For a long time ASM was almost always used, while the alternative C code was hardly ever used, and thus hardly tested. Once we disabled the ASM permanently, stuff was broken. And some still could be in certian circumstances.

Reminds me.. People love autotools so much that the dependency generation script used by allegro, was completely broken for who knows how long till I tried doing some automatic builds on my server. It should be fixed in 4.3.10+ though (new script, the old was just odd).

I belive he's a DJGPP dev... Could be wrong though, but I remember him from comp.lang.djgpp (or whatever the group's name is).

I don't think that changes anything.

I dont understand your point.
DJGPP is still on the list of supported platforms.
Should we just pretend that there is no bug?

Unless he was testing DJGPP itself with common libs on common platforms.

DJGPP is a DOS compiler. Allegro supports it just fine, but you're trying to run the resulting program on a WinXP platform, and Windows has long since abandoned DOS compatibility. This is not a matter of DJGGP-Allegro not working; it's a matter of DOS-Windows.

Sigh, what specific matter are you talking about? 4.2.2 worked just fine on XP but 4.3.10 does not. The DOS-compatability issues did not change, Allegro did. If you know what has changed in Allegro that causes this new problem, I'd like to hear it.

I just found out that doing:
make test ALLEGRO_USE_C=1 DEBUGMODE=2
on 4.2.2 causes the same crash in _farnspokeb.
So it appears that the problem is in the C code.

Frankly, I think it was a fluke that your earlier programs worked.

Ok, it makes sense now. The C-only mode was originally designed for the Unix ports. Until recently even the Windows port didn't work in C-only mode. We probably just didn't test enough (or at all) on DOS when flicking the switch for 4.3.10.

If someone can fix it, that would be best. Otherwise I suppose we'll just revert to asm-mode for the DOS ports. Not so great for long term maintainability, but the DOS ports are pretty much on life support as it is.

I think this involves the least amount of work. Not ideal as you say, but in terms of portability it's not too bad: any system running DOS will be compatible with the ASM code anyway.

I suppose nobody will mind if I keep trying to get DJGPP to run on XP with C-only. I hope somebody who knows more about internals can help me. If it works I guess its a positive for maintainability, right?

It is starting to look like a selector problem. The _default_ds() function is used for the bitmap selector which in turn gets used in the farnspoke functions for pixel setting. But the C-only version of _default_ds always returns 0, this is probably wrong. I tried changing _default_ds() to return _my_ds() and this puts the crash at other points during OS yielding (related to mouse movements?) or at gfxmode changes. Maybe _my_ds() isnt being set right for these situations. Does anyone have a quick summary about what selectors are set and when?

Second question: If people really thought the ASM code was going to be unused, why was it still in the distribution? Shouldn't it have been deleted?

Probably, but at least in this case it helped prove that the C code is broken.

It will be, but until we do the default setting was changed from having it enabled to having it disabled. This makes sense because it's easier to revert if needed (as in this case) and is less work overall.

Which is exactly what I meant to say, and didn't. good thing we have more eloquent people here

Ass kiss everyone ? ;-p

Nah. Just stating a fact.

That was humour, man, but now you are seriously kissing butts X-D

I was more self depreciating there than anything to be honest. You should probably learn the difference

Sure, and I add that you already know what kind of humour mine is ;-p

Sure, but I wouldn't call it humor

It's because you don't know me IRL. Now come get a drink @ Lyon , France !
I am waiting for ya man ;-p

Don't post here if you have nothing on topic to say.

Um, well, in 4.3 ASM is not only disabled by default but also not maintained any more and broken. I didn't want it deleted because this evil ASM thing penetrated into every Allegro pore and cannot easily be removed. It would cause destabilization of a rather stable branch. Heck, only disabling it causes problems.

Wouldnt you try to do it, just piece by piece? Take one function of the ASM code, rewite it in C and test. Repeat until done. I'll play a bit to see if this is possible. Is this the wrong way to go about it?

We only had a mechanism to disable it all at once. So we used that. We had C code prior to that, but it seems now that it hasn't all been tested as much as we'd have liked (it was written for non x86 platforms mainly, but in a way that should work for any C platform).

Allegro uses some custom calling convention when ASM is enabled so the code cannot be combined... It's either ASM or C.
But one thing is still not clear to me: Are you actually trying to run a program under WinXP compiled with DJGPP?

Repeated for explititness

DJGPP on XP was never a supported combination with Allegro. For a while, DJGPP itself had issues running on XP, let alone complex DJGPP apps. Most people that come in and ask about DJGPP and XP move along quickly to mingw as if nothing changed, and they generally have fewer problems (you get better hardware support with the windows code, some things are even hardware accelerated with the windows code).

So when is Allegro dropping DOS support?

All of the ports with no maintainer were removed from 4.9. The only ones left so far are Windows (new D3D9 driver, and new GL driver), OSX (GL \o/) and Unix (GL ftw).

Also note, there is currently no Software implementation available for many functions.

It's not been actively maintained for years, but all the old code is still there in the 4.2/4.3 branches. If someone uses DOS, finds a problem and can provide a simple fix, fine. Removing it constitutes extra work.
No one is willing to do work for Allegro 4.9/5, so that's where DOS support is actively dropped.

Yes, to be clear I am using a DJGPP compiled Allegro program on XP. Apparently other peoples experience has been quite different than mine, for me it has always worked flawlessly. If it aint broke dont fix it. I only use graphics and input, no sound or timers so my view may be somewhat biased.

Different calling conventions between the C and ASM stuff is unfortunate. This could be why by initial attempts to change the bank switching code to C always segfault.

I wont get into here on this thread about why i think dropping DOS support is a bad idea. IIRC, there is an old piece by Shawn Heargraves which sums my view up quite well.

Theres a reason it wasn't dropped in 4.2 and 4.3.x, but in 4.9, the only reason its not there, is noone is here to do the work. Anything without an active maintainer was removed for 4.9 as its essentially a rewrite, and the old code just wouldn't fit with the new api.

If someone really wants DOS support for 4.9/5, they will make sure it gets done. Otherwise, they must not really want it

I think the point is that DJGPP compiles programs that will run in DOS and XP only emulates DOS (and poorly at that). If you want to run a program on WinXP , why not compile a win32 executable file using MinGW (Minimalist Gnu for Windows)? It's based off of gcc just like DJGPP but compiling win32 executables is what MinGW was made for.

Allegro 4 can still be used for years to come, if your game has to work also on DOS platforms. (edit: And the many experienced allogroers won't wipe their memory when they start using v5, so you can still get some support on your v4 programs)

Since Allegro 3, I've seen how dense the Allegro documentation has become because of platform differences, so I welcome the drop as it means the docs of v5 can be written more easily, with a tighter result.

Erm, mind you someone has offered to support DOS in 4.9 once:
http://sourceforge.net/mailarchive/message.php?msg_name=BAY105-F15D25EF0DC14B30124742C86740%40phx.gbl
So saying that the only reason we don't support DOS is that we have no one to work on it is a lie. Apparently, event and input subsystems cannot be implemented in DOS.

Just because you offer, doesn't mean it got done And obviously, it didn't.

I don't see why it can't work, it doesn't need to use threads, the event system should work just fine in a pure poll mode.

Somoene just has to do it. And one person saying they'd like to do it is kinda like "noise".. You get many people volunteering for stuff on a OpenSource project that never deliver for one reason or another.