Win32 systems implement the segmentation model for virtual memory. The 6 segment registers (the lower 14bits of each) are used as section selectors. This allows for 16384 (2^14) sections. Each section can be up to 4GB (2^32). Therefore your system can address up to 64TB of virtual memory. Windows has a swap file for everything that doesn't fit into RAM. If you have a very large HD, you can use this much of memory, but you system will run very slow. Info from "The 80x86 IBM PC and Compatible Computers" Mazidi & Mazidi
Posted on 2001-06-19 23:34:00 by eet_1024
If this problem comes on particular 'magic' data lenghts, my assumption is that is could be a MASM bug in alignement, producing a bad section header. If true, the solutions could be: - Use a good Open Source Assembler. Example, SpAsm strings can be the length you want, and be multi-Lines when "double-quoted". - Align your Data. Data should always be aligned on their own boudary. Unaligned Words and dWords are double memory access time, anyway. You can do this either by writing all your dWords first, then your Words, then your Bytes Data, or by setting some Align 4 where required. - Fix the bug in MASM. Hopefully, as MASM is GPL free, instead of having to do this difficult task by yourself, you just have to ask Bill Gates. He is back to programming these days.
Posted on 2001-06-20 03:47:00 by Betov
Rene :), perhaps you should learn to write in a real assembler like MASM before you try and criticise it. Being GPL free and written directly by the Evil Empire may rub you the wrong way but it still outperforms the rest at the moment, libraries written in MASM, modules, direct compatibility with Microsoft C, excellent minimum size with proper PE files. MASM has a 256 character line limit in the .DATA section but it is easy to get around the problem. I have working software that has strings in excess of 40k that are problem free so I suggest that the problem in [-alloces-] program come from the GIF loader, not the .DATA section. Regards,
Posted on 2001-06-20 04:16:00 by hutch--
i agree with hutch. the compiler doesn't tell me something that there is an error, so the problem has to be something else. as the images don't load correctly, i think it has something to do with the giflib. i'll try to load the images in bmp format and see if it works. i'm gonna tell you if it worked afterwoods. wish me luck! if there is a problem with the giflib "we"'ll have to fix it. bye
Posted on 2001-06-20 08:04:00 by [-alloces-]
It's probably the giflib. I noticed some very stupid bugs in my program (some procedures didn't save registers esi/edi/ebx :rolleyes:). I've updated the lib, you can download the latest revsion at my site: Thomas
Posted on 2001-06-20 12:44:00 by Thomas
hey, i tried loading bitmaps instead of the gifs and everything worked fine. then i tried to load the gifs from file and not from the resource and again, everything worked fine. so there's a problem in loading the gif from the resource. even your new version isn't working exagone, sorry. :(
Posted on 2001-06-20 13:12:00 by [-alloces-]
perhaps one of the code gurus can have a look at exagones giflib source, especially the procedure where the gif is loaded from resource file? that would be very nice
Posted on 2001-06-20 13:15:00 by [-alloces-]
I also remember that giflib has problems with gifs created by some specific programs. Try loading your GIF in paint shop pro or mspaint (not tested with mspaint but psp works), then save it again. Or send me the GIFs and I'll look at it. Thomas
Posted on 2001-06-20 13:37:00 by Thomas