Przemysław Czerpak wrote: > I cannot help you here. Information about DosFindFirst() in OS2 returned > by google suggest that our implementation should not work correctly, i.e.: > > Level 1 File Information (ulInfoLevel == FIL_STANDARD) > On output, pfindbuf contains the FILEFINDBUF3 data structure _without_ > the last two fields cchName and achName. This is used without EAs. > > If the above is true then you should use FIL_STANDARDL and FILEFINDBUF3L > structure. > I saw that on Control API docs as well, but I think this is wrong or, at least, not completely true.
Here I always get file names with FIL_STANDARD, even with my last change which is able to retrieve nearly one hundred file names per DosFindFirst() call. > Also seems that flAttribute parameter has wrongly value. > Without ORing with FILE_ARCHIVED and FILE_READONLY files with above > attribute should be excluded. > bits 5..0 are MAY-have, that is, file name is returned either it has that attribute set or it has not. If you want only those files with attributes set, then you have to use must-have values, 13 MUST_HAVE_ARCHIVED (0x00002000) Must-Have Archive bit; excludes files without the archive bit set if bit 13 is set to 1. Files may have the Archive bit set if bit 13 is set to 0. 12 MUST_HAVE_DIRECTORY (0x00001000) Must-Have Subdirectory bit; excludes files that are not subdirectories if bit 12 is set to 1. Files may have the Subdirectory bit set if bit 12 is set to 0. 11 Reserved; must be 0. 10 MUST_HAVE_SYSTEM (0x00000400) Must-Have System File bit; excludes nonsystem files if bit 10 is set to 1. Files may be system files if bit 10 is set to 0. 9 MUST_HAVE_HIDDEN (0x00000200) Must-Have Hidden File bit; excludes nonhidden files if bit 9 is set to 1. Files may be nonhidden if bit 9 is set to 0. 8 MUST_HAVE_READONLY (0x00000100) Must-Have Read-Only File bit; excludes writeable files if bit 8 is set to 1. Files may be read-only if bit 8 is set to 0. > BTW what errors do you have? > Error 8, that is ERROR_NOT_ENOUGH_MEMORY. With my last change, which uses a block obtained with a DosAlloc() with OBJ_TILE, that is a block aligned to a 64Kb segment, in low memory and with 16bit selectors set, it always works. This is on a SMP kernel searching for a file on a samba share, so going throug IBM LanManager (aka CIFS client) which is an old piece of code which might have some old 16bit/protect mode code inside. I'll commit this change shortly. >> Now, can you tell me if _all_ memory allocations, made via hb_xgrab(), when >> using dlmalloc.c go through dlmalloc.c line 1338, that is through os2mmap() > > Inside DLMALLOC _all_ memory is allocated by os2mmap() function. > Ok, thanks, at first I thought of changing it, but it is not enough since it seems to me that dlmalloc sub-allocs bigger blocks (which is correct, imho) but this makes DosFindFirst() fail from time to time. BTW, if we could be sure that some memory never goes to a DosXXX() call, we could add a OBJ_ANY to the call, making OS/2 use memory above the 512Mb limit that OBJ_TILE has; anyway, this is so a little improvement in every day code, I don't think it's worth the time I've spent writing about it here :) >> even if I'm not mmapping() nothing? > > MMAP is optionally used only in *nix DLMALLOC builds to improve performance > of memory allocation. It does not exists in MS-Windows and OS2 so it cannot > be used in such builds. > ok. >> Or there are other paths to memory allocations? > > Maybe but not inside DLMALLOC code, i.e. some CRTL functions may > allocate memory using different memory manager but DLMALLOC uses > only above function in OS2 builds. > Ok, perfect, I was interested in hb_xgrab() calls. Thanks a lot. Maurilio. -- __________ | | | |__| Maurilio Longo |_|_|_|____| farmaconsult s.r.l. _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
