Hello Everyone,
A bit late to these posts (I'm getting slower in my older age ). I've been working on a utility dll library for fasm for quite some time now. The firsts versions of this library were used to translate some directdraw code from the book 'Windows game programming for dummies' (and on to two other books and there code). But in the last few months I've been adding more new code to this library and as of now has a good selection of functions. It just needs a double check of the main documentation files, and a good turtorial and it will be ready to release for you people to try and report back any bugs that you have found, and features you would like added. The library is named currently 'TurboAsmDX', and Below is a quick-reference of the functionality, the dll, and the source code to the library. In the past few weeks, I've stopped adding new features in order to convert a good selection of includes from the latest windows sdk. Of which I will also upload shortly, also.
MadMatt

Reverend:
1. of course don't push everything always. "preserve" means leave unchanged.
3. string i want are compatible with zero-terminated strings, they just only carry more information with them, like

on second thought ( ) i would be best to use fresh's string library.

altough it makes it harder when working with strings directly, it contains lot of useful code, and also rewriting whole Fresh or having another string library for Fresh wouldn't be very nice. and it fixes many common problems, mainly resizing string.

it's already written, tested, quite independent (it only requires heap funcs) , so i definitively vote for it.

Problem comes out with naming (again and again), i think i'd be fine to keep fresh/windoze way (MemAlloc, StrCat), so Fresh doesn't have to be changed too much to use the library. Maybe we can add name-prefix separator (as Reverend suggested), like "Str.Len", "Mem.Alloc" (i used to use this way too) but it would require changing all names for Fresh to use the library.

Without adding separator, problem comes with names like "HeapAlloc", eg. which are already name of win32 imports. Maybe "MemHeapAlloc?"

PS: Sorry about reopening name issue again , but i found out it really DOES matter when you try to write something. (malloc, MemAlloc, Mem.Alloc, mem.alloc )

I was about to suggest Fresh StrLib. Thanks vid

how about the names? Do you think names like StrLen, MemAlloccan can work out (altough they make problems with things like HeapAlloc)?

vid, you can get rid of buffersize field, if you will allocate memory in the chunks of constant size.

For example, buffersize is always string length rounded up to 256 bytes:



In this case, buffer size can be easily calculated as



Checking for buffer overflow and increasing buffer is very fast and short too. This idea can be generalized, so you can make buffersize some function of string length (say, round it to the nearest power of 2).

By the way, a lot of Win32 API returns the number of characters copied to the buffer, so converting from null-terminated Win32 strings to FASM strings seems to be an easy task. Just wrap Win32 functions such as GetWindowText in your own macros returning FASM strings:



There are a lot of such functions, but wrapping is routine and trivial. May be, it could be done with FASM macros?

nice idea
but somebody would have to write code...
i think this is a little better than Fresh's library, it doesn't have to reallocate memory after each byte added to string.

Some good iteas, but I like the maxlength field to be in the record, somewhere.

To have a general purpose, multi-platform library, you will need a memory manager. It would be a good idea to tie in 'string' memory with the general memory.

Example, you allocate a 'string' of 300 bytes, the string allocation function calls the general memory function, and adds it's own fields to it.

gen. memory record:

next_chunk
prev_chunk
next_segment
prev_segment
size (offset -4 for general memory, acts as string_maxlength at offset -

ends.

start of string record:
string_length (offset -4)
data (offset 0)
zero-termination

ends.

The memory manager would allocate heap memory from the system in 64k segments (or requested amount to nearest 64k), then break the segments up into chunks as needed.

All library routines that use buffers and strings would naturally have to use the library memory manager.

It's higher overhead, but that's the price to pay for having code that compiles under multiple OSes.

You'll have 2 allocation and 2 freeing functions:

malloc - allocates memory for general memory
free - frees allocated memory

stralloc - allocates memory for general memory + string memory
strfree - frees string memory

Or if one prefers (such as me); mem.alloc, mem.free, str.alloc, str.free
Or, without dots; mem_alloc, mem_free, str_alloc, str_free

for example win32 already has memory manager, no need to write ours. i was thinking about:
mem.alloc ;for global memory
mem.free
mem.resize
heap.init ;create heap
heap.alloc ;and for heap
heap.free
heap.resize

and then for heap use system if possible, and make own manager for OSes where it isn't supported. btw. i am already writing this code for win32 (only a wrapper of system calls)

vid: OK, I agree to what you all came to. mem.alloc, mem.free, etc... I will soon upload some of my procs.

Nice try, but a tad too simple. If you allocate a buffer of 1024, then get 35 characters of text back, from that point until the end of time you will think the buffer is only 256 bytes. It may also cause a memory leak, though I believe most memory managers work from memory address rather than addr&len.

OK, buffersize should be in the string for memory management purposes.

[quote]If you allocate a buffer of 1024, then get 35 characters of text back, from that point until the end of time you will think the buffer is only 256 bytes.[\quote]
There is no memory leak if you use HeapAlloc/Free or other memory manager that stores buffer size in its own structures. You will think the buffer is 256 bytes. Then you get, for example, another 1000 characters in the buffer. The algorithm says you need reallocation, and you realloc() the buffer to 1024 bytes. No problems here, just one unnecessary call to realloc(), but it's tolerable.

Although, I agree with Kain: Storing buffer size in the string would be a better solution.

i decided to use Fresh's string library anyway. it's a bit harder to work with string directly, but it is already written and tested, and already used in fresh. i've already started rewriting it.

[EDIT]Reverend: please wait until i post here my version so we can consilidate style a bit.[/EDIT]