gmane.org.netlabs.fm2.devel

File Manager/2 v3.20 released

2012-01-08T22:25:43

FM/2 3.20.0 has been released. The file name is fm2-3-20-0.zip

It has been uploaded to Netlabs and to Hobbes.

NETLABS
Initially uploaded to:
  <ftp://ftp.netlabs.org/incoming/fm2-3-20-0.zip>
Eventual location:
  <ftp://ftp.netlabs.org/pub/fm2/fm2-3-20-0.zip>

HOBBES
Search for it at:
  <http://hobbes.nmsu.edu/h-search.php?sh=1&button=Search&key=fm2-3-20-0.zip&dir=%2Fpub>
Initially uploaded to:
  <http://hobbes.nmsu.edu/pub/incoming/fm2-3-20-0.zip>
Eventual location:
  <http://hobbes.nmsu.edu/pub/os2/util/browser/fm2-3-20-0.zip>

3.20.0 Changes:
 * Identified mmioIdentifyFile's failure to correctly identify some files as the root cause of
   a trap in GBM.DLL. ShowMultiMedia now only checks files with known multimedia extensions.
   This will minimize but not complete prevent the problem. Ticket 402 (Gregg)
 * Add suggested drive flags for use with Netdrive drives to help file. Ticket 171 (Gregg)
 * Clarify ARCHIVER.BB2 date types and add a new one to fix displaying of .tar.gz files for Tar 1.15 and higher.

Request: Commit work for upcoming release.

2012-01-08T18:21:36

The release of FM/2 3.20.0 is imminent.

Please commit all work for this release ASAP.

Reply to this email if there are reasons to delay the release.

File Manager/2 v3.20 released

2012-01-08T22:25:43

FM/2 3.20.0 has been released. The file name is fm2-3-20-0.zip

It has been uploaded to Netlabs and to Hobbes.

NETLABS
Initially uploaded to:
  <ftp://ftp.netlabs.org/incoming/fm2-3-20-0.zip>
Eventual location:
  <ftp://ftp.netlabs.org/pub/fm2/fm2-3-20-0.zip>

HOBBES
Search for it at:
  <http://hobbes.nmsu.edu/h-search.php?sh=1&button=Search&key=fm2-3-20-0.zip&dir=%2Fpub>
Initially uploaded to:
  <http://hobbes.nmsu.edu/pub/incoming/fm2-3-20-0.zip>
Eventual location:
  <http://hobbes.nmsu.edu/pub/os2/util/browser/fm2-3-20-0.zip>

3.20.0 Changes:
 * Identified mmioIdentifyFile's failure to correctly identify some files as the root cause of
   a trap in GBM.DLL. ShowMultiMedia now only checks files with known multimedia extensions.
   This will minimize but not complete prevent the problem. Ticket 402 (Gregg)
 * Add suggested drive flags for use with Netdrive drives to help file. Ticket 171 (Gregg)
 * Clarify ARCHIVER.BB2 date types and add a new one to fix displaying of .tar.gz files for Tar 1.15 and higher.

Request: Commit work for upcoming release.

2012-01-08T18:21:36

The release of FM/2 3.20.0 is imminent.

Please commit all work for this release ASAP.

Reply to this email if there are reasons to delay the release.

File Manager/2 v3.20 released

2012-01-08T22:25:43

FM/2 3.20.0 has been released. The file name is fm2-3-20-0.zip

It has been uploaded to Netlabs and to Hobbes.

NETLABS
Initially uploaded to:
  <ftp://ftp.netlabs.org/incoming/fm2-3-20-0.zip>
Eventual location:
  <ftp://ftp.netlabs.org/pub/fm2/fm2-3-20-0.zip>

HOBBES
Search for it at:
  <http://hobbes.nmsu.edu/h-search.php?sh=1&button=Search&key=fm2-3-20-0.zip&dir=%2Fpub>
Initially uploaded to:
  <http://hobbes.nmsu.edu/pub/incoming/fm2-3-20-0.zip>
Eventual location:
  <http://hobbes.nmsu.edu/pub/os2/util/browser/fm2-3-20-0.zip>

3.20.0 Changes:
 * Identified mmioIdentifyFile's failure to correctly identify some files as the root cause of
   a trap in GBM.DLL. ShowMultiMedia now only checks files with known multimedia extensions.
   This will minimize but not complete prevent the problem. Ticket 402 (Gregg)
 * Add suggested drive flags for use with Netdrive drives to help file. Ticket 171 (Gregg)
 * Clarify ARCHIVER.BB2 date types and add a new one to fix displaying of .tar.gz files for Tar 1.15 and higher.

Request: Commit work for upcoming release.

2012-01-08T18:21:36

The release of FM/2 3.20.0 is imminent.

Please commit all work for this release ASAP.

Reply to this email if there are reasons to delay the release.

Request: Commit work for upcoming release.

2011-12-31T23:50:05

The release of FM/2 3.20.0 is imminent.

Please commit all work for this release within 24 hours.

Reply to this email if there are reasons to delay the release.

Re: Random trap in GBM.dll caused by double clicking a file

Heiko Nitzsche — 2011-10-30T13:50:06

Gregg,

yes, I think the code is the same as used by eCS 2.0. You can get
it from Hobbes (http://hobbes.nmsu.edu/h-search.php?key=jpg-io-procedure-0_1_0&pushbutton=Search)
or from C. Wohlgemuth's old website on os2world.com (http://www.os2world.com/cdwriting/index.htm).
I haven't found any newer version of it and also the latest CW-MM classes
used by eCS 2.0 ship with the same version (try bldlevel jpegio.dll).
Just do a diff of the source files to see what I changed.

The jpegio.dll is a bit smaller as I used slightly different compiler
options (just took a makefile from GBM as template). The DLL additionally
is LX-Lite compressed which contributes the most of the shrink.

Heiko

Re: Random trap in GBM.dll caused by double clicking a file

Gregg Young — 2011-10-29T20:35:51

Heiko Steven

The JPG IO procedure code you sent fixed the trap in GBM.dll (at least I haven't been able to 
reproduce it). It also works to display JPG images. Is it based on the code for the  jpegio.dll 
in eCS 2.0? It is quite a bit smaller. 

I have fixed FM/2 to check file extensions before calling MMIOIdentifyFile. I used the 
extension list from the IO proc list in the multimedia object plus .MPEG and .JPEG.  Should I 
add any others? I also moved the ShowMultimedia call to after the TestBinary call to 
minimize the chance of a file with a multimedia extension that isn't actually multimedia 
getting through. 

I also found a note in the ShowMultimedia code that says MMIOIdentifyFile identifies MPG 
files as FOURCC_DOS. It is buggy.  If this work around doesn't prevent further problems I will 
scrap MMIOIdentifyFile etc completely. Thanks

Gregg 

On Thu, 27 Oct 2011 03:10:22 +0200 Heiko Nitzsche wrote:
zero
it
I
popuplog
)
GBM_ERR_OK 
and
him
I
-

Re: Random trap in GBM.dll caused by double clicking a file

Steven Levine — 2011-10-28T17:14:34

In <100.909a0c005b5ea44e.008-r9/a4iiAUwJeoWH0uzbU5w< at >public.gmane.org>, on 10/23/11
   at 12:35 PM, "Gregg Young" <ygk-r9/a4iiAUwJeoWH0uzbU5w< at >public.gmane.org> said:

Hi,


Did Heiko's latest gbm release resolve these traps?

Steven

Re: Random trap in GBM.dll caused by double clicking a file

Steven Levine — 2011-10-23T22:45:07

In <100.70db0900ba5fa44e.010-r9/a4iiAUwJeoWH0uzbU5w< at >public.gmane.org>, on 10/23/11
   at 12:40 PM, "Gregg Young" <ygk-r9/a4iiAUwJeoWH0uzbU5w< at >public.gmane.org> said:

Hi,


I figured that.  I just wanted to cover all the possibilities.

Steven

Re: Random trap in GBM.dll caused by double clicking a file

Gregg Young — 2011-10-23T18:40:58


I rebuild the sym & xqs files every build and then copy them with the exes to my test 
directory so they always match. Thanks

Gregg

Re: Random trap in GBM.dll caused by double clicking a file

Gregg Young — 2011-10-23T18:35:07

Heiko

I wasn't trying to open an image file. It was a binary file that fm/2 didn't recognize so it 
asks MMPM/2 if it can open it. The answer should be a simple no but this trap occurs 
occasionally. 

I tried to reproduce it this morning with less than ideal results. I didn't get the GBM trap I got 
a cascading trap mostly in various multimedia related dlls. I have attached the popuplog 
entries from both tries. I rebooted to stop the first; the second eventually trapped the kernel. 
I have the trap dumps for the whole thing including the kernel.  

I also have the trap dumps from the GBM.dll trap from yesterday. The MMPM code works 
as expected when I try to open an image file. The cascading trap is reproducible every time 
(double click on fm3dll.xqs) and I can only eliminate it by turning the MMPM/2 check off. I 
wonder if I have corrupted a file somewhere that is contributing to this new problem. 
Thanks

Gregg

On Sun, 23 Oct 2011 16:01:59 +0200 Heiko Nitzsche wrote:





10-23-2011  10:18:16  SYS3171

Re: Random trap in GBM.dll caused by double clicking a file

Steven Levine — 2011-10-23T17:25:21

In <100.d0ef0300da51a34e.010-r9/a4iiAUwJeoWH0uzbU5w< at >public.gmane.org>, on 10/22/11
   at 05:29 PM, "Gregg Young" <ygk-r9/a4iiAUwJeoWH0uzbU5w< at >public.gmane.org> said:

Hi guys,


Heiko, FYI you don't need option symfile.  OpenWatcom .sym files are not
compatible with exceptq, pmdf etc.  They are standable versions of the
debug data generated by the linker.  This will be dwarf format by default.

To generate compatible .sym files, we need to run the OpenWatcom .map
through mapsymw.pl.

Since we use expectq, we can also use mapxqs to generate gbm.xqs from the
OpenWatcom .map file.

Just to be sure, we need to verify Gregg's test setup, athough it may be
just fine.

The .trp file reports

 Trap  ->  1CC6826B   GBM       0002:0015826B  between _GRO + B and
strrchr - 15

This implies that the stack overflow is still occurring.

 00022090  000221ED   FM3       0002:000021ED  SymDef16/32 read error -
4e6 bytes at 1da 

This looks odd.  We need to verify that the correct .sym/.xqs files are in
place for fm3.exe.  I su

Re: Random trap in GBM.dll caused by double clicking a file

Gregg Young — 2011-10-22T23:29:30

Steven, Heiko

It trapped again using gbm.dll 1.73 (build level info below). I have attached the exceptq 
output. Thanks

Gregg

Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature:       < at >#Heiko Nitzsche:1.73#< at > Generalised Bitmap Module (GBM,WAT)
Vendor:          Heiko Nitzsche
Revision:        1.73
File Version:    1.73
Description:     Generalised Bitmap Module (GBM,WAT)

On Sun, 09 Oct 2011 13:17:38 -0600 (MDT) Gregg Young wrote:

copy 





---------------------------------------------------------------------
To unsubscribe, e-mail: fm2-dev-unsubscribe-wlNknbtBlidAfugRpC6u6w< at >public.gmane.org
For additional commands, e-mail: fm2-dev-help-wlNknbtBlidAfugRpC6u6w< at >public.gmane.org

Startup speed

Gregg Young — 2011-10-22T22:36:03

Steven

I removed an UnFlesh call from StubbyScanThread. It seems to speed the load time here 
significantly.  I have committed the change. I can try only running the remote and virtual 
drives through StubbyScanThread if this doesn't help on your end. Thanks

Gregg

Re: Random trap in GBM.dll caused by double clicking a file

Gregg Young — 2011-10-22T22:31:17

Steven, Heiko

It trapped again using gbm.dll 1.73 (build level info below). I have attached the exceptq 
output. Thanks

Gregg

Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature:       < at >#Heiko Nitzsche:1.73#< at > Generalised Bitmap Module (GBM,WAT)
Vendor:          Heiko Nitzsche
Revision:        1.73
File Version:    1.73
Description:     Generalised Bitmap Module (GBM,WAT)

On Sun, 09 Oct 2011 13:17:38 -0600 (MDT) Gregg Young wrote:

copy 



---------------------------------------------------------------------
To unsubscribe, e-mail: fm2-dev-unsubscribe-wlNknbtBlidAfugRpC6u6w< at >public.gmane.org
For additional commands, e-mail: fm2-dev-help-wlNknbtBlidAfugRpC6u6w< at >public.gmane.org

Re: Random trap in GBM.dll caused by double clicking a file

Gregg Young — 2011-10-09T19:17:38

Steven

I contacted Heiko. His response is below. I created appropriate sym file and sent him a copy 
along with mapsymw.pl. I couldn't get 1,72 to trap but it has always been random. I have 
switch to 1.73 and will consider it fixed unless it happens again. I will add a note in the 
readme and help file regarding this issue. Thanks

Gregg

Hi Gregg,

please find OpenWatcom 1.8 debug versions of GBM 1.72 and 1.73
including map and sym files attached. I hope the option symfile
created the correct symfile.

I had a look at the map file already and it seems to crash inside
of libraw. There was an issue in GBM 1.72 when loading certain Canon
CR2 RAW files (and maybe others) because of a incorrectly handled
function. Eugene Gorbunoff reported this issue some time ago.
The trap dump he sent had exactly the same address and thus
I expect the issue you see is the same.

Here is some background info:
As libraw needs much more stack than GBM binary interface allowed in
the past GBM spawns an internal thread for the l

Re: Trap on close while initial drive scan was still in progress

Steven Levine — 2011-10-04T03:07:49

In <100.905f0100f063874e.002-r9/a4iiAUwJeoWH0uzbU5w< at >public.gmane.org>, on 10/01/11
   at 01:03 PM, "Gregg Young" <ygk-r9/a4iiAUwJeoWH0uzbU5w< at >public.gmane.org> said:


Hi,

<isaid>
flag in not a bad idea because it generally will allow the exit to take
effect sooner.
</isaid>

It turns out we may already have such a flag named fAmClosing which gets
set when the main window starting.

We also have the misnamed fRunning, which probably should be renamed
fAmStarting and have it's sense reversed.

Steven

Re: Directories on command line ignored...

Steven Levine — 2011-10-04T03:05:24

In <100.f8ee0900acb2804e.045-r9/a4iiAUwJeoWH0uzbU5w< at >public.gmane.org>, on 09/26/11
   at 11:13 AM, "Gregg Young" <ygk-r9/a4iiAUwJeoWH0uzbU5w< at >public.gmane.org> said:

Hi Gregg,


This should be resolved by changeset #1635

Steven

Re: Directories on command line ignored...

Steven Levine — 2011-10-04T02:16:32

In <100.f8ee0900acb2804e.045-r9/a4iiAUwJeoWH0uzbU5w< at >public.gmane.org>, on 09/26/11
   at 11:13 AM, "Gregg Young" <ygk-r9/a4iiAUwJeoWH0uzbU5w< at >public.gmane.org> said:

Hi Gregg,


After a bit of analysis, it turns out the problem is something else. 
There is already an easy for forget command line option to suppress the
saved state restore (i.e. -).  What is failing is the initial draw of the
directory containers opened on the command line.

For example

  fm3 - d:\tmp

starts up displaying just the drive tree.  However, d:\tmp is there and
will display if the drive tree is minimized.

I'm off to hunt for a solution to this nit.

Steven