Memory problem with Borland C 3.1

Hi….
Sorry for my English and for my question but I’ve very big problem!!

This is my first question in this forum, but I’ve a very big problem. I’m writing a code for Borland C 3.1 that has a function with the following prototype:

Code:

---

Void Retrun_string (int byte1, int byte2, char *ptr)

---

The function take in input the 2 byte and wrote, in output, to a char pointed by ptr pointer a string:

Code:

---

Char *other_string[25];

---

My problem is that in this fuction there are lots of string allocation (more than 64K), all string vector are of the type:

Code:

---

const char *string[] = {
                “string1”,
                “string2”,
                ……
                “stringN”,
}

---

I’ve lots of this vector because I need to make lots of correspondence between the two bytes and the string. And I use this way for making an easier:

Code:

---

Strcpy (ptr, string[n]);

---

The problem is that I must work in a windows 98 space with a Borland c 3.1 (1991). I found on the web that with this kind of workspace there is lots of memory problem because this compiler (that works in MSdos emulation on win98) doesn’t allowed more than 64k of memory. When I run my program I’ve a runtime error in the memory that every times changed and is not periodic but very random. Sometimes my program run without problems, some times all the system crashed, like a MATRIX screensaver. I note that I wrote (random) in lots of parts of memory system for example so0metimes “I” wrote in the keyboard memory, or in the video memory or in the system memory. If I’m lucky the system tell me that I’m trying to access to a reserve and critical part of the memory.

I can’t use an extern file for downloading on runtime the needed string. If I run the program with out my fuction (all the fuction commented) I’ve not problems, nothing. If I run with the entire string vector commented I’ve not running problem. I think the problem are the strings!

When I run my executable file on a winxp workstation I’ve fewer problems… but I must work on 98 systems…. I tried to working with out a pointer in my fuction, but I’ve the same problems. I tried changing with this other fuction:

Code:

---

Static char string2[25];
Retrun_string (int byte1, int byte2)
{
        ….
        Strcpy (string2, string[n]);
}

---

I found on te web lots of people with memory troubles in Borland C, very similar to mine. Lots of people migrate to Borland 5 or made a file where put all the string, but I can’t!

You should be able to use more than 64K of memory by using "large memory model" and "far" pointers.

--
Mats

I don't find the option "far" pointers.. i've only found far data, are the sames?

In more i've found that i've the 80286 instruction set....
I can at the maximum setting 80386 instruction set.. but i've a pentium architecture.

far is an extra keyword in 16-bit x86 compilers, which tells the compiler that this pointer constists of two 16 bit values:
- an offset
- a segment
Together these can address any address 0..1MB [exactly 0..1MB+64K-16 - but for most purposes, you can ignore that last bit, as there is a huge hole at 640K..1MB in DOS].

In "large" mode, all pointers are "far".

http://en.wikipedia.org/wiki/C_memory_model

--
Mats

Unfortunally i'm already in large mode...

I've checked my make file.. and i've the tag specifier in the option

-ml

If i'm in large mode, now i've also far pointers.

So you should be able to use large chunks of memory (bigger than 64K).

You are not, by any chance, creating these string variables on the stack, are you? That wouldn't work, I think. Or perhaps you can if you use "huge" memory model - I can't quite remember all the details.

Actually, searching for "borland C huge" turns up this:
http://www.binarica.com/data/about/bc201.html

If that's not helping, please provide more info:
What exactly is the error message(s) that you get?



--
Mats

I don't get message error.. during runtime my system crashed.. only sometimes i get a message error from windows 98: access memory falied.

I think all variables are created when i run the program in the stack. maybe i've not understand your question..

Is there ANY reason you can't actually port this to a 32-bit Windows Console application?

--
Mats

As yet, you've yet to post any code which seems capable of being compiled, let alone being run.

Also, there seems to be at least one place where you messed up on the parameter type, based on the parameter being passed, and another place of not pointing to allocated memory.

Post some actual code which demonstrates the problem (as best you can anyway).

Even in the large memory models, the size of any single object is still limited to 64K, so if you have many thousands of strings in your array, that might be a problem.

i've something around 2000 string of ~20 byte.

40K byte sigh

In more i've the other parts of the program running and the compiler...

Still, if this is for Win98 or newer systems, you do not need to use Borland C - plenty of freely available 32-bit compilers to solve the problem, and then your 64K limit becomes 2GB limit, which is much less of a hindrance.

--
Mats

I tryed to migreta my software to a "modern" borland C that hasn't this kind of problem, like borland C++ 5, that works on windows space.. but i've a problem conversion with a fuction on my code.

This is not a my code, but a old source created for borland c++, and exatly i've a traslation problem between Borland 3.1 to Borland 5.1 in an interrupt fuction, i try telling you if you can helping me to translate this fuction to new borland standard i think i could resolving my problem:

void Inizializza_Linea_L_(void interrupt (*proc)());
void Inizializza_Linea_K_(void interrupt (*proc)());

I think the compiuler doesn't accept this kind of fuction protoip and this is the main fuction of all the source, but is a low level fuction.. and i think could be very dangerous to modify this fuction, bouce in the end my .exe run in a particolar space, in an other .exe program, with a particolar socket that, unfortunally, i don't know. But if is easy to modify this code, i can try to modify.

What sort of things do those "interrupt" functions do in the old version of the program?

Is an interrutp from a serial or USB (depends) device with an apposit firmware inside, that i can't modify or see the code. That's is why i don't wan to modify a lot the structure of my program.

In Win32, you no longer have to worry about the low-level detail of handling each byte being transferred to/from some piece of hardware.

For instance, to access a COM port, you would begin with CreateFile and a filename like "\\\\.\\COM3"
Then scroll down to Communications Resources and carry on reading and following links.

> That's is why i don't wan to modify a lot the structure of my program.
To be honest, I might think about starting again.
If you're working with some old software, which has a history of being modified by many different people over a number of years, then it's going to look pretty horrible in places. It will contain all sorts of 'DOS-hacks' necessary to make it work on DOS (eg. interrupts, worrying about 64K limits etc), and may even contain large amounts of dead code. It may also implement some features which are no longer needed.

Attempting a line-by-line translation of that to Win32 will retain much of that, and add another layer of confusion for future maintainers.

But if you do rewrite it in Win32 from scratch, then it will be a nice clean implementation which would be a solid base for future development and enhancement. You keep the old program as it stands as a reference to work to.

In Turbo C and C++, the size of a single object can exceed 64K, according to the reference book "The Waite Group's Turbo C++ Bible", by Barkakati.

You can do that by using a memory model that supports it, if (and only if), you have enough physical (or virtual memory given to the program, from an OS like Windows).

The book mentioned has examples of all the Turbo C/C++ key words, in versions 1.0, 1.5, and 2.0.

From what I've just read, it basically makes 2 or more memory blocks, appear like one large memory block, to the programmer.

I heartily recommend grabbing a copy of this book, if you can find it. It's a treasure trove of everything in early Turbo C/C++, with examples for darn near every single thing.

This is the Turbo C/C++ Bible's example for allocating 80,000 bytes:

Code:

---


#include <stdio.h>
#include <stdlib.h>
#include <alloc.h>

int main()
{
  int far *bigblock;
  if ((bigblock = farmalloc(80000L)) == NULL)
  {
      printf("Memory allocation failed!\n");
      printf("\n\n Press Enter ");
      getchar();
      exit(1);
  }
  printf("Block of 80,000 bytes allocated at &#37;Fp\n", bigblock);
  printf("\n\n Press Enter");
  getchar(); 

  return 0;
}

---

This program will not run in the Tiny memory model. If successful, it returns a far pointer to the allocated block of memory. If not, it returns NULL.

I played with this for awhile with WindowsXP using the IDE. I couldn't get it to work, but I'm not experienced with messing with all the compiler options, command line interface for it, and etc.

I found what was the problem...

My fuction and all my part of cade was called by an interrupt fuction. And this was the problem, becouse in the old machine and especially with my old compiler is very dangerous to call a fuction (a big fuction like mine) with lots of memory allocated and with lots of matematics operation.. But was not easy to found that my code was called by an interrupt fuction!