Hey, All.

the question is about the Process id.

after I ran a proc(which? is tested). the id of every new proc that is running in my system? has a big process id.
if I didn't run the proc first (after reboot) , the every process id is normally.

which case will creat the phenomena of process?

regards.
Posted on 2005-03-28 06:07:49 by dcskm4200
My guess would be that your proc allocs/deallocs a lot of handles?
Posted on 2005-03-28 10:29:31 by f0dder
Hey,f0dder

Thanks you for help.

Yes. I used a lot of codes as following.
;=============================================
invoke LocalAlloc,LMEM_FIXED or LMEM_ZEROINIT,100
mov buffer10,eax
.....
invoke LocalFree,buffer10
;=============================================

invoke GlobalAlloc, GMEM_FIXED or GMEM_ZEROINIT, 65535d
mov buffer0 , eax
...
invoke GlobalFree, buffer0
;=============================================
i will check the code.


regards.

Posted on 2005-03-28 19:43:21 by dcskm4200
dcskm4200,

If you need a single large block of fixed memory, GlobalAlloc() works fine but if you are repeatedly allocating small amounts of memory such as the 64k in your examples, there are better strategies available in Windows depending on your task. LocalAlloc() is an out of date form left over from 16 bit Windows so it is better to replace it with a more modern strategy. Note that using either GlobalAlloc() or LocalAlloc() with anything else than the FIXED flag and the zero init flag is technology that is no longer used in 32 bit Windows.
Posted on 2005-03-28 20:33:52 by hutch--
Note that using either GlobalAlloc() or LocalAlloc() with anything else than the FIXED flag and the zero init flag is technology that is no longer used in 32 bit Windows.


That is incorrect. For example, consider the SetClipboardData() function, which requires its second argument to either be NULL or memory allocated using GlobalAlloc() with the flag GMEM_MOVEABLE (The MSDN page doesn't mention the GlobalAlloc() function's name, that is an error in MSDN).

Generally speaking, however, the Global* and Local* memory management functions should not be used.
Posted on 2005-03-28 20:48:53 by death
The criterion set by using SetClipboardData() does not effect general purpose memory allocation as it is a legacy format from 16 bit Windows. Much the same with DDE.

The distinction between global and local memory collapsed with the introduction of 32 bit Windows and where you can use old functions like these, LocalAlloc() no longer references the situation it was originally designed fo where at least GlobalAlloc() does reference global memory.

Generally speaking, memory allocation strategies should be determined on the basis of the task, not reductionist theories.
Posted on 2005-03-28 23:58:03 by hutch--
Hey, hutch-- and death.

Thanks you for help.

How use the buffer in my tested code always is a haze of understanding. for example.
1.
;====================
.data
bufferA db 4096 dup(0)
.code
mov esi, offset bufferA
...
;====================
you first have used the bufferA,  if you'll second use the bufferA. you must clean the bufferA.  the method has some scarcity when you used bufferA repeatly.
another, the method always occupyed the memory, and the bufferA must be enough big . in my tested code, if i click the button 1, the bufferA will be used. when my tested code is running, sometime datas need to use big the bufferA, another time datas need to use small the bufferA.

2.
;====================
.data ?
bufferA dd ?
.code
invoke GlobalAlloc, GMEM_FIXED or GMEM_ZEROINIT, 4096d
mov bufferA , eax
...
invoke GlobalFree, bufferA
...
;====================
main proc used GlobalAlloc, sub proc (7sub) used LocalAlloc. the OP system will be affected by my tested code.  when i click the button 1, sub proc will run, the OP system created a big process id. second click the button 1, my tested code collapsed.

regards

Posted on 2005-03-29 04:49:23 by dcskm4200
Hey,f0dder

I done that according to Hutch-- said.
but I waste a week to figure out the problem of the big id and second clicked collapse. it seems that I can't  figure out it.

could you check my tested code?

regards.
Posted on 2005-03-30 10:41:33 by dcskm4200
Can you post a .asm file that's ready to assemble?
Also, I don't really understand what your problem is - is it a problem in itself that you're getting large process IDs, or is the problem something else?
Posted on 2005-03-30 10:51:25 by f0dder
Hey,f0dder

thanks you.
I will neaten and note the code. after a day, I will send a email to you.

regards
Posted on 2005-03-30 23:31:03 by dcskm4200
Hey, All.
how can I get  my cards id in DOS?
THANK YOU
AND I AM VERY SORRY FOR MY POOR ENGLISH.
Posted on 2005-04-03 07:25:47 by ahwb