Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Dariusz Piatkowski

Pages: [1] 2 3 ... 38
Internet / Re: PMMail and EARLYMEMINIT=TRUE problem?
« on: October 11, 2019, 02:56:59 pm »
Hi Neil,

If no POPUPLOG.OS2 entry is created, then are any .TRP files created? If so, these could contain a clue to what is going wrong.

Nah, nuthin'...that's the funny (although maybe quite reasonable outcome given the possible scenario that Doug outlined). The app simply hung the system, in that soft-hang, which is why CTL-ALT-DEL still worked. But no TRP, no LOG, nothing else.

Well, now that this is behind me though, no sense spending any more time of this. Sometimes I honestly just thank the Almighty that things still keep on working...LOL!

Internet / Re: PMMail and EARLYMEMINIT=TRUE problem?
« on: October 11, 2019, 02:13:41 am »
Doug, everyone...

Take out both REMs, and you probably won't have any more problems, for a while. REM DLLBASING=OFF causes shared memory to allocate on memory boundaries, which causes a lot of fragmentation. You may have 150 M left, but if the biggest chunk is 20 K, you have a major problem.

Older systems would be slowed by using DLLBASING=OFF, but any system after the 486SX won't have any problems with it...

Yup, that did it.

So both REMs got removed, which means I am now running with the following config:

Code: [Select]

PMMail comes up fine, re-started multiple times, no issues found. So far the other major apps are chugging away as well.

Great pointer Doug, appreciate the insight.

Now off I go stripping out some hardware (like the SCSI AdvanSys card that's my scanner connector) to see if that will have any impact on me trying to actually run in the full 6-core CPU configuration.

Internet / Re: PMMail and EARLYMEMINIT=TRUE problem?
« on: October 10, 2019, 02:04:48 am »
Sigurd's right on the money here...I used to run HPFS386 on all my drives, switched to JFS about a year ago (or so). With the HPFS386 cache sizes, even small ones, I was never able to use that setup.

Today...well, PMMail was the only app I noted failed consistently. There may be other ones as well, but given how important email is I never actually got beyond that testing criteria.

Here are some of the CONFIG.SYS entries:

Code: [Select]

My JFS cache is set to 128Meg, and otherwise I do not think there is anything unusual about my setups.

Plenty of free shared memory (as reported by the 'Free Shared Mem' utility) over 150Meg.

Is there anything I can do to capture the crash I'm seeing? So far nothing in the LOG directory, nor in popuplog.os2.

Internet / PMMail and EARLYMEMINIT=TRUE problem?
« on: October 08, 2019, 02:16:51 pm »
So I figured I would try a few different options in order to improve the configuration of my system, but as I did I came up with this surprising (to me anyways) discovery:

Setting EARLYMEMINIT=TRUE in CONFIG.SYS causes my PMMail to crash the whole machine...not a hard crash, but CTRL-ALT-DEL is the only way out.

This is applicable to PMMail (32534).

Has anyone encountered this before? Any ideas what may be causing the symptom I'm seeing?

Applications / Re: Firefox 45.9.0 can no longer play Youtube movies ?
« on: October 08, 2019, 02:01:42 pm »
Dave, everyone...

...mark the DLLs high afterwards and reinstall mozturbo...

We often talk about this approach, which I am using here successfully by all accounts. However, I honestly never know if I should be marking the DLL as:

1) code only
2) data only
3) both

Right now I have them all marked as 'code only' since in the past I have read various posts suggesting that not all data objects may be compatible with the load high option, especially when it comes to the kind of software that FF is, meaning: numerous DLLs being invoked, therefore large amounts of data movement, etc.

But is there a better explanation than that?

Utilities / Re: Where do I find SciTech Display Doctor?
« on: October 04, 2019, 02:48:06 am »
I have to agree with everyone re: no better result with the AN version of SNAP.

In my case I ran non-AN SNAP for several years on a multi-core machine. No problems other than the dreaded pre-WPS Desktop blue-screen "stuck" symptom. This only happens if I have all the 6 cores of my CPU enabled, with just 5 all is good. Same behaviour with AN SNAP.

Otherwise, while in use I did not see any lockups.

Applications / Re: Firefox 45.9.0 can no longer play Youtube movies ?
« on: September 27, 2019, 04:16:34 pm »
Hi ivan,

...Hi Dariusz,

As soon as I get the 'new' computer up and running (as above) I will start experimenting as per your suggestions, don't know when that will be as friends are going to take me out for my birthday, the big 80.

Ahhh...super...Happy Birthday sir!

And I thought I hit the "big one" a few years back when my 40 came around...LOL!!! Rock on.... ;)

Applications / Re: Firefox 45.9.0 can no longer play Youtube movies ?
« on: September 27, 2019, 02:15:17 pm »
Hi ivan,

...I isn't just one core at 100%, but 1 core for a few seconds then it switches to another core for a few seconds then another one.  It works through all 4 cores and the only way to kill it is the big red switch.

A new profile, without any addons, doesn't do anything to change the behaviour (the computer has been switched off more times in testing than it has since I built it :P normally up 24/7 since it also runs the FTP server).

Alright, so this behaviour is very similar to what I have seen on numerous occasions as we were testing the FF49.x builds. Here is what I found out to be the two contributors:

1) high-res timer
I have the following in my CONFIG.SYS, without this my Phenom II X6 cores are constantly jumping around: SET NSPR_OS2_NO_HIRES_TIMER=1. This appears to be very much dependent on your hardware. Some people say it works great letting FF haver access to that timer, others (like me) have to disable it, or else the CPU cores are constantly going crazy.

2) layout.frame_rate FF profile setting
This controls how frequently FF attempts to re-paint the screen and based on my understanding other platforms allows FF to avoid flicker as you scroll pages up and down (the back end code ties-in to things like monitor vsync refresh rates, etc.) However, for us this simply does not exist (the process making use of such an API to make the determination of what rates to try to sync up to), although an effort was started to develop this because SNAP drivers after all do in fact have that API, again, limitted to SNAP only AFAIK.

Now, if you are going to play with this setting here is what the options are (copy/paste from an on-line article):
1) '-1' use hardware vsync to tick the refresh driver
2) '0' means: Enable "ASAP mode", which ticks the refresh driver as fast as possible and disables vsync
3) Values larger than zero mean: Use a software timer to tick the refresh driver at the specified rate (N times per second)

On my machine I have it set to '0', which is the default value in FF 45.9.0. The tradeoff to using this is that as you refresh less often (values get progressively higher) that CPU load diminishes however FF starts to feel it is literally slow to respond to your keyboard input, page up/down commands, etc.

Anyways, try these two things out. Do them one at a time, I would recommend #1 (high-res timer setup) first.

Hardware / Re: SNAP and dual-head display setup recommendations...
« on: September 19, 2019, 03:41:15 pm »
Ah, one more question for everyone: what interfaces are you using to enable dual-head setups?

What I mean is the following:

1) Head_0 => DVI, Head_1 => RGB (my current config)
2) Head_0 => DVI, Head_1 => DVI (my understanding is that SNAP did not support this on any chipsets)

Here is specifically what I am referencing as it appears in the SNAP readme.txt file:

Code: [Select]
Please note that there are some restrictions imposed for MultiHead:

1. Only CRT (15-pin VGA) output is supported for MultiHead at this time.
   You may need to use DVI->VGA connectors on some graphics cards.  The
   only exception to this is the ATI Radeon chipsets, which can also do
   multihead in CRT+DFP configurations, due to native panel programming.
   CRT+LCD, CRT+TV, and DFP+DFP are all unsupported at this time.

My experience matches this, I'm curious what others have seen?

Hardware / Re: SNAP and dual-head display setup recommendations...
« on: September 19, 2019, 03:18:04 pm »
Hi ivan!

Now if SNAP would work with the Radeon Vega 8 Graphics of the Ryzen processor I could get back to what I used to have on my old computer, a couple of 28 inch 1920x1200 monitors.

SNAP is not happy with the Vega graphics and Panorama works as long as I don't want to do anything with extensive graphics activity.

You know, why I have been relying on my ancient (by today's standards anyways) ATI X850 XT PE video card to cover my OS/2 display needs, it is very clear that this hardware has exhausted all of it's power.

I have seen some feedback on the benefits of running the trully new hardware in native VESA mode (providing that the BIOS supports it) with something like the Panorama driver, end rsult being performance that is actually much better than the older hardware which had the optimized/accelerated device drivers (SNAP).

Since you seem to have Panorama working with at least a single display, how are you finding that performance in comparison to the SNAP driver setup?

Oh and regarding the extended graphics with Panorama, it is my understanding that there are 3rd party screen extenders that have been developed to enable this specific functionality...have you tried them?

Hardware / Re: SNAP and dual-head display setup recommendations...
« on: September 19, 2019, 03:12:12 pm »
Hi Doug!

I have a dual head display and it changed my life.

After getting the memory used by SNAP adjusted (down) to what was really needed, I haven't really had any issues...

I couldn't agree more...LOL, which is why it still kind of boggles my mind why we have not spent any more time/$$$ on getting us updated SNAP or expanded Panorama functionality (by that I mean native support for dual-head configuration as opposed to relying on 3rd party screen extenders, etc.). I understand that required funding, an for my part was always happy to support that specific feature with a real additional-cost funding...I just wish someone would take it on.

Agree with the application behaviour findings, seeing the same here.

Hardware / SNAP and dual-head display setup recommendations...
« on: September 17, 2019, 03:28:05 pm »
Hi Everyone,

So I got my dual-monitor setup up and running: ATI X850 Pro with two Samsung 245T panels. With their native resolution of 1920x1200 that gives me an OS/2 Desktop of 3840x1200...yey!!!

...but as I'm starting to discover there are some things that aren't quite biggie any of them (no hard errors or app crashes, more of an annoyance), but I'm looking for suggestions and/or helpfull hints that others with such dual-head setups have found beneficial.

Currently using the option to display pop-up windows on Head_0.


Networking / Re: NcFTP - RPM package application not quite right...
« on: September 15, 2019, 05:36:36 pm »
Hi Dave,

Try SET PAGER=less.exe

I've got this already in-place, or to be precise, the MAN page reader defaults to using 'less.exe', the other option was to actually set it to MORE, which I did not do.

But...just to be sure I did define that in the CLI window and started NcFTP from there. Issuing 'bookmarks' command still resulted in MORE being used, so it would appear NcFTP itself is coded to rely on MORE as opposed to the 'SET PAGER=' setting. That's OK, I now actually have visibility to the bookmarked FTP sites, which was previously broken.

Thanks for the suggestion though!

Networking / Re: NcFTP - RPM package application not quite right...
« on: September 09, 2019, 02:45:08 pm »
So after initially posting this off I went looking at this 'MORE' command...heck, I do know it works, I have used it previously, pretty much as the default until 'less' became available!

For some reason, not sure why, was missing from my boot drive..ugh??? :o

Luckily I had an older backup partition still kicking around and pulled that one over. Indeed, now NcFTP certainly works because the 'sh' shell commmand issues a 'more' statement which is intended to scroll the bookmarks contents.

You are right though Dave, I wish I could tweak that to use 'less' because that approach has some additional functionality that 'more' does not.

Hey Doug,


Personally, I wouldn't call that driver "stable", in any sense of the word...

Fair, but in my experience that is THE driver that works on my hardware. I find the device driver support rather lacking (even through AN) and given my previous experience of working several tickets (SNAP and Panorma, none of which went anywhere) I decided to avoid that approach altogether.

Look, given that David isn't having much luck with the latest and greatest MMRE drivers it would seem to me like an alternative approach is what's required, even if that means having an obsolete driver that actually works better than the generic & latest MMRE one!  :P

Pages: [1] 2 3 ... 38