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 ... 64
Hi Dariusz, before monitors supported EDID, you really did have to set things up manually for your monitor, and depending on the monitor specs you entered, the screen object would have shown the possibilities I assume. I only had a VGA monitor back in the Warp v3 days and don't remember the screen object... are right...I do recall those days after all. My first OS/2 video card (which would have been OS/2 v3) was actually a Cirrus Logic shipset card...but heck, those drivers are long gone from my machine.

Dave's suggestion is probably the best-fitting driver package you're going to find. I'd give that a shot...

...The default display parameters for the OS are VGA 640x480 256 colors.  I know the Genoa card can do better and was trying to find a better resolution and bit depth.  But, as I say, I am not very experienced with the OS and don't really know what's possible or how to achieve it.  I thank you all for your help.


So I'm curious, when the WPS (Work Place Shell) comes up and you see your OS/2 Desktop, are you able to select the "OS/2 System => System Setup => Screen" object?

I have had SNAP deployed here for some years now so I am not 100% sure, but I am nearly certain that this is the standard OS/2 "screen-setup" object. If that objects exists on your machine, you should be able to open it up and select a higher resolution and colour depth. Of course these will be driven by the system's ability to recognize the display montior hardware, but it's worth a try in order to avoid getting stuck with the ancient VGA resolution.

| SciTech SNAP Graphics for OS/2 requires a version of OS/2 Warp 3 or
| later in order to run. More importantly, it requires at least Warp 3
| with FixPak 35, or Warp 4 with FixPak 5 installed.

Right...and per Charles' original post (although the BOLD is my add), where he stated:

...I am completely inexperienced ("noob") with OS/2 but I installed V3 on a '586 VLB machine and had a running system until I tried to install a video driver for the Genoa Windows VGA 24 VLB video card...

the suggestion to deploy SNAP should provide a viable and hopefully better result.

Here is something else you could try: head on back to Hobbes and d/l the SNAP video drivers. Here is the direct link to the ZIP file =>

Given that your video chipset is an older one I'm not sure if that last public version of SNAP supports it, but the README will most likely point it out.

The benefit with these drivers is that they simply have additional capabilities to help you deal with different monitor formats, resolutions, etc.

Worst case if SNAP does not work, is that you repeat the same VGA Recovery process that you had just gone through.

Hey Charles,

Probably the quickest way to get back to a working system is by forcing the VGA mode at boot-up.

Here is what you need to do:

1) Re-boot the machine
2) when the white rectangle pops-up in the top LEFT corner of the screen (during early boot stage) you hit ALT+F1
3) you now should be looking at a menu that has several choices, select option 'V' I think (if I remember correctly), this will force the box to book in VGA mode

Try it and let us know what happens.

Hi Doug,

...I don't know if you can make shadows of file system objects stored on media that doesn't support EAs.  If the shadow is stored in OS2.INI then you probably can.

Yes, this works. I have the "Documents" directory off of my NAS showing on my OS/2 Desktop as a Shadow object. As long as I connect successfully to the NAS (which is done during boot through NetDrive) that object will be 'live' by the time WPS comes up.

Your idea on how to use the WPS Shadow functionality is precisely what I wanted to do.

Hardware / Re: OS/2 on Virtualbox with 8 COM ports
« on: May 07, 2021, 03:08:43 am »

Hi. First time here and first post. I am the CTO of a hardware design company (Est 1985) in Canada and have strong design experience with PCI, PCIe and USB products.
Sam came to our company many moons ago when he resided in Michigan (IBM), just prior to us becoming a supplier to PictureTel who used our ISA adapter (back then) on OS/2. It was the industry's first jumperless I/O adapter.
Kumar Bhatia
Axxon (OEM) Inc.

No's been many many years since we talked, but say around the early to mid-90's I would stop by once in a while at your shop and just talk pure computing stuff, or better yet, the field of Artificial Neural Networks. Not sure if you recall, but during my first visit to your location I remember asking to speak to the president as the business name, Axxon, was just so darn close to the AXON of the ANN fame (and well, the biological build we all have within us), which was my field of study (thesis work) for my last year of undergrad at UofGuelph.

Anyways...a bit of a memory lane walk there, and welcome to our forum. We have just a couple of OS/2 users from Windsor on here, and as both Martin and Neil pointed out, this forum is largely focused on grass-roots type of discussion around our platform.

ArcaNoae on the other hand is the leader in the commercial space today, and I for one would hope they might need the sort of solution you can provide. Lewis will be able to answer this I believe.

Either way, would love to catch-up...heck, I remember you telling me about the assembler work you guys were doing at that time, most of it device driver software if I recall?

Hi andreas,

i'm not a programmer. and maybe my idea is stupid.
but maybe it's possible to create a folder that automatically collects shadows of every opened document (maybe just some types of documents - recogniced by the data-type or -ending, like *.txt).
additionally you'd need a routine to automatically delete the older shadows.
not sure if that is possible though..

at least it would be nice to have an option for each file or folder to create a shadow into a certain folder with one click (manually)..

No, not a stupid idea...there are none like that in my book, and besides, this is a "thinking" session all ideas merit review, regardless how "crazy" they may feel/ worries!  8)

What you are suggesting is probably 90% of what I was envisioning as I started to think about this. This is why I had originally talked about it from the perspective of defining an object class which could have it's functionality extended. I thought of the Folder approach as well, and as you pointed out, of using WPS shadows to represent the MROD objects themselves.

I probably need to spend time with the WPS docs to understand how big of a challenge it may be to either extend the existing Folder class, or to flat out define a new 'MROD Folder' which only does this single thing. Either way, I would expect that we should be able to use object inheritance to pick up all WPS functionality currently avaialable for regular WPS folders and use that in our MROD Folder object. As such, things like shadows, being able to open with alternative applications, etc. would all work by default.


The WPS way of work was always different than the Win way. You shouldn't navigate through program folders but open your document folder or even more advanced one of your work areas. If you don't like to open your pdf with the standard program you only have to right click and select the other programs from the open with popup menu...

OK, but that ONLY works assuming the actual storage media filesystem supports all the OS/2 WPS functionality AND you have your documents centrally located. Great point, but even on a native OS/2 install how likely are you to have all of your documents in a single folder? Yes, I am oversimplifying a bit, but the point is that even if you had a central Documents folder where all the other documents were stored in sub-folders, you'd still need to navigate down to them. And I certainly do not want to toss Gigs of docs into a 'Working Folder'.

...The programs own history are necessary for other OSes which aren't designed like the WPS (document centric) but build around programs. Maybe also we OS/2 users forgot a bit the WPS philosophy cause we are also have to use the program centric model of other OSes?

Yes, I think I agree with most of your stipulation here. I have always found OS/2's way of dealing with docs as an object far superior to anything else out there. Still, there is an element of convenience (always will) in being able to re-open an app specific file from within that ap.

However, I would say that the challenge here isn't so much brought on by forgetting about WPS philosophy, rather it is driven by the recognition of the changing storage device landscape. As I previously mentioned, my OS/2 box is no longer the central doc repo, that stuff has moved on to the NAS box, which does not even support EAs.


No, it would only work for files opened via the WPS, but see last paragraph. But that's exactly the question: what are the REAL expectations ? If you use an app to open files and that app already has support for "most recently used docs" then there is no need to offer that via the WPS.

The WPS knows nothing about applications. But it can detect that files were being modified on file system level (I don't know if this is limited to file content or also for changing EAs).

For me it's the WHOLE thing...meaning: the utility should have visibility to ALL WPS file "Open/Close" events, the key stipulation here is WPS, b/c in my mind that would allow us to utilize as much of the currently existing OS API support as possible.

This approach is the core function of the utility: avoid having to navigate through multiple paths to re-open a document. While most of us may think of this as storage volume navigation (so drive paths, etc.), one should also consider the user-interface pathway to the application itself as well. In other words, why force me to navigate all of my Program Menus just to 1st open the right application so that I can then select the file I'm interested in?

I want it all done with "one click" instead! Should I want to open that particular file with an alternate application (so back to my use-case of PDF files: that could be GSView, or Lucide or QPDFView) I would then have the WPS provided option of selecting that alternate application. This is part of the reason why I was starting to think of it as a folder object where the files themselves could be listed as shadows...thus preserving all of the existing WPS functionality that readily applies to dealing with such objects.

Hi Andi,

There already exist WPS functions that can tell you which file objects are currently active/open and there are notifications when files are changed on a file system level.
Sounds like a very elegant way. But does this also work when you f.i. open a file from cmd line in an editor which writes this file afterwards. And do you get notifications when you f.i. open a pdf by double clicking in the email client which fires up qpdfview and when do 'Save as' in qpdfview?

Hmm, I cannot see being able to get that to work reliably, here is why: those types of "Open" events typically place the actual PDF file in temp storage, so stuff is pulled out of email body/ZIP file/whatever, tossed into temp and then the default application is evoked. The problem with making this work reliably is that the temp storage may not be persistent...heck, all my TMP/TEMP settings point to a RAM - sure, clean - sure b/c a re-boot completely wipes it clean for me.

But this could be turned into a setting that the user activates (meaning, s/he decides that YES indeed, they do want those kind of openning events tracked and listed in the MROD dynamic list).

Applications / Re: Most Recently Opened Documents - Discussion
« on: May 03, 2021, 08:46:32 pm » guys, I think I will take that conversation to another thread, I feel bad I hi-jacked Martin's post!

High level though, my thinking is as follows:

1) Intercept any application 'Open File' action at the OS level (so literally having some kind of a daemon that watches to see what files are being opened)
- user settings would possible filter this down to only a certain sub-set of applications
- this daemon would keep track the "most recently x opened" files, as per the user's settings

2) Show the user a dynamically maintained list, where one would simply interact with the object using the default system behavious (so rely on Associations, etc.)
- the "container" object that would allow the user to select such a file would be either a purposely built own class object, or perhaps a folder where the objects themselves would be represented as SHADOWs - idea being to re-use as much of the underlying OS structure, and therefore functionality, as possible

My goal was very similiar to what Lars' thinking is: use as little NEW code as possible, rely on existing platform / OS infrastructure to handle much of the lifting.

Thus my original question: what would be best suited to serve as that "container object"? In parallel to that, what are the current APIs that I could use to monitor the current files that are opened?

Andi, maybe as you suggested that intercepting DosFileClose would allow me to build that dynamic list of files that have been opened...that list would continue to be purned as per user settings and filters, which in theory should give us a workable solution.

Use Case
Let's say I only care about PDF files. I have them all over the place, my NAS box in particular...and I just do not feel like going through the full directory/path navigation each and every time I need to open one up. This to me is very real you guys...I moved our documents from the OS/2 box onto the NAS some tiem ago, we now have a single centralized DOC repo for the full house...but that requires me to do a hell of a lot more mouse clicking to just get to the file I want! lol

Anyways, Martin, I'm sorry...your post TITLE was precisely what I had in mind for some time now and the ideas just needed to "come out", but let's take this to another thread, please see =>;board=15.0 in Programming section.

Hi Martin,

Can't help you with the questions you posed, but I'd like to piggy back off of the topic you started and ask the following question: what WPS class would need to be extended/replaced in order to create a "Most Recently Opened Documents" object which literally shows a list of documents (should have a user adjustable setting to control how many are shown) there were most recently opened.

In short, I wish there was an easy way to re-open the same doc I had just looked at, withouth me having to go off fishing for it once again.

I suppose this would be a Folder like object, but it really would not have any persistent objects (the previously opened Documents) present there, instead maybe shadows could represent each one?

Utilities / Re: QT5 Runtime
« on: April 23, 2021, 04:49:22 am »
ivan, Joop,

Head on over to the GitHub HOME for QT5 =>

Scroll down a tad, you have the option to d/l the ZIP files as well.

The Wiki itself (with all the gory details, or the "goodies", it all depends on how you look at it and what in particular you are looking for) is HERE =>

Utilities / Re: QT5 Runtime
« on: April 21, 2021, 07:11:16 pm »
Hi ivan,

'yum list qt5*' will return a whole bunch of RPM packages...I'm sure somewhere in there is the runtime...I haven't looked at them myself quite yet.

Heck, 'yum list qt5*base*' shows the following:

Code: [Select]
[G:\]yum list qt5*base*
Loaded plugins: changelog, downloadonly, ps, replace, verify
Available Packages
qt5-qtbase.i686                           5.13.1-1.oc00              netlabs-rel
qt5-qtbase-common.noarch                  5.13.1-1.oc00              netlabs-rel
qt5-qtbase-debuginfo.i686                 5.13.1-1.oc00              netlabs-rel
qt5-qtbase-devel.i686                     5.13.1-1.oc00              netlabs-rel
qt5-qtbase-examples.i686                  5.13.1-1.oc00              netlabs-rel
qt5-qtbase-gui.i686                       5.13.1-1.oc00              netlabs-rel
qt5-qtbase-private-devel.i686             5.13.1-1.oc00              netlabs-rel
qt5-qtbase-static.i686                    5.13.1-1.oc00              netlabs-rel

Pages: [1] 2 3 ... 64