Re: NewEra: NE_DATA segment

dwc@cix.compulink.co.uk (David Chan) wrote : dw>The NE_DATA problem can be solved by breaking up the application into dw>DLLs and moving global/shared variables into these DLLs. I'm not too dw>sure dw>whether the cause is the use of complex types. I suspect it is the use dw>of global/shared variables. We don't use that much global variables, just one that references a class that has many constants as members wich are very often used. I watched the size of the NE_DATA segment in the .map file and noticed it increased when i added a member of type ixString to one of the used classes. It also increased when adding a new function. What we used often is a VARIABLE- statement in the pre_body of our wifs, this is almost everytime a VARIABLE xyz RECORD LIKE tab.* statement. Can this be the cause ? dw>The p-code problem could be the same as above but it is more likely to be dw>the 64k limit on function name space in your 4gi. In which case, use dw>DLLs or shorten your function/handler names so that the total length fits dw>inside 64k. How do i split up a program into DLLs ? This is not mentioned anywhere in the onlinehelp. Can i put a whole program part including windows into a dll or just small functions ? --- _ // Tom Beuke Mail : tob@blanker.ruhr.de _ // Westhoffstr.13-15 Tel. : +49 231 839757 \\X/ 44145 Dortmund --- 5 Kilometer zum Nachbarn, 18 Kilometer zum Arzt, 889 Kilometer zur Tochter, 3 Schritte zum Telefon, 2000,-DM Telefonrechnung im Monat ...