Memory eaters

Haveing finaly gotten P'd off with VBs memory munching I installed a RAM LIBERATOR program. It fixed the problem that's for sure - not very satisfying.

But it seems VB is not the only MS product that takes RAM and then wont give it back.

Even the MSN website does it (!)

Are microsoft out to prove PCs are crap or is it a fundamentle difference between what they think we use and what we do use?

Have noticed VB is nasty for it though. It wants all my spare memory and what for? does it need it? NO!

I recon one day MS will slip up and forget to include the memory hog modual in a program.

Sorry pet peeve. does anyone know how to limit the VB packages damage on memory munching when it's been loaded a few hours a giant hole appears in my memory and it all leaks out. I haven't got that much anyway.

sounds like you aren't closing your program right or some functions.

but it could also be a memory resident program that sits in the back of the memory just eating, can't remember the name for those.

Quote:

---

Originally posted by scoutt
sounds like you aren't closing your program right or some functions.

but it could also be a memory resident program that sits in the back of the memory just eating, can't remember the name for those.

---

well the programs you make in VB have alot of overhead and clunky memory management

how much ram do you have matt? i use vc++/vb (not anymore now, but when i did), and the msdn site took up almost no memory at all, and whatever it used it gave back to me. your prolly running some bloatware that you dont know know. check your startup.

VB makes extensive use of the SCM (the thing that actually maps memory for COM servers into process space).

The SCM has a 'feature' that certain kinds of objects are cached in memory. And persist after image exit. You'll notice this if you start IE5 or Word, then exit the apps. The available memory is less than when you started.

The assumption is that other microsoft apps that you are going to start will need the objects - which is true only if you fire up more MS products.

If the amount of memory contiues to go down with each run of the app, then you have a memory leak.

This is all sounds chillingly familiar.

Question is what should I do about it? What can I do about it. Operating systems and the hardwear eliment of computers are not my strong point. I've only given them seriouse study in the last year.

There isn't much you can do about what the SCM persists in memory, except make sure that you close down VB programs correctly.

eg. things like:

Code:

---

Dim o as object
  for each o in Forms
        unload o
  next

---

Ok thanx, Iguess it's just one of those things that'll have ta live with.

BTW: is that "code" 4 real?

Quote:

---

Dim o as object
for each o in Forms
unload o
next

---

:rolleyes:

There are certain API calls that cause huge memory leaks.

API functions?? I C!

Any idea what these could be?

I'm not to fussed if you can't tell me but.... you know 'twould be usefull to keep in mind.

No api causes a memory leak when you use it correctly. But if you call CoTaskMemAlloc and forget to call CoTaskMemFree you can be in a world of hurt, for example.

The problem here is that you may not KNOW that you call CoTaskMemAlloc, because you called it indirectly.

For instance:

Code:

---

Private Type BrowseInfo
    hWndOwner As Long
    pIDLRoot As Long
    pszDisplayName As Long
    lpszTitle As Long
    ulFlags As Long
    lpfnCallback As Long
    lParam As Long
    iImage As Long
End Type
Const BIF_RETURNONLYFSDIRS = 1
Const MAX_PATH = 260
Private Declare Sub CoTaskMemFree Lib "ole32.dll" (ByVal hMem As Long)
Private Declare Function lstrcat Lib "kernel32" Alias "lstrcatA" (ByVal lpString1 As String, ByVal lpString2 As String) As Long
Private Declare Function SHBrowseForFolder Lib "shell32" (lpbi As BrowseInfo) As Long
Private Declare Function SHGetPathFromIDList Lib "shell32" (ByVal pidList As Long, ByVal lpBuffer As String) As Long
Private Sub Form_Load()
    'KPD-Team 1998
    'URL: http://www.allapi.net/
    '[email protected]
    Dim iNull As Integer, lpIDList As Long, lResult As Long
    Dim sPath As String, udtBI As BrowseInfo

    With udtBI
        'Set the owner window
        .hWndOwner = Me.hWnd
        'lstrcat appends the two strings and returns the memory address
        .lpszTitle = lstrcat("C:\", "")
        'Return only if the user selected a directory
        .ulFlags = BIF_RETURNONLYFSDIRS
    End With

    'Show the 'Browse for folder' dialog
    lpIDList = SHBrowseForFolder(udtBI)
    If lpIDList Then
        sPath = String$(MAX_PATH, 0)
        'Get the path from the IDList
        SHGetPathFromIDList lpIDList, sPath
        'free the block of memory
        CoTaskMemFree lpIDList
        iNull = InStr(sPath, vbNullChar)
        If iNull Then
            sPath = Left$(sPath, iNull - 1)
        End If
    End If

    MsgBox sPath
End Sub

---

yes I think I follow.