| [3811] | 1 | OS/2 bugs:
 | 
|---|
 | 2 | - Dlls are terminated in the order in which they're present in the modules
 | 
|---|
 | 3 |   name lookup table instead of taking dependencies into account
 | 
|---|
 | 4 | 
 | 
|---|
 | 5 | - DosSetMem doesn't seem to do what it's supposed to;
 | 
|---|
 | 6 |   the size parameter has to be adjusted to take page boundary crossing
 | 
|---|
 | 7 |   into account. According to the Control Program Programming Guide, DosSetMem
 | 
|---|
 | 8 |   should do this automatically.
 | 
|---|
 | 9 | 
 | 
|---|
 | 10 | - DosSetMem does not alter the 16 bit selectors so if you change memory
 | 
|---|
 | 11 |   attributes and then access the memory with a 16 bit API (such as DosRead),
 | 
|---|
 | 12 |   it will have the old (alloc time) attributes
 | 
|---|
 | 13 | 
 | 
|---|
 | 14 | - If you allocate memory without PAG_EXECUTE and use DosSetMem to commit and
 | 
|---|
 | 15 |   set that flag, then DosQueryMem does not return that flag.
 | 
|---|
 | 16 |   If you allocate it with PAG_EXECUTE set, then DosQueryMem does what it's supposed to.
 | 
|---|
 | 17 | 
 | 
|---|
| [4600] | 18 | - Workaround added for coordinate problem when a window
 | 
|---|
 | 19 |   looses focus and SelectClipRgn is called. GpiSetClipRegion
 | 
|---|
 | 20 |   resets the window origin for some unknown reason 
 | 
|---|
 | 21 |   (TODO: figure out why)
 | 
|---|
 | 22 | 
 | 
|---|
| [3811] | 23 | FP13:
 | 
|---|
 | 24 | - DosQuerySysState bug when object information is requested. Probably a
 | 
|---|
 | 25 |   problem which occurs in _LDRSysMteInfo when qsCheckCache is calle before
 | 
|---|
 | 26 |   writing object info. The result is that the cache flushed and the attempt
 | 
|---|
 | 27 |   of updating the qsLrec_t next and object pointer is not done. This used to
 | 
|---|
 | 28 |   work earlier and on Aurora AFAIK.
 | 
|---|
 | 29 | 
 | 
|---|
 | 30 |   The fix for this problem is to check if the pObjInfo is NULL while the
 | 
|---|
 | 31 |   number of objects isn't 0 and correct this. pNextRec will also be NULL at
 | 
|---|
 | 32 |   this time. This will be have to corrected before we exit the loop or moves
 | 
|---|
 | 33 |   to the next record. There is also a nasty alignment of the object info...
 | 
|---|
 | 34 |   Hope I got it right. (This aligment seems new to FP13.)
 | 
|---|
 | 35 | 
 | 
|---|