#61 closed defect (fixed)
SVN rev 299: newview.exe crashes on searching in IFS.INF
Reported by: | erdmann | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | Future |
Component: | utilities | Version: | |
Severity: | low | Keywords: | |
Cc: |
Description
I realized that IFS.INF has been enhanced with previously missing information about 32-bit entry points and enhanced system structures to support 64-bit file sizes and file offsets (which of course is a good thing).
Unfortunately, the created IFS.INF is no longer searchable via newview.exe. I searched for term "FS_NAME" and newview.exe crashed.
I would be good if IFS.INF would be rebuilt. Maybe Watcom's wipfc.exe has a bug. Maybe it needs to be rebuilt with ipfc.exe from the IBM OS/2 toolkit (just a guess).
Change History (7)
comment:2 by , 7 years ago
I just disassembled the original ifs.inf with newview.exe. Newview might just ignore the search index info (can you look into ifs.ipf and check if it is so? At the moment I just don't know what is required for an .inf file to be searchable). Yes, wipfc has some features unimplemented. For example, I needed to fix a bit the .ipf code to have the main screen look good (you may notice that original version has three-part main screen, but my version has two parts. This is because something is not working in wipfs). But I prefer to use free tools with sources. Some tools are cloned in osFree project, like mkmsgf.exe. I don't want to depend on Toolkit or DDK. The only Toolkit dependency now is mapsym.exe, which is also desirable to have an open source alternative. This is in the queue for osFree project.
PS: Yes, a good point about FS_FINDFIRST additions in trunk\src\doc\addenda. I'll add it too.
PPS: Is fat32.inf not searchable too? I enhanced it a bit too, BTW.
comment:3 by , 7 years ago
Hm, strange -- search works fine in fat32.inf but searching in ifs.inf indeed crashes newview.exe
comment:4 by , 7 years ago
Building with ipfc eliminates the problem. However, both compilers throw a bunch of duplicate ID warnings which might be the real problem.
comment:6 by , 7 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:7 by , 7 years ago
2Lars: I just changed wipfc to ipfc. The problem with wipfc remains, of course. This seems to be a bug with creating search index structure.
Forgot: it would also be nice if the info in: http://trac.netlabs.org/fat32/browser/trunk/src/doc/addenda
could be merged into the IPF in the FS_FINDFIRST / FS_FINDNEXT sections