Conference abbott::teamlinks_windows

I forwarded your note to the developer that knows the
most about FCLIST, but he's out this week. I can't recall
anyone ever reporting this before though.

Do the bitmaps for drawers and folders show up? Do
local filecabs work correctly?

Jerry

Does it work ok if cc:Mail isn't running?

Does the same type of thing happen if the FC is displayed in the
Select Attachment dialog?

Bob

    I spoke with the customer today.
    
    They have installed 2.7-001 still the same problem.
    
    This is happening for IOS drawer and the network drawers.
    She is going to have the user check to see if when using
    add attachment if the select attachment windows shows
    the same behavior.
    
    They have noticed this happens when the GDI gets low.
    I had them run sysmeter and they have noticed when Word 6.0a 
    is launched from TeamLinks and then closed, each time it is
    launched and closed they loose about 1% of the GDI each time.  
    
    The registration database is used to launch Word not an association.
    
    If the exit TeamLinks and CC Mail and restart then sometimes the
    folders names are visible if that does not they an then restart
    the PC and they are visible for a while.
    
    Is this a possible GDI problem and is this just the way it works?
    
    Thanks,
    
    Beth Andres
    

Yes, low GDI would cause these sorts of problems.

    Jerry,
    
    Have you heard if opening Word by using Launch from TeamLinks causes
    GDI to go down?  I tried this with Windows 95, Word 7.0 and Tl 2.7
    with Sysmeter running and I did not appear to loose GDI.
    
    However the customer is using Word 6.0a, Windows 3.1 and TL 2.7,
    not sure if this makes a difference or not?
    
    Thanks,
    
    Beth
    

I don't think we have any absolute, positive knowledge
of this, though I think there may be a suspicion that
there's a problem. Windows 3.1 would certainly be sensitive
to that.

Jerry

The table below, if it comes out, helps identify why GDI problems 
are less significant on Windows 95. The gist of it isa that in Windows 
3.1 all GDI elements come out of a single 64K segment for the whole 
system and all applications. There are basically 6 things stroed in the 
GDI head. They are, if I can remember them, fonts, bitmaps, DC, pens, 
pallettes and of course brushes. In Windows 95 there is stil la 64Ksegment 
for the whole system and all of the applications but a lot of the elements
don't go in it. DC's, Pens, Brushes and fonts are stroed in the 32 bit 
global head which is virtually virtual. Get it heh, heh. GDI monitoring 
tools only monitor the 64K 16 bit local heap. On Windows 95 this is 
not used for much and it is possible that loading Word might not use any 
local GDI heap. On Windows 3.1 or 3.11 it would use significantly more. 

Cheers, 
jal
 


Windows 95 provides a significant increase in the system resources 
available to Windows-based and MS-DOS � based applications over what was 
available under earlier versions of Windows. The net result for users is 
that they can count on more system resources being available for creating 
windows, using fonts, running five or more applications simultaneously, and 
so on. 
Windows 3.1 maintained 64K regions of memory heaps for use by the graphics 
device interface (GDI) and USER system components. These heaps stored GDI 
or memory object information allocated when an application called a Windows 
API function. The amount of space available in the combination of these two 
heaps is identified as a percentage of system resources that are free (that 
percentage appears in the Help About dialog box in My Computer and other 
Windows-based applications). Under Windows 3.1, when the calculated amount 
of free space dropped to a low number, the system often reported that it 
was out of memory even though the amount of free memory shown in the About 
dialog box was still quite high. This was often due to low memory in either 
the GDI or USER heap, or both.
In Windows 95, to help reduce the system resource limitation, many data 
structures formerly stored in the 16-bit GDI and USER heaps are now stored 
in 32-bit heaps. This provides more room for the remaining data elements to 
be created.  
The following table shows the system limits in Windows 95, as compared to 
the constraining limits under Windows 3.1. For information about how to 
assess performance of key system resources, see �Identifying Performance 
Problems with System Monitor� later in this chapter. For information about 
the supporting architecture, see Chapter 31, �Windows 95 Architecture.�
Windows 95 System Limits
  
Resource	Windows 3.11	Windows 952

Windows Menu handles	~299	32K 
Timers	32	Unlimited
COM and LPT ports	4 per type	Unlimited
Items per listbox	8K	32K
Data per listbox	64K	Unlimited
Data per edit control	64K	Unlimited
Regions	All in 64K segment	Unlimited
Physical pens and brushes	All in 64K segment	Unlimited
Logical pens and brushes	All in 64K segment	All in 64K segment
Logical fonts	All in 64K segment	750 � 800
Installed fonts	250 � 300 (best case)	1000
Device contexts	200 (best case)	16K

1   Limits for GDI objects in Windows 3.1 are not exact because all 
regions, physical objects, logical objects, device contexts (DCs), and 
installed fonts had to fit in a single 64K segment. Because many of these 
have been moved to the 32-bit heap, Windows 95 provides much more room for 
those remaining items, such as logical pens, brushes, and so on. The 
remaining items in the Windows 95 local heap are all less than 10 � 20 
bytes each.
2   System-wide resources, unless noted otherwise.