166
Internet / Re: Gopher server?
« on: June 01, 2017, 03:33:11 pm »
There's only GoServe. The latest version 2.52 (http://www.tavi.co.uk/os2pages/ews/goserv.zip) supports gopher and http.
OS2World.com Forum is back !!!
Remember to visit OS2World at:
http://www.os2world.com
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.
So there is wireless. Hurrah! Is the card an OS/2 friendly one?It should work with Genmac wrapper. Download it here: ftp://ftp.netlabs.org/pub/genmac/genmac220.wpi
Note that the wireless card does not show up in the GUI app (see screenshots inf first post of this thread).
I'm not sure how to install these given the contents of the zip file. Could you advise please? Thanks!Simply extract two files (B44A.OS2 and B44A.NIF) to your \IBMCOM\MACS directory. Then run MPTS and change the adapter to "Broadcom BCM4401 MAC driver".
Does your driver read the MAC address from the NIC? IIRC one of the netstat commands should show you this.It's quite simple to run netstat -n checking for this behaviour.
In the past there were some cards with Realtek chips which could not read the MAC address from the hardware and you had to add it manually in NAPS - Adapter options or directly in protocol.ini. No clue if this is still true.
I am asking b/c I have the fully blown 4.0 here (with various fixpacks) and as you said, even though the product is aged now it is still extremely impressive. Considering that it was always resource hungry, now with the faster machines and better hardware capability it really zips along quite nice.I don't know what you mean by "various". There's only Fixpak 1 for OS/2:
Part of that install, in my case, was the option to select the standard C/C++, which I did, thus installing the 3.6.5 release (or maybe it was a separate install altogether??? lol, it's been a while...).It's an extra CD-ROM in the package and needs to be installed separately. Also a different fixpak:
What I have always wondered about is the choice between the two? Which one is best suited for what types of apps?V 3.6 is better suited for projects from VAC 3.0 environment or cross platform projects. Of course there is also a migration feature in the V4.0 workframe. Both support the same level of IOC (IBM Open Class).
Let's also point out that Germans aren't always that qualified to reply, because they've got eCS 2.x DE. Good for you.Sorry, but that's a wrong assumption. My observations are made on systems that are generic IBM OS/2 Warp 4 or Warp Server for e-business installations with latest fixes applied (if required). And I'm aware of minor differences between NLS versions.
That's the environment they are often used to, exceptions excluded. OS/2, eCS and ArcaOS are different products.The so-called ported software from RPM packages is only tested under an US OS/2 Warp 4 MCP2 environment. Most of the included localisation that got installed (without the option to disable unwanted locales) is simply not usable or unreadable on specific NLS target systems because of wrong text encodings.
If you're French, for example, then you may be forced to use OS/2 Warp 4 FR. They are lucky, because they have got a FP15. Probably often with matching old hardware. AFAIK there's no package manager update package for OS/2 Warp 4 FR. So a package manager is an assumed default solution of different products for different countries.As I worked in the past for an account in Spain and France my experiences are different. For client stations the french MCP1 or MCP2 can be used. But I cannot remember exactly if it was only Canadian French installation media set to an European locale for France. I can a look at it soon.
Now FF requires (too) many DLLs. Some DLLs have requirements. Installing the DLLs, with support, requires some package manager. Surely this package manager has requirements too. Not if you're using different products like eCS 2.x or ArcaOS. The next requirement is that you'll have to "investigate" the random digital package manager each time, for example because it's not aware of all LIBPATH-settings of all WPS object.There are a lot of inconsistencies in dynamic linking and it's consequences regarding the memory management. The lack of reliable development tools is only one of the reasons that leads often to strange behaviour of the generated application. The average user will only notice slower performance and faulty graphics in most cases. The biggest bottleneck with mozilla apps seems to be now I/O and not CPU performance.
So why is a package manager a bad choice for a product called "FF for OS/2"? Because there is no digital package manager update for OS/2 Warp 4 FR. It's "FF for eCS 2.x" (EN/DE only), or "FF for ArcaOS" (EN only). Of course the main reasons are that the human package manager has to manage more than one system, and that requirements of requirements of requirements are a bit over the avoided top. If anything compared to downloading one package called "FF for Windows".In my opinion it's a misuse of the Firefox brand, but who cares? Usually beta versions should use a different branding.
That's why a human package manager used a digital package manager. To obtain the DLLs. Once, for all installs. So far we're also ignoring the fact that OS/2 and eCS 1.x have no "@UNIXROOT", and so on, and that there are no update packages to keep components of older products like OS/2 Warp or eCS 1.x up-to-date. Actually ANPM may be a rare exception. The human package manager gets it right once, and delivers the known, right solution to all qualifying systems. Just like you don't want Microsoft's update to update your browser, install irrelevant software, and so on.I cannot follow the idea behind the @unixroot thing. It's only required by fontconfig which has hardcoded paths. I can only guess that this "feature" was only tested with JFS volumes.
If you're using eCS 2.x DE in an environment which isn't that complicated, then its digital package manager may be an excellent choice. You'll have the matching Unix-directory structures, and so on.By only reading reports from German eCS 2 users I cannot agree with you. I have only eCS 1.2 (but not installed).
In the EU, 11% of the community speaks German. In the EU, 38% speaks English. If those statistics are true, then far less than 50% of the community (some Germans do speak English too) in the EU will understand eCS 2.x DE/EN and ArcaOS EN. Other people may not prefer a DE/EN OS, despite of understanding both languages.I don't know where are the figures from. But it does'nt have any relevance for OS/2. Approx. 60-70% of existing installations are German NLS of different OS/2 product levels. And even communication with IBM Austin (15 years back) could be done completely in German. I agree with you that NLS should be improved. Forcing users from South Africa for instance to use an English OS/2 is not polite.
Has anyone managed to get the Broadcom BCM4401 driver working with ArcaOS? I just installed on an old Dell Inspiron 1300 and everything appears to work bar the networking.
There are 2 ways to successfully run applications on a modern OS/2 system:YUM relies on IP connectivity and a quite large Python language environment. We would use here RPM, but in the current form it's not an easy process. I could not find any documentation about the installation of RPM without yum. Unfortunately your "simply works" means in real world the lack of any documentation that would help the operators.
1.) Go the RPM/YUM way. Stuff simply works in most cases.
2.) If there is an older version library that is required by an elder application under any circumstances - use LIBPATHSTRICT. PMDLL is your friend.QuoteThis advise is not totally wrong, but it cannot resolve all dependencies or compatibility issues.
There's OpenWatcom, OpenWatcom.org, the only existing cross compiler for OS/2 and of course GCC, yum install gcc.OpenWatcom supports different host OS and some more target OS in one package. For older OS/2 32-bit releases version 1.8 of OpenWatcom C/C++ should be used. Support for other target architectures is almost not existing, only an assembler for Alpha AXP and PowerPC. On the other hand it includes enough libraries to produce simple PM applications.
It's seems you cannot read. This forum area topic is about "Applications". You have no better to do than spreading fake news here. The current situation under OS/2 is a total disaster for end users of your "ported" applications. It's a fatal mixture of breaking compatibility, introducing new unstable interfaces, slovenliness and unkindliness etc.QuoteWell, an (half-ported) package manager from the late 90ies and an update mechanism from early 2000 is the ultimate solution nowadays.
Ultimate solution? Your words. bitwise never said that. However, the solution that made most sense. And it can't have been that wrong...
https://www.ibm.com/developerworks/library/l-lpic1-102-5/
They appear ridiculous only if you missed the most important point. I bet you will not guess which one I meant. Just go through my writing once more and do a careful reading.It only becomes even more abstruse at every further time.
Hint: Conservative minds often miss that point.
I have to address some statements in this discussion:QuoteOS/2's human package manager
Why does OS/2 rely on a human package manager? Because its architecture is from the early 1990ies. No need for automatic package managers back then.
However: It is quite arrogant to assume that all other OS maintainers (no matter whether these are the Linux, Windows, FreeBSD, whoever guys) are rather dim and incompetent to create such beasts for other OSes when in reality they were not needed. 201x software (especially bigger programs) are simply too complex for a manual approach.
Firefox 45 is a 2016 piece of software: The problems to get all DLLs together are not OS/2 specific - all the other OSes got package managers to do that job. NOBODY on other OSes asks for specific DLL requirements to be manually downloaded "somewhere" and copied into specific locations - the question for that (unless for specific research purposes) would be considered plain stupid and obsolete.
The RPM/YUM port is an attempt driven by bitwise works and Arca Noae to close this gaping hole in the OS/2 architecture.
So:
If you want to run software the 1990ies way on a 1990ies OS, please use software from the 1990ies - an automatic package manager would not really be required then.
If you want to run software from the 201x on a 1990ies OS, please do as the ones who DO THE WORK on that stuff suggest. We know what we are doing and why we are doing it the way we do it.
If you do not want to do it the suggested way - you are free to do so. You just need to do A LOT OF RTFM and use PMDLL as a tool to overcome the arising difficulties...
Maybe it is time for you to review your point of view. But please don't steal our time by asking 1990ies questions in 2017. They have been solved - use RPM/YUM - that IS the solution.
Does Win 7 work inside vbox with os/2 host?I have Windows Server 2008 running with the older VirtualBox 1.6 release. The Windows 7 32-bit edition should behave the same way but requires a larger footprint.
Returning to Firefox v38.8.0 is no problem, all the additional DLL's that Firefox v45.5.0 require are backward compatible and actually improve the performance of v38.8.0.Unfortunately that's not the truth. Every user testing the newer functions in a RPM installation, should also backup the DLL files especially nspr & co., which is not fully backwards compatible. Of course the esr38 applications will still start with them so it may look "compatible". But their usage leads to bad performance and breaks the functionality of several add-ons, for instance uBlock Origin.
I'm wondering if anybody knows the legal ramifications of reverse engineering the OS/2 win32 support? There are some APIs that Visual FoxPro 3.0 requires that cause it to not run on OS/2, though it would run on a full version of Windows 3.11 by Microsoft.
I am considering creating a wrapper DLL which would embrace some of those Win32 1.1 specs, initially just those which are used by Visual FoxPro 3.0, but ultimately any that would be required for other apps, so that we could get more modern Win32 apps up and running (at least many that would work on Win95).
If it's legal, I may consider investing some time on this as I program in Visual FoxPro daily, and I would gladly leave Windows forever if I could get this environment up and running.