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] 4 5 ... 14
Article Discussions / Re: ArcaOS Wishlist - 6 months !!
« on: December 30, 2017, 08:37:55 pm »
Here you go with 2 drivers that I have written:

The WPIs contain all the source code. While they might not serve a practical purpose for most people, they are a live example of what can be done in a device driver.

And here is another one (including source code).

The latter is a PSD. Hopefully the source code contains enough comments for people to understand :-)

Programming / Re: Compiling an OS/2 Driver
« on: December 30, 2017, 04:57:35 pm »
Hi Martin,

my gut feeling is that you actually want to do more than just compiling a driver. My feeling is that you want to enable others to actually write a device driver, maybe you are thinking about people capable of writing a device driver for Windows but who have no clue about OS/2.

That said, I'd go with Roderick's hint. Have a look at David's driver library (for 16-bit and also for 32-bit).
Don't use the DDK for these purposes:
1) the DDK is a mess. It is unstructured, things are difficult to find.
2) the DDK mostly relies on the old 16-bit Microsoft C compiler and/or masm.exe, an extremly old Microsoft assembler that can only deal with nothing better than an 386 CPU.
2) I do not recommend to take any of the DDK code as being correct or suitable for SMP systems. Fact is, many of the DDK drivers are VERY old. You cannot rely on that code to work on any modern system, SMP systems in particular.

The only thing that is really necessary from the DDK are the header files as they basically define all of the internal interfaces/structures (as far as things have been made public to begin with).

Unfortunately, even with this info there are things about OS/2 that are really special:
1) a 16-bit driver is, well, 16-bit. For example, if you want to read a 32-bit HW register there is usually a HW requirement to read it as full 32-bits. That will require a minimum of assembler code because you will need to use memory instructions that will move a full 32-bit of data. A 16-bit compiler won't generate these instructions. There are more of these issues.

2) You will need to fumble around with virtual addresses: a selector and an offset. That is what most programmers nowadays will have forgotten about. Then there is the additional difficulty to hop back and forth between virtual addresses, linear addresses (a 32-bit offset in a flat 4 GB address space) and physical addresses. The reason for this most likely will be that virtual addresses can only address a "chunk" of memory <= 64 kBytes. More often than not this is not sufficient. For example, USBEHCD.SYS needs to address 128 kBytes of internal management data structures to make isochronous transfers work (something that you need to make USBAUDIO.SYS work, for example).


Programming / Re: VAC3.65 / 3.08 inline assembly? How to insert INT 3?
« on: December 26, 2017, 08:28:03 pm »
If you have the source code, can't you just compile xwlan with source debugging info (ICAT knows CODEVIEW and HLL where unfortunately it no longer understands the CODEVIEW variant that Watcom produces) and then set breakpoints from ICAT ?
If you set a breakpoint via ICAT, that's exactly what it will do: replace the first byte of an instruction with the 0xCC (int3) instruction.
At least that's what I have done over and over again with the USB driver source code.
Of course, the source code will have to be on your ICAT machine (along with the binary with debug info). The binary with debug info will (also, of course) have to go to the MUT.

Programming / Re: htonl in REXX
« on: December 26, 2017, 11:49:14 am »
then do this:


Programming / Re: VAC3.65 / 3.08 inline assembly? How to insert INT 3?
« on: December 24, 2017, 10:36:09 pm »
_interrupt(3) will very likely encode an "int 3" instruction as a 2 Byte opcode (0xCD 0x03).
Just verified with a test sample and it decodes correctly to 0xCC. This is with VAC3.65 and icc /Ti. Idebug stops and the popup says 'A program-generated breakpoint was encountered'.

OK in that case Everything is fine. Thanks for the Feedback.

Programming / Re: VAC3.65 / 3.08 inline assembly? How to insert INT 3?
« on: December 23, 2017, 11:57:22 pm »
Here is my smart ass answer to "_interrupt":

_interrupt(3) will very likely encode an "int 3" instruction as a 2 Byte opcode (0xCD 0x03).
The "real" int3 however is a 1 Byte opcode (0xCC). These two instructions are close but not the same and might confuse a normal debugger that expects 0xCC opcode for int3 (if you intend to execute the application under Debugger control and intend to stop it on the int3).

Programming / Re: VAC3.65 / 3.08 inline assembly? How to insert INT 3?
« on: December 21, 2017, 11:15:14 pm »
Need a little bit of assembly. Write yourself an assembly function. And while you are at it, make it a library so that you can reuse it.
Use ALP for assembly. It's still good enough for not too advanced assembly code (goes up to XMM, supports all protected system instruction).

Internet / Re: Experimental build of SeaMonkey
« on: December 21, 2017, 01:27:10 pm »

Interesting, full screen has consistently worked the same here since Netscape 4.61 with the exception of 45.5 where it was broken.
Drag and drop usually works fine here though there has been an issue for the longest time where if you do it too quick, the browser crashes. Perhaps on faster hardware, too quick isn't so quick anymore.

I doubt that this has anything to do with speed. I would think that this depends on the windows that are crossed when you drag stuff. This sounds much like a bug in a window procedure getting a notification that something is dragged across it and then accessing the dnd info in the wrong way, eventually crashing either the drag source or drag target application. It's also possible that the crossed window does everything ok but the drag source reacts in the wrong way when the crossed window establishes some handshaking with the drag source /notifies the drag source.
I would not be surprised if the error still exists. You just have not reproduced the right scenario for it to happen.

Programming / Re: htonl in REXX
« on: December 20, 2017, 01:03:38 pm »
Why don't you just use "reverse" function ? At least that is what I use:

htonl: procedure
parse arg swp .
return reverse(swp)

If you have to work on binary data directly you would likely need to do this:

htonl: procedure
parse arg swp .
return c2d(reverse(swp))

General Discussion / Re: OS/2 application developers
« on: December 18, 2017, 02:13:24 pm »
Today, every application should use the "L" type of functions: DosOpenL, DosSetFileSizeL, DosSetFilePtrL, etc.
DosOpenL has a special parameter "OPEN_SHARE_DENYLEGACY" that will allow application A to open a file > 2 GB (if the filesystem supports that) while preventing application B to open shared that very same file via DosOpen (and therefore restricting itself right from the outset). Of course, the intention is to assure that BOTH applications can access the whole file.
Of course, the "L" variants will ensure that the underlying filesystems' capabilities (to support files > 2 GB) are completely transparent to the application. If the underlying filesystem does not support files > 2GB you will get an error if you attempt to create a file > 2 GB or try to access a fileoffset > 2 GB.

That's about as good as it gets. I was talking about the native OS/2 API. If you need proper RTL support (fstat, fstat64 etc.) then you would need to invest more effort.

In the year 2017, applications should be able to assume they are running on a kernel supporting the large file API and they should never ask for less.

1) Use "L" APIs, in particular DosOpenL
2) use "OPEN_SHARE_DENYLEGACY" on the DosOpenL call

Storage / Re: oddities with OS2AHCI version 2.04
« on: December 16, 2017, 10:40:45 pm »
"memory check": I am using also Windows 10 64-bit on this very same HW. I have no apparent issues with it. At least not unexplicable crashes.

"setting NX" bit: I have no such option in my BIOS. I am not sure if my instability is limited to use of high memory. I had set VIRTUALADDRESSLIMIT to 512 MB and I still have these strange reboots etc.
I have the strong feeling that the amount of system memory matters. Unfortunately it is not all that easy to reduce it. And I bought it to be usable with a 64-bit OS like Windows 10 ...

Maybe there is an issue with AMD based systems ? You all seem to have Intel based systems.

What I also realised:
1) when I dump OS2AHCI$ to the console I have a lot of these entries:
port #0 interrupt error status: 0x40000001; restarting port

2) when I run "smartahci.exe -i hd1" and then dump OS2AHCI$ I get:
timeout for IORB da811ea (etc.)

I am beginning to believe that I cannot use OS2AHCI.ADD on this AMD based system.

Storage / Re: oddities with OS2AHCI version 2.04
« on: December 16, 2017, 08:10:38 pm »
1) I have 16 GB of system memory. How much do you have ?
2) I have an AMD 8-core system ("8350 Eight-Core Processor", I think that is Bulldozer architecture). What do you have ?

I have tried to limit memory via VIRTUALADDRESSLIMIT. That works as described and I can also use memory in excess of the 4 GB boundary as memory for the QSINIT ram disk.

But I have the suspicion that there is a bug in the kernel if more than 4 GB physical memory is installed in that the memory management will go bad. I have many odd effects, from sudden reboots to some Theseus working set script (getws.exe) leading to a kernel trap as soon as I execute it.

I have no special SW installed whatsoever.

Storage / oddities with OS2AHCI version 2.04
« on: December 16, 2017, 03:17:48 pm »
I recently installed version 2.04 which indeed fixes the problem with the system freezing on invoking smartahci.exe which happened with version 2.03.

But now I have this oddity: if I invoke smartahci.exe more than once in a row, the first invocation will work fine but the second invocation will again freeze the system.
I tried this commandline: smartahci.exe -i hd0

Before I open a problem report at AN: Does anyone experience the same problem ? Or is it just me ?

Hardware / Re: Hardware Reports / Reviews - More - MORE !!!!
« on: December 12, 2017, 04:58:27 pm »

Is this a MIDI in hardware device? It is supposed to be class compliant.

Yes, that is a MIDI device. However, I was thinking about a USB device with a built-in synthesizer/wavetable that generates audible output from the input MIDI stream. Much like what normal sound cards did/do.
In short: something you can throw a MIDI file at and then you can listen to some sort of sound output.
I don't know if that exists. Maybe MIDI is dead.

Hardware / Re: Hardware Reports / Reviews - More - MORE !!!!
« on: December 09, 2017, 02:02:01 pm »
May I add that Wim and me we are currently working on a fix for USB 1.0 audio devices to being able to control playback volume/mute setting. But this is only a minor issue.

That said, ANY USB audio standard version 1.0 compatible device that supports sampling rates <= 48000 Hz should work with USBAUDIO.SYS. But you are limited to wave playback: MIDI does not work and properly never will (unless you use a SW emulation like Timidity). I have yet to come across an USB audio device that supports MIDI in HW. Wave Recording will also work but the current driver does not bother to support any controls regarding recording (like automatic gain control on/off etc. etc. etc.).
One of the reasons for this is that OS/2 does not have a user interface that would allow the user to control all that stuff (and the standard is very generic, it supports all kinds of odd controls, from compression to reverb, echo,  mixing, etc.)

Beware that more and more USB  audio devices now follow the standard version 2.0 because Microsoft has started to deliver such a driver for the Windows OSes (a few years ago). Unfortunately these standard versions are not backward/forward compatible which eventually will leave OS/2 behind (unless someone starts writing USB audio version 2.0 driver). As so often.

Pages: 1 2 [3] 4 5 ... 14