I guess because size_t is 16 bit, you cannot even create an array with more than 64k entries. Your value gets truncated to the least significant 16 bits. Also, in h/new, it says:

NOTE: Open Watcom currently does not throw std::bad_alloc on allocation failures.

Ringding wrote on 2025-04-03, 16:28:

I guess because size_t is 16 bit, you cannot even create an array with more than 64k entries. Your value gets truncated to the least significant 16 bits. Also, in h/new, it says:

NOTE: Open Watcom currently does not throw std::bad_alloc on allocation failures.

Okay... so what I'm hearing from this is that OW basically doesn't support the huge model or bad_alloc exceptions? How is the huge model useful if I can't actually allocate more than 64K memory with it?

Welcome to the wonderful world of 16bit programming 😉

You should be able to allocate more. Try an array of 30000 longs! That should be larger than 64KB.

Ringding wrote on 2025-04-03, 16:43:

Welcome to the wonderful world of 16bit programming 😉

You should be able to allocate more. Try an array of 30000 longs! That should be larger than 64KB.

Haha well I can do that but then I have to extract individual bytes from it which will slow everything down.

I guess I basically have to write my own memory manager that juggles 64K chunks or something.

Isn't there also a (storage) modifier for 'new' required or is this handled transparently?

keenmaster486 wrote on 2025-04-03, 16:37:

Okay... so what I'm hearing from this is that OW basically doesn't support the huge model or bad_alloc exceptions? How is the huge model useful if I can't actually allocate more than 64K memory with it?

I'm not a c++ guy, but it works fine in c.

wcl -mh -oneatx -2

1#include <stdlib.h>
2#include <malloc.h>
3int main(int argc, char *argv)
4{
5	unsigned char far *hugePointer = NULL;
6	hugePointer = halloc(128, 1024); // allocate 128kb
7	if(hugePointer == NULL)
8		printf("malloc failed\n");
9	else
10		printf("malloc success\n");
11	return 0;
12}

works just fine.

I too have used the huge memory model in Open Watcom / 16bit to allocate >64kb (actually enough for a 640x400x8bpp screen buffer).

It definitely works in C via standard *alloc calls as BloodyCactus states.

Hmm. Maybe I just need to use 2D arrays?

Try adding UL next to your 80000, like 80000UL (if the compiler supports this), or put the value in a DWORD variable and ensure the value is indeed stored as 80000 and not wrapped around 16 bits.

I just went back and checked my code in question, and whilst I do have large (>64kb) malloc calls, I noticed the other thing I was doing is defining large static regions as follows:

#define VRAM_END 256000
unsigned char __huge vram_buffer[VRAM_END]

Compiler flags used are:

CFLAGS = -0 -bc -d0 -ox -ml -zq

So it looks like (>64kb) declared static / globals are allocated and work just fine, as well. Your particular compiler flags may need to vary, of course.

The code in question uses an off-screen page buffer for a 640x400x256c screen, and then copies one VGA-window sized chunk to hardware at a time, incrementing the VGA window each time until the full screen is page-flipped. VESA linear framebuffer is nicer, of course, but not available everywhere.

Hmm yes, but doesn’t that inflate the executable size?

keenmaster486 wrote on 2025-04-04, 13:37:

Hmm yes, but doesn’t that inflate the executable size?

Not if it ends up in .bss
i.e., for zero-initialized memory, the executable just keeps track of how big the region needs to be at runtime, rather than explicitly storing all those zeros

and if it did, executable packer would reduce it to like 5 bytes anyway.

Ringding wrote on 2025-04-03, 16:43:

You should be able to allocate more. Try an array of 30000 longs! That should be larger than 64KB.

Not even this: operator new exists only with a size argument of type size_t, and this is 16 bits long. This seems to indicate that for dynamic huge memory allocation, you would have to use different library functions.