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 ... 26
1
2Dave Yeo: Yes, I plan to make a command line switch to disable that in the future, but not yet. Just in case someone does not like this. So far, I saw only one reason to not do that. Imagine, you have both "My documents" and "Mydoc~3D" directories in the root directory. Then under DOS, the first one will be abbreviated to the second name, and the second name will be inaccessible. If that's not desired, you'd better avoid creating file names ending at ...~<Number>. But such names are usually not needed. So, it is unlikely if you'd ocassionally create such a file/dir.

I can see another problem as documented in the screenshots that Martin provided:
there is a directory called "VBoxAdditions-os2-x86-5.0.51.r200". This directory name is "shortened" to "VBOXA~29.R20".
Obviously, the translation algorithm misinterprets everything after the last dot as a filename extension even though it is a directory. Additionally, the "extension" r200 is clipped to r20 because for a DOS filename extension only 3 characters are allowed.

I'd say that for a directory name, there should NEVER be an extension (but I am not sure how DOS handles a dot in a directory name). No matter what DOS does it would be much safer to never assume that a directory name has an extension and handle dots in directory names just as an ordinary character.

2
It's hard to understand what good it does to return "4 Bytes" on a FIL_QUERYEASIZE if the return value is to serve as a measure of how many bytes you need to allocate when you want to actually request an EA.
As I said, you need an FEALIST with at least one entry plus the extra space for the requested EA Name to return the result. even if the EA is empty/does not exist. That is most certainly more than 4 bytes.

And guess what: obviously JFS.IFS returns 0 bytes on a DosFindFirst with FIL_QUERYEASIZE (that's what I read from Gregg's comments). But seemingly it would return 4 bytes on a DosQueryPathInfo with FIL_QUERYEASIZE. In short: the results are not even consistent in itself.

Who is using HPFS (and therefore testing with it) these days ? Nobody.

3
ok, FS_FINDFIRST / FS_FINDNEXT should therefore also return pfFind->cbList = sizeof(pfFind->cbList) in case of no EAs (!HAS_EAS(pDir->fEAS)) or not activated EAs (!f32Parms.fEAS).

And then, I also wonder if "usGetEASize" returns the correct size. My gut feeling is that you will also need to add 4 on top of what it returns. And I have not yet understood if it really counts the bytes of all the FEA structures (appended by the EA name and the EA data) that it needs to create or only the bytes of the "naked" EA data which, again, would be wrong.

By the way: FS_PATHINFO and FS_FILEINFO do not honour the (!HAS_EAS(pDir->fEAS)) case (that is: the case where no EAs exist).
Unless "usGetEASize" properly handles this case ...

Here is the back and forth discussion regarding FS_FINDFIRST/FS_FINDNEXT:
http://trac.netlabs.org/fat32/ticket/55

4
I just checked the FAT32 source code:

FS_FILEINFO (that should cover API DosGetFileInfo) returns 4 (for FIL_QUERYEASIZE and FIL_QUERYEASIZEL) if there are no EAs.

FS_PATHNFO (that should cover API DosGetPathInfo) returns 4 (for FIL_QUERYEASIZE and FIL_QUERYEASIZEL) if there are no EAs.


FS_FINDFIRST/FS_FINDNEXT (that should cover APIs DosFindFirst/DosFindNext) return 0 (for FIL_QUERYEASIZE and FIL_QUERYEASIZEL) if there are no EAs. This latter one was what Gregg requested as the response for files that do not have EAs.

Read this nonsense about "DosFindFirst" (quoting from the original programmer's documentation):
<quote>
For Level 2 File Information (ulInfoLevel == FIL_QUERYEASIZE) : On output, pfindbuf contains the FILEFINDBUF4 data structure without the last two fields: cchName and achName. This is used with EAs.

The cbList field contains the size, in bytes, of the file's entire EA set on disk. You can use this field to calculate the maximum size of the buffer needed for Level 3 file information. The size of the buffer required to hold the entire EA set is less than or equal to twice the size of the EA set on disk.
</quote>



5
By the way: how does this go together with the fact that if you ask for a specific EA that then, the IFS does have to return an FEA(2) structure, basically returning the EA name that was requested (that is: szName is filled and cbName properly set to the length) but with EMPTY content (that is: cbValue is 0) ?
Returning nothing in this case is definitely WRONG.

That's why in the past I suggested to return a "sensible" size for exactly that FEA(2)LIST structure that would allow to return at least a couple of empty FEA(2) structures but Gregg stated that 0 should be returned.

As I said: a horrible programming interface.

6
Oh yes, EAs.

That's the worst designed programming interface I have ever come across. I am sure MS invented this bullshit in its darkest days. It's a steady resource of misinterpretation (as we all can see from this discussion).

But wait, parts of MMPM are just as bad.

7
The SIOCAIFADDR error indicates that the system failed in adding an alias address (for an existing IP address).
I assume that you did not try to specify an alias for an IP address, and that makes it likely that you have a syntax error in SETUP.CMD, as Roderick has also pointed out.

If you post your SETUP.CMD it should be possible to fix this error.

8
Storage / Re: changing USB volume letter
« on: June 18, 2019, 05:38:19 pm »
DFSee: "change LVM info" and then set '*' (without the '') as the drive letter. That equivalents to driveletter = None = the next available drive letter.

That is how I set up ALL my USB sticks and drives/partitions in order to avoid a driveletter conflict.

As to my USBMSD.ADD that can also mount "large floppy" formatted USB sticks: it also always sets the drive letter of the "fake" volume that it creates (for the 'large floppy' formatted USB stick) to '*' so that it will never conflict with any already used drive letters.

9
Multimedia / Re: Warp with 2 sound cards?
« on: June 06, 2019, 09:55:17 am »
Do you know any email address ?

10
Multimedia / Re: Warp with 2 sound cards?
« on: June 06, 2019, 09:05:16 am »
Lars,

With the current state of MMOS2, the fact that IBM essentially abandoned it around the time of Warp 3, I am not surprised that there are bugs.  I certainly would not put any fault in your driver or applet, in fact I applaud your efforts - I'm really impressed with how well your USB audio driver works.

The sad part - there was a time when MMOS2 was near the top of the game - I can recall when the only system that had better multimedia capabilities was the Amiga.  Unfortunately today it can be a challenge just to get a sound card to work.  But I can't say that I'm all that surprised.


Do you know the [Filters] sections in MMPM2.INI ? If you are a programmer or if you have any idea of how to USE these filters via the MCI interface API functions, I'd be more than glad if you would let me know. What I tried to achieve is to use these filters to convert ADPCM encoded WAV files to PCM WAV files (which is what the IMAADPCM and MSADPCM filter drivers most likely do) but I have no clue of how to "tie" a filter to the WAVE device so that filtering will actually take place. I planned to use that in the USBWAV DLL to make it completely transparent for users to open and play any WAV file, regardless of its internal compression type. I have managed to do that for u-law and a-law compressed WAVE files but I have not "wrapped" these as filters and am calling the registered CODEC procs directly (the a-law and u-law CODECS are also contained in USBWAV.DLL).

Unfortunately, that "filtering" stuff is not documented at all in the MMOS2 programming spec but the Toolkit header files clearly show that a filter is much like a device (it has an MCI DEVICE TYPE just analogous to a WAVE device). It's just not explained anywhere of how you open a filter "device" and "tie" it to a WAVE device.

When I look at the Windows API of what is left of the MCI API (yes, it still exists in Windows even if it is marked as deprecated ...) then I can see that they have removed tons of awkward to use MCI functions like, for example, the connector stuff that nobody ever really understood of how it is to be used. And of course, they also removed that "filter" stuff ...

Lars

11
Programming / Re: Compiling Tookit WPS applications
« on: June 04, 2019, 09:11:42 pm »
This WPS sample is so fucked up that you will have to use the old RC version 4.00 (find as RC16.EXE in the toolkit) instead of the newer version 5.00. That'll eliminate the RC errors you are seeing.
It's even more fucked up in that it links in the incorrect libraries. Once you fix that it still does not work all the way. It'll load but it will not display the properties dialog etc.

The best you can do is to rewrite the makefile. And then, to rewrite parts of the code ...



12
Multimedia / Re: Warp with 2 sound cards?
« on: June 03, 2019, 10:42:13 am »
I just tried the REXX interface: even though it claims to be able to specifically select a WAVE device in the form "Waveaudio01", "Waveaudio02", etc. that will not work. Instead it will effectively use the device that is specified as the "default" device via MMPM2.INI.

I guess that is due to a longstanding bug in Warp 4 and beyond where it is necessary to not only set the default WAVE but also the associated default AMPMIX device to have any sound for a specific audio device (in short: you have to set these as a pair).

But the REXX interface does not allow to specifically select an AMPMIX device.
Therefore, once you set the default AMPMIX device via MMPM2.INI, you are effectively also selecting the WAVE device.

My applet cannot work around this twisted design. It can also not be held responsible. The design is just broken.


Lars

13
Multimedia / Re: Warp with 2 sound cards?
« on: June 02, 2019, 10:28:24 am »
If an app or a REXX script does not explicitly specify a specific audio device then the default device is used. USB 10.227 now comes with an applet that hooks itself into the Multimedia Setup Objekt and that allows easy default device selection ( regardless if USB or not).
But if you want to select a specific device then the app needs some logic to query the available devices and to select from those. OS/2 provides the necessary API but an app has to use it.
For a REXX script, you need to open a specific device,see the REXX mm helpfile on how to do that and what schema the audio device names follow.
Yes it should still be possible.

14
Multimedia / Re: SYBA USB Stereo Sound Adapter: Good or bad?
« on: June 01, 2019, 10:06:56 pm »
No.
No time, no HW, no interest. And for the next 2 years (likely starting end of this year) I will be somewhere else. Which will likely coincede with the end of OS/2 for me.

15
Multimedia / Re: SYBA USB Stereo Sound Adapter: Good or bad?
« on: June 01, 2019, 07:39:57 pm »
I beg to doubt that Doug's judgement is based on any measurable or even measured facts.
This is how the USB HW works: you prepare a transfer by setting up transfer desriptors that point to the data to transmit. Then you kick off the HW which does the transfer completely autonomously, without any SW intervention.
The only thing left is to handle the HW interrupt that is asserted when the transfer is completed (passing the transfer descriptor back to the system, setting up the next transfer etc.).
This basic mechanism is about the same with USB 3 where USB 3 does have additional means to speed up things because I seem to remember it allows to define concurrent transfers (multiple transfers running partly in parallel). Again, it is the HW that does all the transfer, the SW part is negilible.
I don't see how changing SW from 16-bit to 32-bit can make that much of an impact but I am an engineer and not a believer.

USBMSD on the other hand is crippled by the fact that larger blocks of data (like one or multiple disk sectors) typically occupy more than one memory page (a list of "scattered" data). And then it would be helpful if the host controller drivers would allow to pass this scatter list directly to the HC drivers as the transfer descriptor mechanism allows to do just that: set up a list of discontiguous memory blocks to transfer. But this is not currently supported and therefore my workaround was to copy those scattered blocks to a contiguous piece of memory and transfer that in one shot. This DOES show performance improvement because people have already measured the performance gain.


Pages: [1] 2 3 ... 26