Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » Config files

This thread is locked; no one can reply to it. rss feed Print
Config files
DanielH
Member #934
January 2001
avatar

I have a slight situation. I want to use the config file functions for loading information, but I need the information before I load allegro.

I've tried loading allegro. Getting information from file and close allegro. Then go about running as normal. It errors automatically. Is there something that allegro does that won't allow itself to be started twice in the same prog?

Zaphos
Member #1,468
August 2001

If you call install_allegro with SYSTEM_NONE and a null atexit_ptr the first time, do you still have the problem?

Edit: hmm, can't replicate your problem. What are you doing besides reading/writing the config files each time?

spellcaster
Member #1,493
September 2001
avatar

My mame front does shutdown allegro everytime before it calls mame, then restarts it as soon the mame has finished. It does work, so I guess something fishy is going on.
You can use the config file routines once you have called install_allegro() which shouldn't have any side effect on your code, since it doesn't create a window, etc.

Could you post the smallest possible program you can reproduce your error with?

--
There are no stupid questions, but there are a lot of inquisitive idiots.

Evert
Member #794
November 2000
avatar

I think the CVS version of Allegro can load configfiles without having to call install_allegro() first.

DanielH
Member #934
January 2001
avatar

Do I need to call allegro_exit?

Zaphos
Member #1,468
August 2001

Do you mean, do you need to call allegro_exit before having called install_allegro? Why would you need to do that?

DanielH
Member #934
January 2001
avatar

    install_allegro( SYSTEM_AUTODETECT, &errno, &atexit );
    set_config_file( LOLO_CFGFILE );
    fullscreen = ( get_config_int( "System", "fullscreen", 1 ) == 1 );
    width = get_config_int( "System", "width", 800 );
    height = get_config_int( "System", "height", 600 );
    depth = get_config_int( "System", "depth", 32 );

    allegro_message( "%s %d %d %d", ( fullscreen ? "fullscreen" : "windowed" ), width, height, depth );

    allegro_exit();

After this I go about creating a window without allegro, but using GDI in win32.

I've also tried
install_allegro( SYSTEM_NONE, &errno, NULL );
with no luck

***********************************
Ok I narrowed it down to this

win_set_window( hWnd );

The window was created and here is where it exits the program.

I think it might have something to do with the internal variable
_allegro_count
when allegro is installed then the variable is incremented, but never decremented when allegro closes.

***********************************
I included aintern.h and decremented the variable myself and it works fine now.

Does anybody see anything wrong with this?

Evert
Member #794
November 2000
avatar

Quote:

I think it might have something to do with the internal variable
_allegro_count
when allegro is installed then the variable is incremented, but never decremented when allegro closes.

Sounds like a bug to me.

BAF
Member #2,981
December 2002
avatar

why do you have to kill allegro to make the window?

DanielH
Member #934
January 2001
avatar

Aren't you supposed to win_set_window before allegro_init? And shouldn't I kill allegro before calling allegro_init again?

BAF
Member #2,981
December 2002
avatar

oh i see, i didnt know when you had to call those functions.

Evert
Member #794
November 2000
avatar

Quote:

Does anybody see anything wrong with this?

I don't think _allegro_count is meant to be decremented ever. It looks like some code in install_allegro() could break if you do.
Can you try the attached patch instead?

DanielH
Member #934
January 2001
avatar

I'm not recompiling allegro when it is a bug.

When I call allegro_exit, that should clear anything allegro related from memory. So If I decide to do anything else with allegro there should not be any crashes.

Steve Terry
Member #1,989
March 2002
avatar

I agree, upon allegro_exit() the _allegro_count variable should be decremented. This should be done in the next release or so of allegro :)

___________________________________
[ Facebook ]
Microsoft is not the Borg collective. The Borg collective has got proper networking. - planetspace.de
Bill Gates is in fact Shawn Hargreaves' ßî+çh. - Gideon Weems

Evert
Member #794
November 2000
avatar

Quote:

I'm not recompiling allegro when it is a bug.

I need to know if my patch fixes the problem, though. I'm not going to apply it if it isn't tested.
So please (someone) test if it solves the problem :)

Quote:

When I call allegro_exit, that should clear anything allegro related from memory. So If I decide to do anything else with allegro there should not be any crashes.

This is what the patch aims to fix, yes.

Quote:

I agree, upon allegro_exit() the _allegro_count variable should be decremented.

I don't nescessarily agree. From src/allegro.c:

/* flag for how many times we have been initialised */
int _allegro_count = 0;

It counts how often Allegro has been initialized. This doesn't imply that the variable should be decreased when Allegro is deinitialized (although I do agree that that would make some sort of sense).
Whoever wrote that code (Shawn himself, I think) probably had an idea and had a reason for not wanting to decrement the variable. Without going through all the system drivers and testing all of them, there's no way to know what (if anything) will get broken when the variable is ever decremented. One obvious bit is in install_allegro() itself though:

   /* install shutdown handler */
   if (_allegro_count == 0) {
      if (atexit_ptr)
   atexit_ptr(allegro_exit_stub);
   }

   _allegro_count++;

There is no way to unregister a function registered with atexit(). Decreasing _allegro_count will install the exit function multiple times. It is written in such a way that this is actually safe, but it is still undesirable to register it multiple times.

And yes, the code could probably be rewritten to remove the _allegro_count variable or do what it does in a different way that also solves the problem. This requires a lot more work across different platforms though. More hands make light work though, so if anyone cares to look at the code in detail and make a patch...

DanielH
Member #934
January 2001
avatar

Ok. I'll try it. Just how to you use patch? Where do you get it? I am using mingw.

Evert
Member #794
November 2000
avatar

You'll need the patch utility. I think it's a standard tool with MinGW, but I could be mistaken. Otherwise, it's probably in a package called something like diffutils.
Save the diff in Allegro's main directory (as patch.diff, say) and from there run `patch -p0 < patch.diff' and then rerun make. It isn't a big change though. If you don't have diffutils installed, you are probably easier off applying the patch manually: you can open it in an editor and from the file that needs to be patched (src/win/wwnd.c I think) remove the lines that start with a - in the .diff and insert those starting with a +.

EDIT: Or you can replace src/win/wwnd.c with the attached version and recompile.

DanielH
Member #934
January 2001
avatar

I'm using 4.0.3 and that wwnd.c was too different than my wwnd.c. I manually copy it over. I downloaded some unix-style utilities and things fell apart when compiling allegro. Alot of couldn't find files for .....

I removed those utilities and allegro compiles fine now. After changing the file my program works now without having to decrement the variable.

Now what do I do now? If I distribute my program, will I need to distribute my alleg40.dll that has the change?

Evert
Member #794
November 2000
avatar

Quote:

After changing the file my program works now without having to decrement the variable.

Great! Thanks for testing. I've committed the patch to CVS.

EDIT: To both 4.1 and 4.0 branch. The patch actually applied almost cleanly to the 4.0 tree, although there were quite a few warnings, only one of the changes actually failed.

Quote:

If I distribute my program, will I need to distribute my alleg40.dll that has the change?

Either that, although distributing modified DLLs is officially discouraged, use the next WIP release, or wait for 4.0.4

Personally, I'd probably staticlink in this case. If you do distribute a modified DLL, you'll have to tell people they really need to have yours rather than the official one, at least until 4.0.4 comes out.

Go to: