| [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 |  | 
|---|