i have a big data section. and now i think that it became too big. at a specific number of variables (especially string variables), my app doesn't load my images correctly whose handles are defined in .data? section. here is my .data and .data? section. what's wrong?
	player SPIELER <30000,0,0,0,0,0,0,-1,982,700>
	txtplayer1name db "alloces",0
	feldernamen     db "Los",0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
			db "Badstraße",0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
			db "Gemeinschaftsfeld",0,0,0,0,0,0,0,0
			db "Turmstraße",0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
			db "Einkommensteuer",0,0,0,0,0,0,0,0,0,0
			db "Südbahnhof",0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
			db "Chausseestraße",0,0,0,0,0,0,0,0,0,0,0
			db "Ereignisfeld",0,0,0,0,0,0,0,0,0,0,0,0,0
			db "Elisenstraße",0,0,0,0,0,0,0,0,0,0,0,0,0
			db "Poststraße",0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
			db "Gefängnis",0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
			db "Seestrasse",0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
			db "Elektrizitätswerk",0,0,0,0,0,0,0,0
			db "Hafenstrasse",0,0,0,0,0,0,0,0,0,0,0,0,0
			db "Neuestrasse",0,0,0,0,0,0,0,0,0,0,0,0,0,0
			db "Westbahnhof",0,0,0,0,0,0,0,0,0,0,0,0,0,0
			db "Münchnerstrasse",0,0,0,0,0,0,0,0,0,0
			db "Gemeinschaftsfeld",0,0,0,0,0,0,0,0
			db "Wienerstrasse",0,0,0,0,0,0,0,0,0,0,0,0
			db "Berlinerstrasse",0,0,0,0,0,0,0,0,0,0
			db "Freiparken",0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
			db "Theaterstrasse",0,0,0,0,0,0,0,0,0,0,0
			db "Ereignisfeld",0,0,0,0,0,0,0,0,0,0,0,0,0
			db "Museumstrasse",0,0,0,0,0,0,0,0,0,0,0,0
			db "Opernstrasse",0,0,0,0,0,0,0,0,0,0,0,0,0
			db "Nordbahnhof",0,0,0,0,0,0,0,0,0,0,0,0,0,0
			db "Lessingstrasse",0,0,0,0,0,0,0,0,0,0,0
			db "Schillerstrasse",0,0,0,0,0,0,0,0,0,0
			db "Wasserwerk",0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
			db "Goethestrasse",0,0,0,0,0,0,0,0,0,0,0,0
			db "Ins Gefängnis",0,0,0,0,0,0,0,0,0,0,0,0
			db "Rathausplatz",0,0,0,0,0,0,0,0,0,0,0,0,0
			db "Hauptstrasse",0,0,0,0,0,0,0,0,0,0,0,0,0
			db "Gemeinschaftsfeld",0,0,0,0,0,0,0,0
			db "Bahnhofstrasse",0,0,0,0,0,0,0,0,0,0,0
			db "Hauptbahnhof",0,0,0,0,0,0,0,0,0,0,0,0,0
			db "Ereignisfeld",0,0,0,0,0,0,0,0,0,0,0,0,0
			db "Parkstrasse",0,0,0,0,0,0,0,0,0,0,0,0,0,0
			db "Zusatzsteuer",0,0,0,0,0,0,0,0,0,0,0,0,0
			db "Schlossstrasse",0,0,0,0,0,0,0,0,0,0,0
			db "Los",0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
	gem1 db "Aus Lagerverkäufen erhälst du: 500 DM",0
	gem2 db "Es ist dein Geburtstag. Ziehe von jedem Spieler 1000 DM ein.",0
	gem3 db "Du erhälst auf Vorzugs-Aktien 7 Dividende: 900 DM",0
	gem4 db "Zahle an das Krankenhaus: 2000 DM",0
	gem5 db "Bank-Irrtum zu deinen Gunsten. Ziehe 4000 DM ein.",0
	gem6 db "Die Jahresrente wird fällig. Ziehe 2000 DM ein.",0
	gem7 db "Zahle Schuldgeld: 3000 DM",0
	gem8 db "Arzt-Kosten. Zahle: 1000 DM",0
	gem9 db "Du hast den zweiten Preis in einer Schönheitskonkurrenz gewonnen."
	     db " Ziehe 200 DM ein.",0
	gem10 db "Du hast in einem Kreuzworträtsel-Wettbewerb gewonnen."
	      db " Ziehe 2000 DM ein.",0
	gem11 db "Du kommst aus dem Gefängnis frei. Diese Karte musst du"
	      db " behalten, bis du sie benötigst oder verkaufst.",0
	gem12 db "Gehe in das Gefängnis! Begig dich direkt dorthin."
	      db " Gehe nicht über LOS. Ziehe nicht 4000 DM ein.",0
	gem13 db "Einkommenssteuer-Rückzahlung. Ziehe 400 DM ein.",0
	gem14 db "Rücke vor bis auf LOS.",0
	gem15 db "Du wirst zu Straßenausbesserungsarbeiten herangezogen."
	      db " Zahle für deine Häuser und Hotels 800 DM je Haus, 2300"
	      db " DM je Hotel an die Bank.",0
	gem16 db "Du erbst: 2000 DM",0
	er1 db "Rücke vor bis zur Seestraße. Wenn du über LOS kommst,"
	    db " ziehe 4000 DM ein.",0
	er2 db "Du bist zum Vorstand gewählt worden. Zahle jedem"
	    db " Spieler 1000 DM.",0
	er3 db "Gehe zurück zur Basstrasse. ",0
	er4 db "Du kommst aus dem Gefängnis frei! Diese Karte musst"
	    db " du behalten, bis du sie benötigst oder verkaufst.",0
	er5 db "Die Bank zahlt dir eine Dividende: 1000 DM",0
	er6 db "Rücke vor bis zum Opernplatz. Wenn du über LOS"
	    db " kommst, ziehe 4000 D
Posted on 2001-06-18 14:43:00 by [-alloces-]
You can do away with "offset " in the tables of pointers. In a case such as this: string1 db "Hello",0 string2 db "Goodbye",0 stringtable dd string1,string2 MASM can figure out that the dwords are offsets. But I'm not sure if that will solve the problem here. I will have a closer look. (Edit) Does feldernamen need to be padded like that? If so, you might like to use a macro of this kind: s25 macro txt local hereweare hereweare equ $ db 25 dup (0) org hereweare db txt org hereweare+25 endm and then in your source you write: feldernamen label byte s25 "Los" s25 "Badstraße" s25 "Gemeinschaftsfeld" ... This prevents any accidental miscount of the 0's. This message was edited by Larry Hammick, on 6/18/2001 4:35:55 PM
Posted on 2001-06-18 16:06:00 by Larry Hammick
This is probably a stupid question, but do the images load correctly if the data section is not so big. If some images load and others don't could the problem be in the image loading, or displaying routine. One thought is that you forgot the padding at the end of ead row in the images. Otherewise, sorry but this wouldn't be my area.
Posted on 2001-06-18 16:42:00 by Zadkiel
@alloces: This looks like Monopoly. Am I right? :D
Posted on 2001-06-18 17:51:00 by bazik
@zadkiel:this is not a stupid question, the images load correctly if the .data section is not so big. @larry hammick: this is a great macro, i'll check that out this evening, but i'm sure that everythings ok with the zeroes. @bazik: You are right, it's a monopoly clone, but i call it "Business Master" :D so, no idea what could be the problem?
Posted on 2001-06-19 03:18:00 by [-alloces-]
Hey, If what alloces is saying is correct does it mean that u cant code big programs in asm which use a lot of .data section? I mean ok this much code in .data alloces might still be able to cut down by the use of macros and all but hwta if someone else had a program which had say,2000 more lines in the .data section. What would he do?
Posted on 2001-06-19 04:46:00 by MovingFulcrum
hey movingfulcrum, don't worry, the program works, but it doesn't load my images correctly anymore. i first thought that it would be a problem of defining the strings, but that doesn't seem the problem. if i cut some of the strings out, the images are loaded correctly again. perhaps it's just a compiler bug or something. hutch-- can you help?
Posted on 2001-06-19 05:01:00 by [-alloces-]
Hi alloces, I'm just a beginner. But what about moving all constant data strings to the .const section. Clark
Posted on 2001-06-19 05:11:00 by Superman_San
hey larry, could you please explain that macro to me in detail? and what does "feldernamen label byte" mean? how can i access the different strings in feldernamen then? superman_san: that could be an idea, but as far as i know you have to use "equ" in constants and there is only one value allowed. but i'm not sure. anyways, there must be an easy answer for my problem.....
Posted on 2001-06-19 05:27:00 by [-alloces-]
normally, the .data segment can be as large as you want. Maybe its a bug in the MASM assembler, I know iit from WASM, which assembles some shit, if a db line extents the 119. column. Maybe you can put some of the strings into a .rc file and load it dynamically via LoadString.
Posted on 2001-06-19 05:57:00 by beaster
isn't there another way to bypass .data section than defining the strings in the resource? it'd make much problems for me...
Posted on 2001-06-19 06:12:00 by [-alloces-]
[-alloces-], The only limit I have ever found in ML.EXE is the line length of a single data item which is 256 characters. I have routinely built reasonably large data section that have had text stored in them, I am thinking of about 40k or so. The way I have done it is to start a single line,

MyData db "1st line of data",
dummy0 db "2nd line of data",
dummy1 db "last line of data",0
Noting that the zero terminator is on the last line only. What I don't know is how you are reading the lines of data. It can be done at a BYTE level because the data is linear in memory and it will keep reading until the zero terminator but where you have multiple lines of data that terminate with zeros, the only way I can see it working is to know how long the length is you want to read. Regards, hutch@pbq.com.au
Posted on 2001-06-19 07:09:00 by hutch--
Hutch, it works without the dummys : MyData db "1st line of data" db "2nd line of data" db "last line of data", 0
Posted on 2001-06-19 07:49:00 by karim
hey hutch--, it seems that there is a problem with defining my string, but i don't know where the problem is. i mean, i can use every string of my choice, my problem only appears if the data exceeds a specific length. i does something with the resource file or with the handles in .data? section. i also don't know how i could debug that.... you asked how i want to access the strings when they are zero terminated not knowing their length. Larry Hammick told me how to do that:

   gemfelder dd offset gem1,offset gem2,offset gem3,offset gem4,offset gem5,offset gem6,offset gem7
        dd offset gem8,offset gem9,offset gem10,offset gem11,offset gem12,offset gem13
        dd offset gem14,offset gem15,offset gem16
   erfelder dd offset er1,offset er2,offset er3,offset er3,offset er4,offset er5,offset er6,offset er7
       dd offset er8,offset er9,offset er10,offset er11,offset er12,offset er13,offset er14
       dd offset er15,offset er16
so, if i want to have the 5th string i take the address of the sting by doing: mov eax,dword ptr erfelder easy, huh? I'm sure that you have known that...... :cool: anyway, thanks for help.....
Posted on 2001-06-19 10:47:00 by [-alloces-]
I had a similar problem, your data section is about 16k and mine was about 24k. I had to break up my db's so that none were longer then 1024 bytes. It gave me some strange problems. I don't know what that would do to you in your coding for the feldernamen array. Ewayne This message was edited by Ewayne, on 6/19/2001 8:45:45 PM
Posted on 2001-06-19 18:01:00 by Ewayne
The Section Size element of the Section Header inside the PE file is allocated 4 Bytes, allowing sections up to 4GB; the processor supports this. If you can't get section over some arbitrary limit to work, you could use multilple data sections; win32 and the processor also support this.
Posted on 2001-06-19 21:47:00 by eet_1024
I just assembled and PE (with FAsm) and had no problem with it placing a 30kB file in a data section. format PE GUI entry Start ;***---------------------------------------------------------------*** section '.data' data readable writeable Data_Blob file 'Test.txt' ;30,000 Byte file ;***---------------------------------------------------------------*** section '.code' code readable executable Start: push 0 call ;***---------------------------------------------------------------*** section '.idata' import data readable writeable dd 0,0,0,rva kernel_name,rva kernel_table dd 0,0,0,rva user_name,rva user_table dd 0,0,0,0,0 kernel_table: ExitProcess dd rva _ExitProcess dd 0 user_table: MessageBox dd rva _MessageBoxA dd 0 kernel_name db 'KERNEL32.DLL',0 user_name db 'USER32.DLL',0 _ExitProcess dw 0 db 'ExitProcess',0 _MessageBoxA dw 0 db 'MessageBoxA',0
Posted on 2001-06-19 21:58:00 by eet_1024
It is not a case of section-overflow. I once used an artificial asm source-generator to get a big symbol table into binary form. Masm had no difficulty with it, despite several thousand symbols and about 300K in one data section. But, like other people, I suspect masm is getting dispepsia in some way. In those cases there is practically always some work-around, but you might need to show us more of your source. The macro will expand into the same bytes as you have now. Therefore you can get at the individual strings (which have no names) in the same way as you are already doing. "Feldernamen label byte" just means that the data on the next line is called Feldernamen and is of byte type. There are various other tricky macros worth knowing. A section .const adds to the exe file size. I suppose it might prevent accidental overwriting of constant data, but even then, you can always put constant data in the .code section. (Of course, if you do things my way, you won't need a section .rsrc either, nor .idata, nor .edata, nor ...:))
Posted on 2001-06-19 22:26:00 by Larry Hammick

 (speaking in general).

 what is limit? try and compile/run the following code:

.model  flat,stdcall
 option casemap:none

 include 	\masm32\include\windows.inc
 include 	\masm32\include\user32.inc
 include 	\masm32\include\kernel32.inc
 includelib     \masm32\lib\user32.lib
 includelib     \masm32\lib\kernel32.lib

  buffer2      db "Is Data Limited?", 0
  buffer       db "the size of this exe could result over 1MB in size!", 0

 dbstart db "START:"
  MyData1    db 9999 dup("MYDATA___1   "), 0dh, 0ah
  MyData2    db 9999 dup("MYDATA___2   "), 0dh, 0ah
  MyData3    db 9999 dup("MYDATA___3   "), 0dh, 0ah
  MyData4    db 9999 dup("MYDATA___4   "), 0dh, 0ah
  MyData5    db 9999 dup("MYDATA___5   "), 0dh, 0ah
  MyData6    db 9999 dup("MYDATA___6   "), 0dh, 0ah
  MyData7    db 9999 dup("MYDATA___7   "), 0dh, 0ah
  MyData8    db 9999 dup("MYDATA___8   "), 0dh, 0ah
  MyData9    db 9999 dup("MYDATA___9   "), 0dh, 0ah
 dbend   db ":END"

             invoke MessageBox, NULL, addr buffer, addr buffer2, MB_OK
             invoke ExitProcess, NULL
 end start

 and then use any hex editor and look into the exe. you'll see
 that all data are compiled flawless. and the app run nonetheless.

 so, if .data is limited, then why did masm bothered to compile
 all those dummy data?

Posted on 2001-06-19 22:58:00 by disease_2000

 SIG(speaking in general):

 every app has its own 4GB(i don't know how this is possible when
 you only have 32/128 or 256MB of ram) right?

 I can see that you use GIF algorithms in your program. I wouldn't
 dare reask, but Zadkiel said that it could be the displaying
 routine. My guess is that the more data you have in your .data
 section, the higher the address increase and it might affect
 your algorithm (one that does the displaying, during calculation

 or could it be that the way you organize your data make it hard
 for masm to parse?

 could one little mistake in the end destroys the whole thing?

 anyway, it's just a guess...

Posted on 2001-06-19 23:16:00 by disease_2000