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 - Rich Walsh

Pages: 1 [2] 3 4 ... 8

This only applies to PM apps. None of the DLLs listed in SYS_DLLS are loaded into VIO apps.

(3) Not all textmode programs do write into stdout, but there is text output shown nevertheless. This output gets shown in the hidden cmd.exe VIO window and not in my editor window. Can someone explain what this means and perhaps how to get this text in stdout nevertheless?

A VIO window is not a virtual TTY device. It's an emulation of a full-screen text mode session. In these sessions, the screen is accessed via the Vio API functions which can write anywhere on the screen independent of stdout/stderr. When an application like cmd.exe wishes to write stdout/stderr to the screen, it probably uses an internal version of VioWrtTTY().

To capture Vio API output, you would need access to the actual screen buffer used by full-screen apps or the virtual screen buffer used by VIO windows. Unfortunately, these buffers belong to other processes, so your app has no way to get at them.

Applications / Re: XWP and folder file size listing
« on: November 19, 2019, 03:34:53 am »
If all you're interested in is a larger command line window, add this to the "Parameters" field of whatever object you use to start 'cmd.exe':
/k mode 104,43

For the command line window that XWP adds to folder menus, I use this to increase the size and change the current directory:
/k mode 104,43 & cd %*

Another way to open a command line in the desired directory is to drop a file or folder on this object.

Applications / Re: XWP and folder file size listing
« on: November 16, 2019, 10:44:31 pm »
I was about to explain the cause but Gregg beat me to it, so I'll just add this: almost certainly, the culprit here is Doodle Screen Saver which you've been playing with lately. Did you have it installed previously?

FYI... my fix for this was to reset the FPU control word to what VAC expects every time a folder is about to be refreshed. This works most of the time but not always. I don't know why.

Networking / Re: openvpn configuration?
« on: October 03, 2019, 04:42:37 pm »
I have no idea how difficult it might be to create a tun driver for OS/2 - from what I've read, almost all VPN services prefer tun to tap - which is awkward as our port only supports tap!

I wouldn't worry about 'tap' vs 'tun'. Win uses 'tap', so it's going to be supported by commercial providers if they want any customers. Writing a new device driver for 'tun' is a tall order and best avoided if possible.

I'm sure I can tweak the code around loading ifconfig.exe - I'll try and remember to zip up the source tonight.

I suspect that this warning is the cause for the misconfiguration:
> WARNING: 'dev-type' is used inconsistently, local='dev-type tap', remote='dev-type tun'

My _guess_ is that there's some code or flag in the Win version that tells the server to use 'tap' during the initial connection setup - code that's being bypassed because Win32 isn't #defined.

If you'd care to share a diff of your changes, I'd be happy to pull the source and start looking.

Networking / Re: openvpn configuration?
« on: October 02, 2019, 09:50:34 pm »
I'm trying to use Paul's build to connect to a commercial VPN provider but I'm not having any luck (the problems aren't specific to his build - all 3 versions act the same ).

At first I thought it would be easy because the provider (TigerVPN) offers customized '.ovpn' files for each of its servers. After changing "dev tun" to "dev tap", I tried to connect and got this:
Code: [Select]
Wed Oct  2 12:37:36 2019 C:/MPTN/BIN/ifconfig.exe lan1 netmask mtu 1500 up
sem reset rc=300
Error: Interface is not point-to-point.
Wed Oct  2 12:37:36 2019 OS/2 ifconfig failed: external program did not exit normally

Note that it's supplying both local and remote IPs, rather than just the local address. My guess is that it's trying to configure lan1 as though it were a "tun" device rather than a "tap". Setting "dev-type tap" didn't help. Also, our 'ifconfig' complains if you include "up" when setting the address and netmask, so that's another minor problem.

Next, I tried to do a workaround by having it run a script using the "up" and "ifconfig-noexec" options rather than letting it run 'ifconfig' directly. No such luck, doing so produces this:
Code: [Select]
Wed Oct  2 12:48:30 2019 Assertion failed at misc.c:222

I got the same results regardless of whether I used 'cmd.exe' or 'sh.exe' (and the appropriate type of script). Having it run the same dummy script at an earlier point in the process worked just fine, so the issue isn't OpenVPN's ability to run a script or the script itself.

Finally, I considering writing a wrapper for 'ifconfig' that would fix the command line, but then I discovered that the path to 'ifconfig.exe' appears to be hard-coded as "x:/MPTN/BIN". This makes the wrapper idea impractical because it would affect normal use of 'ifconfig' during startup. (IMHO, the .exe should be found via a PATH search.)

Does anyone have any suggestions on how to get this working?

Setup & Installation / Re: eCenter button image
« on: October 02, 2019, 03:26:11 am »
Thanks. I've extracted it, to possibly use the usual, known eCenter button image for xCenter. The extracted eCenter bitmap appears to be either damaged or weirdly wrapped, but so far I've only stripped bytes before the bitmap's header and haven't looked at the back end yet. After a quick fix it's good enough already, albeit not pixel-perfect.

Don't bother with that. Go to where you'll find 'ecslogo.bmp'  and 'ecsminilogo.bmp'. I believe you need the mini version.

Setup & Installation / Re: eCenter button image
« on: September 28, 2019, 03:17:02 am »
The eCenter/XCenter button image is a bitmap resource (number 128 ) attached to 'xwpres.dll'.

Hardware / Re: CUPS EPSON ET-4700 printer problems
« on: September 23, 2019, 07:41:53 am »
The driver you're looking for is here:

This file contains 2 other zips: my port of Epson's open-source CUPS-driver, and an OS/2 Postscript driver based on PSPRINT that I pre-configured to support 511 models of Epson Inkjet printer.

Both require MANUAL installation. Please follow the enclosed directions *exactly*.

Applications / Re: XWP v1.0.13 Beta 1
« on: September 06, 2019, 04:22:23 am »
After installing 1.0.13 beta, Warpin still shows 1.0.12. Is that intentional ?

Yes, it's It won't be 1.0.13 until the GA.

Background: back in the past something screwed up my Warpin Database and that happened AFTER I installed XWorplace 1.0.12 but BEFORE I installed 1.0.13. It is possible that on installation of 1.0.13 there was no entry in the Warpin database for 1.0.12.

Nonetheless the side effect for the AMouse plugin installation remains: you will have to RERUN the AMouse plugin installation (deinstall and then reinstall) after installing XWP (to a different directory). Or fiddle around with files.

To see if there really was a problem, I did the following 3 times: I uninstalled XWP, reinstalled an older version in one of several directories, then upgraded to one of the betas (with a reboot in between each step). In every case, WarpIn forced the upgrade to use the existing directory, not a new one. You may have had a WarpIn failure, but I don't believe XWP was the cause.

Next time, you might consider reviewing the suggested installation directory and possibly changing it before pressing OK...

Programming / Re: fully programmatic menu creation?
« on: September 05, 2019, 09:12:56 pm »
I'm looking into the feasibility of porting some GUI code to OS/2. One of the things needed is to create the menubar and menus completely in code.

From skimming online books, I gather that this is possible, but apparently not as straightforward as calling single API methods like win32's CreateMenu, AppendMenu, SetMenu, etc.

Creating menus programmatically is quite easy but it isn't done using API calls that resemble those in Windows because the windowing model is different.

A top-level OS/2 Presentation Manager window does not have a non-client area where the OS draws stuff like menus and titlebars for you. Instead, each of these design elements is a separately created window of the appropriate class whose size and position is coordinated by the top-level "frame window".

Menubars, popup menus, min/max/close buttons, and system menus are all windows of class WC_MENU. Like any other window, they are created using WinCreateWindow() and are manipulated by sending them window messages such as MM_INSERTITEM. The end result is the same as CreateMenu() and AppendMenu() but the methodology is different.

To get a better understanding of PM windowing, I highly recommend PMTree. It provides a graphical display of the OS/2 windowing hierarchy for every top-level window open on the Desktop. You'll quickly discover there's a lot more to OS/2 windows than Windows' windows.

FWIW... on a practical note: in cases where you need to create custom menus, it is often easier to create and load conventional menu template resources, then customize them by adding or removing items, rather than starting from scratch.

Applications / Re: XWP v1.0.13 Beta 1
« on: September 03, 2019, 05:40:41 pm »
The reason for the trouble with Widgets not being found is this:
for some reason XWP 1.0.13 Beta1 does not install into the same directory as 1.0.12 did. And therefore you need to copy over the widgets from the "plugins\xcenter" directory of 1.0.12 to the 1.0.13 directory tree (in the "plugins\xcenter" directory).

Thanks for pointing this out. The directory change was intentional, the side effects weren't. However, I don't understand why the beta wasn't installed into the existing directory structure - that's the way WarpIn usually works. Did you uninstall the previous version before installing this one?

Applications / Re: XWP v1.0.13 Beta 1
« on: September 03, 2019, 05:59:51 am »
All the files are there.  However, the AN removable object fails to appear as an option in the widgets select.

I'm confused by some of the non-standard terminology you're using. Please do this:

Right-click anywhere on XCenter to bring up its menu, then click on the "Create new widget" item. At the top of the submenu that appears, you should see "AN Removable Media Monitor".
* if the item is enabled, click on it to add it to XCenter
* if it's disabled, then the widget has already been added - either to this XCenter or another one. Are you _sure_ you don't have two XCenters open (one on top of the other, perhaps?).
* if it isn't present, then are you certain that you have 'RemMedia.dll' and 'RemM_EN.msg' in 'x:\sys\apps\xwps\plugins\xcenter'? (The other files don't matter.)

Note:  Checking my other partition, in the XCenter>Properties>Widgets
The an Removable media is listed with the option of rebuilding object when right mouse button selected. My problem partition does not list it in the Widgets page and as a result cannot be rebuilt, although all required files are where they should be.

A widget only appears on the Widgets page if it has already been added to XCenter. If it isn't listed, you have yet to add that widget. Use the context menu for any existing entry as another way to access the "Create new widget" submenu. Assuming RemMedia appears on the submenu, select it to add it to XCenter.

Note: the "Classes" page of the XCenter properties lists all the DLLs XCenter knows about. Is "remmedia.dll' listed? If not, the files probably aren't in the right place.

Programming / Re: DragText & STDIN
« on: September 03, 2019, 03:49:58 am »
If text is dropped and the drop target is an app, then it's possible that the file created by the app will be saved in the directory of DragText. Not in the directory of the source of the text or, for example, in the desktop directory (i.e. the homre of the WPS).

Not supporting files in the the DragText directory is not a perfect option, and using <WP_DESKTOP> if the path of the output file would be DragText's may surprise an user.

Are there other options to exclude DragText input, or to avoid the use of the DragText directory? The dropped DragText file has got rather specific EAs. If the dropped file is located in DragText's directory, and the EAs may be DragText's, then use the <WP_DESKTOP>?

Rather than making a simple task pointlessly complicated, have you ever considered using the target app's "Save as..." menu item? After all, it _is_ the accepted method for choosing the correct name and path for a file you wish to save.

FYI... the reason you're getting the filename 'DT_TEXT' is because your editor doesn't understand DragText's native methods for exchanging text. If it did, the text would just appear and have no effect on the filename. Instead, your editor is reading a temp file created specifically to enable d&d in more apps.

If that's unsatisfactory, you can disable creation of the temp file so the operation always fails ("Setup->Paths->Create temp files" in DT's Settings notebook). If instead you would like to have DT override the app's handling of d&d so DT's native text exchange works, try this (it may not work): open DT's notebook to Setup->Reenable. Look at the entry for 'e.exe', then create a new one for your app with the same checkboxes selected.

BTW... DT has nothing to do with 'stdin'.

Applications / Re: XWP v1.0.13 Beta 1
« on: September 01, 2019, 08:06:53 pm »
So far it works ok, but graph in CPU pulse a little bit out of screen.

I found the problem and fixed it. Oddly, it only affected systems with 1 or 2 cores. On my quad-core, it worked OK. I had to set /MAXCPU to 1 or 2 to see it.

Is there any possibility to read Virtual Address Limit from DosQuerySysInfo but not from config.sys?

Are you referring to the V.A.L setting on the Memory page of the "Kernel" object? The slider there changes the setting in config.sys, so I'm not sure it is a good idea to read the value from somewhere else. Why do you need this change?

Pages: 1 [2] 3 4 ... 8