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 - Lars

Pages: [1] 2 3 ... 58
I know that this can be argued forever but I would NOT put "VCompat" under /pub/dos.

"VCompat" is a 32-bit OS/2 VDD (virtual device driver). It CANNOT be loaded by the DOS operating system. The same holds true for "VSound" and "VDMA" (from the same author and in the same directory as "vcompat").

"2GBFix" on the other hand is a DOS TSR (Terminate and Stay Resident) program that can be executed under a real DOS or inside an OS/2 VDM.

What might be reasonable is to have a new subdir "/pub/os2/system/drivers/vdd" to place these kind of drivers.

By the way: the "2GBFix" functionality is included in "VCompat". In short: it's easier and preferrable to use "VCompat" as it also has many additional DOS fixes.

Multimedia / Re: How do I change this default behaviour?
« on: December 01, 2021, 04:53:41 pm »
Ok, then try this, assuming we are talking about avi files:

1) create a dummy file "mmtest.avi" on the desktop like so: oo /n MMMPG mmtest.avi "<WP_DESKTOP>"

2) Use the context menu of that file to add "mplayer" to it as an open action. Move "mplayer" up the list to be the topmost/first action (that is: the default action)

3) now, modify the default view: oo mmtest.avi "<WP_DESKTOP>" "CLASSDEFAULTVIEW=4096;" (find out the oo switch to modify an object, I don't have that handy ...)

Maybe that will do the trick. If yes, you can then automate the process (with a REXX script) and do this for all the various file extensions that you want to have mplayer play.

Hardware / Re: Using a LaserJet 2100m on a Print Server
« on: December 01, 2021, 04:39:19 pm »
By "old printer", I do not mean "bad printer". It's just that bidirectional communication with a printer was not standard when printers with parallel ports were first built.

Multimedia / Re: How do I change this default behaviour?
« on: December 01, 2021, 10:28:50 am »
Yes, the complexity is ridiculous. But if Rich's suggestion means that the "first associated program" will open the file, then you'll also need to associate your desired program and it will have to the "the first".

And in order to do that, I suspect that you need to set up a program object for your desired progam and then, on the association page, to assign by file type and/or file extension the files you want to have handled by this program (the *.AVI files in your case). What I don't know is how to convince the system that this is the "first" program for the files of given file type and/or file extension. I hope that you can specify the usual placeholder parameters in the "command line" entry field to have the program started with additional parameters and the filename.

Since with Rich's suggestion, on a double click, the open action now is "the first associated program" and no longer the default action (which was "Play"), your program should then be called with the filename as the argument instead of the "Play" action invoked (which likely is to invoke the default MM device specified through MMPM2.INI ...).

So I hope at least.

Hardware / Re: Using a LaserJet 2100m on a Print Server
« on: November 30, 2021, 10:40:20 pm »
Why don't you use the SLPR port driver and specify the IP address of the print server ( as "LPD Server" and "Printer" (without the quotes) as the "LPD Printer" ? That's at least what the DLink config page mandates (if you read through the help for "LPD Printer" you will see that it is the LPR Queue Name that you need to enter).
The use of USB should be completely transparent as long as the USB host implementation in the print server works according to standards.

EDIT: the reason why you don't see a "proper" name for your printer might indeed be related to the USB to parallel port adapter and/or also the printer itself. I suspect that you need bidirectional communication functionality to query a "decent" printer name from a printer. If the printer is very old, it might not support that or the USB to parallel port adapter might not support bidirectional communication. Nonetheless I would hope that at least you can print to that printer with the settings given above.

Multimedia / Re: How do I change this default behaviour?
« on: November 29, 2021, 07:02:37 pm »
On second thought, it's likely much easier to write a new WPS class that registers for certain file types/extensions and then to override the "open" method (invoked on a double click). And that is what the CWMM classes likely do. Then they just invoke some app with the filename. And the app seems to be configurable via some INI key or config file.

Multimedia / Re: How do I change this default behaviour?
« on: November 29, 2021, 05:05:23 pm »
You are mixing up MCD drivers (see "MMPM2.INI") and MMIO procedures (see "MMPMMMIO.INI").

MCD drivers are for actually playing/recording audio/video content, MMIO procedures are for converting file formats (say from ADPCM to PCM) so that they become playable by MCD drivers (which only know a limited number of file formats to play, for audio this is almost exclusively: PCM) or transform to a standard format on record.

I would need to look at what commands an MCD driver needs to support but there must be something like OPEN , LOAD and also PLAY. And I seem to remember that either on OPEN , LOAD or PLAY, the MCI driver gets passed a filename or an "hmmio" which is a handle to an already opened audio/video "file" (where "file" can also mean data in memory). Search for "MCI_OPEN", "MCI_LOAD" and "MCI_PLAY" ...

Then, simply spoken, you'd just start the app with that filename (if it is a real file, otherwise you would need to create a temporary file ...). Then, in order to deal with concurrent calls, you need to deal with device IDs and possibly serializing access to that "MCD device" (maybe that replay app can only play one file at a time ...).

And then, in order to easily support multiple different replay apps, it would likely be a good idea to make that configurable via either some INI file or via some settings page in the "Multimedia Object" or some such. There are a few other functions that are mandatory to support (but won't need to do much for the envisaged use case).

And yes, the entry point of such an MCD driver (DLL) always is "mciDriverEntry".

Have a look at this, I think that's a good explanation of somebody who knows:

By the way: MCD drivers are added via a CARDINFO.DLL resource DLL. It's some work to write one but it's not extremely difficult (maybe there also exists some script approach but I don't know). An example has been the "Timidity MCD" which essentially wrapped the Timidity SW so that you could play MIDI files with a double click.

Multimedia / Re: How do I change this default behaviour?
« on: November 29, 2021, 10:44:13 am »
The MM classes do make an attempt to define some "default" behaviour when you double click a file for the file type/file extension they are responsible for. I have not looked at the MM classes but I'd expect that they just do a MCI_PLAY command on the MM device that is associated with that file type/extension as a default. The CW MM classes might have implemented a smarter approach (looks like it).
Anyway, the "default" MM device for some given file type/file extension is defined through MMPM2.INI. And unfortunately, that "device" has to be an MCI device which essentially boils down to being a DLL with a defined entry point and command support. Certainly not any arbitrary EXE file. It would be possible to "wrap" invocation of an EXE file as a MCI device but this has to be implemented...

Hardware / Re: New ArcaOS USB driver.
« on: November 28, 2021, 02:43:58 pm »
Sent to your private email.

Hardware / Re: New ArcaOS USB driver.
« on: November 27, 2021, 03:40:49 pm »
I have that test version ready. Bumped up the version number to 14.106 so as to avoid confusion.
Where do you want me to send it to ?


Games / Re: DOS VDM - USB and Game port Gamepad support
« on: November 27, 2021, 10:36:51 am »
I just tested: libusb uses "Usbquerydeviceinfo" to query the devices. And "lsusb" uses libusb to show the devices list. It will only show non-hub devices (that is: only "end-user" devices).
Unless David has added something. But that of course will never be publicly visible. He'll always roll his own ball.

Games / Re: DOS VDM - USB and Game port Gamepad support
« on: November 27, 2021, 10:19:42 am »
That struct returns the parent hub index a device is attached to as "parentHubIndex". But there is no public way to query the device index of that hub device. (query the device index from the hub index) And therefore you cannot build up the hierarchy.
It would not be awfully difficult to extend the functionality but now we have quite some code out in the field that makes use of USBCALLS. We could add another function that can query the device index for a given hub index. Then an application could of course build up the hierarchy.

EDIT: and sine the struct does not contain the device index but rather the real device address and rmDevHandle, then that new function should better return device address and rmDevHandle.

Games / Re: DOS VDM - USB and Game port Gamepad support
« on: November 27, 2021, 12:09:34 am »
As to controller,hub,device info: I assume you are quoting what the testlog from AN returns.
For debugging purposes, David added an interface to USBD.SYS to completely query all USB devices, including hubs. Since USBD.SYS of course knows about all USB devices, including USB hubs.

But USBCALLS (and USBRESMG) does not have access to that interface.

Anyway, libusb is using USBCALLS to implement its functionality, so that is the proper way to go. Because that is what usbhid obviously uses.

Games / Re: DOS VDM - USB and Game port Gamepad support
« on: November 26, 2021, 01:24:58 pm »
I am currently working on libusb (for various reasons).
I did some updates on what port you will find what device. That'll hopefully solve it. We will see.

Note that our implementation of libusb will NEVER be able to list the whole bus hierarchy (which encompasses root hubs and chained hubs) because USBD.SYS (and therefore USBRESMG.SYS and also USBCALLS.DLL) does not publicly expose hub information.

EDIT: now I see that "libusb_get_port_numbers" tries to resolve the whole bus hierarchy, from the plugged in device upstream up to the root hub port. As I said, that cannot work. Unless we modify USBD.SYS, USBRESMG.SYS and USBCALLS.DLL.

Hardware / Re: New ArcaOS USB driver.
« on: November 25, 2021, 10:48:11 pm »
I'll try and knock it together. As time permits.

Pages: [1] 2 3 ... 58