Recent Posts

Pages: 1 ... 8 9 [10]
91
Virtualization / Re: Win-OS/2 - Open vbesvga.drv video driver
« Last post by Martin Iturbide on November 18, 2025, 03:56:39 am »
Hello

I shared the links to vbesvga.drv at the ArcaNoae Testing mailing list. I'm hoping it can be evaluated and can be of use to other users.

Regards
92
Applications / Re: OS2VOICE RPM - ...and MMOS2 Updater
« Last post by Dave Yeo on November 17, 2025, 03:28:41 am »
Hi Dariusz,
Likely there was a bug fix or feature change. Steven built the one I'm using after I ran into a problem using a rsync server on the internet, namely that server had xattrs turned off and the client expected them to be turned on.
It is weird that Voice is hosting an RPM without the OS/2 fixes from Steven/Paul. I'd assume their source is available.
93
Applications / Re: OS2VOICE RPM - ...and MMOS2 Updater
« Last post by Dariusz Piatkowski on November 17, 2025, 03:01:35 am »
Hey Dave!

I'm using,
Code: [Select]
Z:\>rsync.exe --version
rsync  version 3.0.9  protocol version 31 (os2-perms)
Copyright (C) 1996-2011 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Built by Steven H. Levine Dec 21 2012 10:43:12
Built with GCC 4.4.7
Capabilities:
    64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints,
    socketpairs, hardlinks, symlinks, no IPv6, batchfiles, inplace,
    append, no ACLs, xattrs, iconv, symtimes
...

Note the built by Steven H. Levine part along with (os2-perms).
I'd assume the newer one is similar as Steven has been maintaining it.

Thanks for pulling that up b/c sure enough, doing that on my box did in fact produce a matching 3.0.9 version (previous info was a copy/paste from the readme.os2 file), albeit with a slightly different release date:

Code: [Select]
rsync  version 3.0.9.1  protocol version 31 (os2-perms)
Copyright (C) 1996-2011 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Built by Steven H. Levine Oct 27 2017 23:45:11
Built with GCC 4.9.2
Capabilities:
    64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints,
    socketpairs, hardlinks, symlinks, no IPv6, batchfiles, inplace,
    append, no ACLs, xattrs, iconv, symtimes

although I think the main difference here is the GCC version that was used.
94
Applications / Re: OS2VOICE RPM - ...and MMOS2 Updater
« Last post by Dariusz Piatkowski on November 17, 2025, 02:55:55 am »
Hi Marin!

...The latest version that I had found about RSync for OS/2 is 3.0.9.1 (2017-11-11)
-- http://www.warpcave.com/betas/rsync-3.0.9.1-20171111-shl.zip
or
-- https://hobbesarchive.com/Home/Download?path=/Hobbes/pub/os2/util/backup/Rsync_3-0-9-1.zip

I don't recall any release "3.1.3" port, but if you have the links let me know...

Well, the 3.1.3 is what you are hosting on that EXPERIMENTAL repo, right here => http://rpm.os2voice.org/rpm/experimental/00/i386/rsync-3.1.3-2.i386.rpm

Indeed, downloading it and extracting from the RPM produces the following:

Code: [Select]
rsync  version 3.1.3  protocol version 31
Copyright (C) 1996-2018 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
    64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints,
    socketpairs, hardlinks, symlinks, no IPv6, batchfiles, inplace,
    append, no ACLs, no xattrs, iconv, symtimes, no prealloc

...thus the question I had posted earlier as there is nothing in that package that spells out the WHO/WHERE/HOW (so to speak) and it does appear to be missing that "os2-perms" support, at least judging by the above output.
95
Events / Re: Warpstock 2025 USA - The end of my journey with ArcaOS
« Last post by Roderick Klein on November 16, 2025, 10:46:28 pm »
Quote
who have the knowledge, time and interest
  • who have the knowledge
  • time and
  • interest

Tell me when you have a candidate for only one of the above 3 questions.

Seriously, I've been the maintainer of xwlan and our port of wpa_supplicant for about a decade. Although I've fixed and extended a lot and invested countless hours, even these two project are far from what we would need today. And that's only an interface to a driver. I know porting or writing a wifi driver would be a lot of more (huge more) work. From my experience the majority of 'non programmers' don't even get feedback. Not to talk about helping out with testing or writing readme's..... So dream on.

Look I am not an expert but heck you ask Copilot.com at least as *some* form of start. This list comes pretty close to what is needed to write an OS/2 wifi driver. Maybe not all is needed. But let this list sink in:
1. Device Identification & Initialization
   PCI/USB/SDIO bus interface code to detect the chipset.
   Proper vendor and device IDs so the OS can bind the driver.
   Initialization routines to set up registers and memory mapping

2. Firmware Loader
   Many WiFi chipsets require proprietary firmware blobs.
   The driver must include routines to load firmware into the chipset at startup

3. MAC Layer (Medium Access Control)
   Implements 802.11 protocol logic (association, authentication, encryption).
   Handles packet framing, retransmissions, and QoS.

4. PHY Layer (Physical Layer) Control
   Manages radio tuning, modulation, and channel selection.
   Provides APIs for setting frequency bands and transmit power.

5. Network Stack Integration
   Hooks into the OS networking subsystem (e.g., Linux cfg80211 and mac80211 frameworks).
   Provides standard interfaces for scanning, connecting, and data transfe

6. Configuration & Management Utilities
   User-space tools or APIs (like iwconfig, NetworkManager, or custom utilities).
   Support for WPA/WPA2/WPA3 security via integration with supplicant software

7. Interrupt & DMA Handling
   Efficient handling of hardware interrupts for packet transmission/reception.
   DMA (Direct Memory Access) setup for high-speed data transfer.

Skipping power management

9. Error Handling & Logging
   Debugging hooks, kernel logs, and recovery routines for failed transmissions or firmware crashes.
96
Events / Re: Warpstock 2025 USA - The end of my journey with ArcaOS
« Last post by Roderick Klein on November 16, 2025, 10:09:25 pm »
Hello
wished i was a programmer to contribute to the development of a WIFI-driver.
What about the idea to start a project to develop one together - online with the help of all who have the knowledge, time and interest - step by step. Would that be feasible?

Even that the Andi B's comments are right, I was wondering if a more dirty/non-elengant/hack aproach can be worked out to have wifi drivers with less effort. Like just focusing on some basic wifi first and maybe not fully functional first. Maybe going back the 32bits windriver wrapper idea, or focusing on some USB wifi dongles.

Regards

Read my lengthy reply to Sigurd if it was all that simple, really I wish it was. Sadly its not.  I have been looking at all of this.

What we need understand as community is what I described below:

You effectively have two approaches.

1. Port a driver, copy paste chunks and get a driver.

2. Come up with library or wrapper that does this.  This what David tried twice with Linux and FreeBSD.  But it backfired because simply a case of badluck. The bad luck that Linux changest the kernel somehow and then it happened again with FreeBSD.

The win32 wrapper is complete dead end. Simply because no more 32 bit drivers are being made for Windows. You know when Willebald Meyer created Genmac it was a lot of work I am not discounting that at all. But to some degree he also got lucky and here is why. The NDIS network stack on OS/2 and Windows where pretty close (no surprise of course).
One of the changes is that NDIS stack on Windows started to change that much (and the driver as well). To an extend keeping Genmac up with the changes on Windows became to much for one person to keep up with.

I wonder if people even fully grasp the parallels between Multimac and Genmac. To put it differently Willibald Meyer looked a generic solution to not write the drivers.
But wrote drivers to support the Windows drivers. My conclusion Genmac stopped working simply because the technical changes between Windows and OS/2 become to big.
ReactOS I think also only supports 32 bit wifi drivers, not 64 bit.

ReactOS seems be in the same boot as we are.

https://reactos.org/wiki/Supported_Hardware/Wireless_Network_cards

Roderick

97
Applications / Re: OS2VOICE RPM - ...and MMOS2 Updater
« Last post by Martin Iturbide on November 16, 2025, 05:34:38 pm »
Hello Dariusz

The latest version that I had found about RSync for OS/2 is 3.0.9.1 (2017-11-11)
-- http://www.warpcave.com/betas/rsync-3.0.9.1-20171111-shl.zip
or
-- https://hobbesarchive.com/Home/Download?path=/Hobbes/pub/os2/util/backup/Rsync_3-0-9-1.zip

I don't recall any release "3.1.3" port, but if you have the links let me know.

Regards

98
Events / Re: Warpstock 2025 USA - The end of my journey with ArcaOS
« Last post by Roderick Klein on November 16, 2025, 05:31:08 pm »
First of all I listened to many hours of the Warpstock stream and I do not think that Lewis said it such a way as one line answer. Like ooh who needs Wifi, in my opinion Sigurd did not picked up the message 100% correctly.  David mentioned if he could hand over to another developer he would welcome that.  He did not state (from what I heard) he would stop development.

And while I perfectly understand everybody is entitled to his opinion and call stuff excuses.  They way I understand the idea is Arca Noae works on drivers to keep ArcaOS to boot on new hardware. And that is logic order in my opinion. So as David and Lewis mentioned. IBMKBD.SYS was updated to support systems without a 8042 controller, we take NVME support for granted. USB 3.0 took waaaay longer then every expected. And now David is working an update to ACPI as discussed by Dmitry.  And why do we not have Wifi drivers.

We you can port drivers to another OS in two ways.

1. You rewrite the code to match OS/2. from Linux/FreeBSD that is very, very time consuming.

2. The second option is that you write a driver library so you work more efficiently.

Option two we started with when David still worked on eCS at Mensys and worked on the Multimac driver system. With library he could with almost changing no code and push out Linux kernel NIC support on OS/2 within a few hours per driver.  Work was resumed to push this towards Linux and when it was not far from being finished. Well the Linux guys changest the kernel in such a way that broke the Multimac library to a high degree.  And that was the end of the dream of portable wifi drivers, blown. I once heard from David at one of the Warpstocks
then one binary for the Wifi Intel driver (that not working yet, it was not finished). One binary was 400 KB in size. I think that is just the size Uniaud32.sys.
Wifi drivers are so waaaay, waaaay much more complicated then ethernet drivers.

So after the Linux option went away David started from scratch on Freebsd. Some concept but it takes time to build such library. Every call the driver source make need to mapped somehow to work on OS/2.  So ethernet drivers started to appear. And when stuff got closer for Wifi with a FreeBSD library well the FreeBSD modified the kernel sources.

Now David his work to port the 2.5 gigabit drivers is slowed down also as he encounters option 1 I mentioned. Porting code. All of that is way more labor intensive.
So for people to sit there that nothing was done on wifi drivers etc.

Cutting long story short. Serious efforts where made for wifi drivers and mostly failed because of bad luck. If Linux or FreeBSD did not modify its kernel sources we would have had the wifi drivers. Indeed wifi drivers are one of the most complex driver types around just about. Panorama, AHCI, NVME, ACPI and USB is so much easier, but why is that ? Well the interfaces are to high degree standard.

Now porting the new Intel and Realtek ethernet drivers might also take longer because of the same changes to FreeBSD kernel.
Its not recompiling the code....

Just my humble opinion.

Roderick
99
Applications / Re: OS2VOICE RPM - ...and MMOS2 Updater
« Last post by Dave Yeo on November 16, 2025, 05:22:56 pm »
I'm using,
Code: [Select]
Z:\>rsync.exe --version
rsync  version 3.0.9  protocol version 31 (os2-perms)
Copyright (C) 1996-2011 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Built by Steven H. Levine Dec 21 2012 10:43:12
Built with GCC 4.4.7
Capabilities:
    64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints,
    socketpairs, hardlinks, symlinks, no IPv6, batchfiles, inplace,
    append, no ACLs, xattrs, iconv, symtimes

rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
are welcome to redistribute it under certain conditions.  See the GNU
General Public Licence for details.

Note the built by Steven H. Levine part along with (os2-perms).
I'd assume the newer one is similar as Steven has been maintaining it.
100
Applications / Re: OS2VOICE RPM - ...and MMOS2 Updater
« Last post by Dariusz Piatkowski on November 16, 2025, 03:11:39 pm »
Hello Martin!

...Visit: https://rpm.os2voice.org/
Include the RPM and WarpIn repository into AN Package Manager...

This is a great undertaking, so thank you for the engagement.

I have a app specific question: RSYNC.

The version I am currently using is the Paul Smedley 3.0.7 release, which specifically calls out the following OS/2 specific changes:

Quote
Rsync v3.0.7 compiled with GCC 4.3.4 & kLibc v0.6.3

Requires libc063.dll available from ftp://ftp.netlabs.org/pub/gcc/libc-0.6.3-csd3.zip

We (Paul and Steven) are using this as both client and server for backups

Changes in this version:
- Updated to v3.0.6
- Incorporated a bunch of patches from Steven Levine
- Move to GCC 4.3.4 as a compiler
- --xattrs now works for remote servers

eCS/OS2 specific changes:

- Supports OS/2 extended attributes
  Enable with --xattrs
  The default is --no-xattrs
- Supports drive letters
- Supports OS/2 style backslashes in path names
- Supports preserving native OS/2 permissions
  Enable with --os2-perms
  The default is --no-os2-perms
- Supports 2 second native file time resolution
  Defaults --modify-window to 1 second
  Disable with --modify-window=0
- Falls back to shared open if standard open fails
  Allows open files to be backed up if owner allows reading
- Defaulted to %ETC% for rsyncd.conf

However, in your release (which is v3.1.3) there are no OS/2 specifics being called out.

Therefore, I am trying to understand how these packages compare to the otherwise alternative distributions in terms of functionality (this of course is a version-to-version kind of a comparison since obviously 3.0.7 will be different from 3.1.3), etc.???

Thank you!
Pages: 1 ... 8 9 [10]