There may be a problem with Local/GlobalAlloc flags (GM_FIXED if i remember). I do not understand why everybody uses these functions for Memory management. The 2 weird 'Handle/pointer' seems to me very strange. VirtualAlloc is much more clean, consistant, easy and powerfull. It doesn't rise any problem under Win NT/2000: ____________________________________________________ ; Ask For: api 'KERNEL32.VirtualAlloc' &NULL D§HowMuch, &MEM_COMMIT__&MEM_RESERVE, &PAGE_READWRITE mov D§MemPtr eax ____________________________________________________ ; Release: api 'KERNEL32.VirtualFree' D§MemPtr &NULL &MEM_RELEASE More: Advanced possibilities are available... Does anyone know some reason for prefering Local/GlobalAlloc? betov.
Posted on 2000-12-30 05:26:00 by Betov
betov, GlobalAlloc usually works fine, gives you the choice of memory type, (FIXED - MOVABLE) and gives you the size you want, problem I see with VirtualAlloc is that it will swap to disk if you run low on memory which is handy enough but a pain if you need to handle large amounts of data in RAM. The later stuff tends to use iMalloc interface and it is supposed to be a bit faster but in most instances, GlobalAlloc works fine. Regards,
Posted on 2000-12-30 06:05:00 by hutch--
Hi! Hutch, Bye the way, chery MistChras to you too (made me laugh a lot...). 1) What interrest of having a MOVABLE Mem? 2) Never heard that GlobalAlloc would be unable of swaping to disk. What would it do when mem low? 3) "iMalloc interface" ? No info in my Win32 help out of Folders managements; Any example? What Win version? Is it an api or a C routine? By the way, too, in a previous article, you wrote: "It is still common to get someone who has a copy of TASM and notepad driving everybody nuts with questions on how to write MessageBoxA because they are too FUCKING lazy to get the reference material and a decent assembler to write some decent code." ... With "decent assembler", i suppose (as you use same vocabulary as me in my private messages), that you mean SpAsm? when will you join? :) ) betov.
Posted on 2000-12-30 08:27:00 by Betov
GlobalAlloc allocates memory from the default heap. You can specify that it returns the pointer to the memory block by passing GMEM_FIXED flag. Actually there are three levels of memory management APIs: Global/Heap/Virtual. At the lowest level, both Global and Heap functions use Virtualxxx ones. The advantage to using GlobalAlloc is that: you don't have to be concerned with the page boundary: you can specify the memory block with byte granularity and you have the option to zero out the memory block in one function call (GMEM_ZEROINIT): you don't have to be concerned with the state of the memory block itself whether it's reserved or committed. Virtualxxx is good for reserving large block of memory address space. However, you have page granularity: on Intel platform, that means even if you want to allocate only 4 bytes, the memory block must be 4k in size. You also have the option of specifying whether to reserve the memory range and commit physical memory when it's necessary. So for simple memory usage, GlobalAlloc is easier to use.
Posted on 2000-12-30 11:12:00 by Iczelion
OK, Iczelion. Tests made > i will never use it (for side reasons too long to discuss here) but you are right. Thanks a lot. Remains the problem that it doesn't seam to work well under Win NT/2000... betov.
Posted on 2000-12-30 15:05:00 by Betov
betov, I will be pleased to see you get SpAsm going, I have played with NASM but found it not powerful enough to do full 32 bit windows code, excellent pre-processor but no stack automation. NASM may have been "assembler friendly" for writing an assembler but it was not powerful enough to write the wide range of code necessary for general purpose applications. TASM was abandoned by Borland/Inprise some time ago and they never fixed its "out of hash space" problems, it had problems with structures and it was still OMF format which made the EXE size larger. Apart from being a MASM man from old, Bill and the Evil Empire actually need ML.EXE to plug the holes in poor C++ performance so it is an up to date assembler that is a very mature in its design and it can produce more or less anything you need for the 32 bit windows platform. The other thing is you get MASM for FREE, even though I paid for my last version of MASM. A new assembler is something I would like to see and if it is powerful and flexible and can write the range of code that I need, I will be inclined to have a look at it and perhaps use it but I am no purist in assemblers, I am happy enough to write inline asm in both C and basic if it does the job. The things I would like to see in a new assembler are, 1. Stack automation as in a high level language. Also the option to do it manually if it is needed. 2. A macro capacity that is at least as powerful as MASM. 3. Modular capacity. The capacity to build static libraries is an absolute necessity. 4. NO leading notation like nasm's macros, %whatever. 5. Size limit on header files determined by memory alone, not a limit set by old DPMI from TASM. Same with source file size. 6. The ability to handle the documented names of ALL the windows constants, structures and API function calls. No unusual requirements and notation that makes header files harder to write. There are of course others but you get the general idea, a FAST, user friendly assembler that can do all of the normal high level constructions in a reliable manner. Regards,
Posted on 2000-12-30 18:03:00 by hutch--
Hutch.. please add: 7. a big project like my project, speed of assembly with multiple levels of include files and macros is very important.. Bogdan
Posted on 2000-12-30 19:58:00 by BogdanOntanu
1) Stack automation is done in Spasm with User defined Macros (i provide them, and others, in Beginners'tut5). 2) Point 1 gives you the answer about the Macros power... 3) Modularity: never, sorry, we cut and paste... and see what we are doing. 4) Leading notations are great: they increase a lot readibility and they make parsers analyses very simple and fast. They prevent from a lot of common writing errors like MASM confusion between Adresses and Values due too the more stupid declaration convention ever seen in Asm. 5) There is no header files concept in SpAsm. Only one source file without size limit. 6) SpAsm have an internal storage of Win Equates (they don't require any declaration). Structures are in an external text file, to be Copy/Paste. Api calls are not controled (illusion help anyway). 7) SpAsm compiles a 1 Mb source, written in middle style, in 16 seconds on K6/200/Win95. From full source to PE write. As i suppose you saw few Asm applications with 1 Mb Asm size source, we can say that, on common size app, it does the PE from scratch in very few seconds. About one more third of compile time for HLL style sources, and a bit less for true low level style sources. About "unusual requirements and notation...", this would suppose that we have something called 'a reference Assembler'. What i deny. Before writing SpAsm, i learned other available Assemblers (A86/386, NASM, Pass32, Asm32). MASM have never been any possible choice for me, even if evil's factory made it the best in the world and give money with it, i would never use it. Several ideas in SpAsm come from upper 4 good Assemblers. If i had to choose what 'reference Assembler', i would say: NASM. I didn't simplify syntax just for the pleasure of turning people nut: i tried to remain as close as possible to A86/386 and NASM. > "NASM may have been "assembler friendly" for writing an assembler..." makes me think that you believe i wrote SpAsm with NASM (?). SpAsm is written intirely with SpAsm. This is the 1 Mb source upper example. Bye. betov.
Posted on 2000-12-31 07:36:00 by Betov