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 ... 71 72 [73] 74 75
Programming / Re: New OS/4 kernel :: SVN4227
« on: January 04, 2016, 05:56:57 pm »
It remains a secret of the OS4Krnl developer team why they removed the trace and strace facilities.
Without that none of the USB drivers can be traced as they are making good use of OS/2 built in tracing mechanism. Tracing is about the only chance for a developer to do offline analysis of problems surfacing at the user's site (unless you want to recode your own tracing facility).

Applications / Re: WPS Class List Color?
« on: December 12, 2015, 10:35:35 am »
I am not talking about WPMouse and you know it. That would not take more than say 1/2 year full time.
I am talking about replacing WPObject,WPAbstract,WPTransient,WPFileSystem,WPFolder,WPDataFile.
Replacing these and ensuring that all WPS classes that are derived from them (that is, all user additions like for example XWorkplace) still work correctly would likely take in excess of 20 man years full time. Just think about all the regression testing that would be necessary.


Applications / Re: WPS Class List Color?
« on: December 11, 2015, 04:56:56 pm »
You can experiment all the way you want.
But the whole idea of making the WPS object oriented is to inherit functionality. One class inherits from another for a good reason. The reason is to not rewrite functionality that can be offered in a generic way.
There is no way to make XWPMouse a subclass of WPAbstract unless you rewrite the COMPLETE functinality of WPMouse. Your suggestion just makes no sense unless you can provide man years of developer hours and know all of the WPS internals.
I can tell you the outcome of making xWPMouse a subclass of WPAbstract. You effectively have no mouse configuration functionality whatsoever. WPAbstract is a base class that you cannot even create instances of. It just provides bare minimum functionality: you can save persistent data in the OS2.INI file, you get a settings notebook with the standard pages, you could set/query object title etc.


Applications / Re: WPS Class List Color?
« on: December 09, 2015, 04:42:39 pm »
WPS class replacements are not full replacements in the sense of the word. They rather inherit from a parent class and declare to the WPS they "they are the first one" to be called.
In fact, they usually build on top of the functionality of the class that they replace, that is, they call into the old class and modify the result for example.
Therefore you cannot remove classes that replacement classes inherit from.

It's getting even more complicated if for example a class intends to replace WPFolder but WPFolder is already replaced by another class like XFolder. Then the new class that intends to replace WPFolder actually replaces XFolder and so on and so forth ...

You better not touch the base WPS classes WPObject, WPAbstract, WPTransient, WPFileSystem, WPFolder, WPDataFile or you are going to drop into a deep and dark hole.

Example: the XWPS classes replace and enhance some undocumented functionality of WPFolder. If you don't get your open source WPFolder replacement right then you are in deep shit trouble.


Article Discussions / Re: [Arca Noae] Checked your disk lately?
« on: December 08, 2015, 11:29:37 pm »
Just a guess: there is always the chance that shutdown will be prevented by USB host Controllers that are still active and therefore accessing memory. The fact that some HW device is still reading from / writing to memory (USB host Controllers are busmaster capable) is enough to make shutdown fail. This is true in general for any other busmaster capable device (in short: a busmaster capable NIC still being active might exhibit the same problem).
It's always worth a try an specify /FS on every USB host Controller Driver line in config.sys. This switch will halt the host Controller and therefore will prevent it from touching memory.

In a perfect world, all OS/2 drivers serving busmaster capable devices should disable busmaster capability on shutdown. But not every driver does so ...


Article Discussions / Re: [Arca Noae] Checked your disk lately?
« on: December 07, 2015, 06:16:25 am »
Interesting. I did not know that the USB repository is now split. I only know the one at Netlabs.


General Discussion / Re: and eComStation
« on: July 21, 2015, 08:12:28 pm »
Hi Joachim,

So it appears that the USB keyboard problem is what I mentioned earlier, a lack of communication between USBKBD.SYS and KEYBOARD.DCP because the Chinese keyboard need a special translate table for which there is no provision.  Sounds as if your team are in for a serious re-write of all that area, just make sure all the changes are tested against non Chinese installs before you release them.

From what I can tell from the USBKBD.SYS code it doesn't do any translation at all. It only creates scan codes.
I guess the translation to characters always happens somewhere else, also for any other keyboard.

What's the point in building drivers from the DDK sources and releasing them as freeware ?

1) the drivers already exist and are part of the OS/2 product. Just rebuilding them and declaring them as freeware adds nothing.
2) the DDK sources might be outdated with regards to the binary drivers that come with OS/2. This is even very likely (I am sure this is the case for OS2CDROM.DMD for example).
In other words: you might run into a whole bunch of bugs and problems using these built drivers that where already solved.

The only reason why print01.sys exists on hobbes is because a functional limitiation was removed that existed in print01.sys and people where "desperate" for a fix.
You still run the risk of the DDK code not being up-to-date.

I have already gone through this nightmare for all the USB drivers. You are just opening a can of worms.

Programming / Re: Presentation Manager - About PM DLL's
« on: March 08, 2015, 09:56:03 pm »
Plain Forwarder DLLs contain no code but just references to other DLLs which actually implement the function. The loader that loads the executable that in turn loads the forwarder DLL will replace the entry points in the executable not by the entry point of the forwarder DLL but rather by the entry point of the DLL the forwarder DLL refers to (after all that is the purpose of a forwarder DLL).

Why ?  Well maybe because the designers of PM decided to stuff everything into a single DLL "PMMERGE.DLL". But at that point in time there where multiple applications around that referred to file "PMWIN.DLL" (and others like "PMDRAG.DLL" for example) instead. In order to ensure that those applications would continue to work, "PMWIN.DLL" was made a forwarder DLL.
By the way: libc also follows this concept, libc*.dll are all forwarder DLLs except for the latest version that you have installed. You can tell by the file size: the latest version of libc*.dll is about 1.3 MBytes in size while the others are only 150 kByte or less in size. At least they started doing this with version libc06.dll.

Applications / Re: AOOo 4111GA does not install libc066
« on: February 28, 2015, 12:45:49 pm »
Oh, thanks a lot. I don't have a clue about this yum/rpm stuff. I did as you suggested. At least that worked and downloaded and installed a bunch of things I don't know about.

I had already found the (or rather, the equivalent zip file) and installed that which cured the problem with AOOo 4111GA.

To be honest: I don't like the yum/rpm stuff as I cannot see what it is doing and how to fix problems with it. But I don't want to start a flame war ...

Applications / AOOo 4111GA does not install libc066
« on: February 22, 2015, 08:49:39 pm »
I tried the WPI method (rpm WPI on same directory as the base WPI): it does not work
I then tried to run yum with the command line given in the readme: I get told that Python cannot find urlgrabber and then that's it

libc066.dll is not installed and therefore none of the applications works.

Can someone tell me where to get libc066.dll ?

Hardware / Re: Motherboard woes
« on: January 04, 2015, 01:34:33 pm »

Currently the USB stack is getting its last bugs taken out and the OS2AHCI driver being worked on.

It is my opinion that the USB stack will never work properly, until it is completely rewritten. The guys who work on it have done wonderful things, but they seem to be constrained by the original design. USB 3.0 may help to get over that, but it should have been finished about 2 years ago.

I wouldn't say that the stack design is the problem. The problem is that the USB Driver code from the DDK that we have is outdated and is also full of bugs where you never know if these bugs are also in the latest drivers from IBM or not.
I think I fixed around 8 to 10 bugs in USBUHCD.SYS+USBOHCD.SYS+USBEHCD.SYS+USBD.SYS (including bugs that RĂ¼diger Ihle had already found). And I reworked USBEHCD.SYS to make isochronous transfer work (which Wim actually implemented, many thanks to him !) which apparently was never properly implemented and therefore not tested at all.
I am currently doing a major rework on USBMSD.ADD to allow to use USB sticks formatted under Windows and fix problems with existing devices. Again, that driver contained a couple of bugs. And it's the worst/messiest piece of SW I have seen in a tong time.
Nonetheless, rewriting the whole stack will never happen. It's much too much work. Forget it.

Programming / Re: New OS/4 kernel :: SVN4222
« on: August 21, 2014, 11:25:21 pm »
I can easily think of a scenario where use of MTRRs become a problem compared to PAT.
MTRR mem. type regions have to be of size "power of 2" and there are restrictions regarding overlapping regions. PAT is fine granular down to the 4 kByte memory page and it can"override" the underlying MTRR memory type to a certain extent.

Programming / Re: New OS/4 kernel :: SVN4222
« on: August 21, 2014, 11:25:29 am »
The latest  versions of Panorama also support PAT where MTRRs cannot be set up properly.
I'd appreciate a less biased information flow.
To be more precise: PAT support is in GRADD.SYS which is used by Panorama.

Hi Lars

I just pushed the files to github:

My only observation is that the git client didn't recognize any change on "hwman.xh" when I replace it over the original final.  Was it any change on it?

Thanks for sharing.

It's well possible that hwman.xh did not change. In any case, it would be regenerated from file hwman.idl by the SOM compiler.

Pages: 1 ... 71 72 [73] 74 75