Windows 10 End of Life

Windows 10 support ended 10/14/2025 and Windows 11 was made to trash millions of computers, as most users don't need the fancy hardware features Windows 11 demands to install.

Luckily for anyone who just wants email, web browsing, word processing, spreadsheets, access apps, instead of ditching your computer, you can continue using it "as is" until its wheels fall off. Just make sure you don't accidentally click on something that causes Win11 to be installed.

Another option is to backup your personal files, ditch Windows, and go with one of the many free Linux versions. Pro versions of Windows can have lots of bits of Linux lurking in it anyway, so you can go the whole way and ditch Windows completely.

It's kind of like everyone used to think you had to have a landline, then mobiles came along and had to have a keypad, then iPhones came along...Could phone numbers and Windows be next on the chopping block?

I've continued using Windows 10 on my primary laptop and have no intention of doing anything different with it until the laptop itself fails

Every once in a while I get popups trying to force me, I get rid of them pronto.

The OS's have become increasingly annoying and more apple-like over time, so I put them off until I have no choice. Probably will be when I next buy a laptop I may have no choice at that point

I use no AV system at all, (other than all the windows built in stuff), AV systems behave more like a virus than a virus does, never regretted it
 
I use no AV system at all, (other than all the windows built in stuff), AV systems behave more like a virus than a virus does, never regretted it
Yeah, they are resource hogs that are always one step behind.
 
Fixed my problem with a registry edit. Despite pausing my latest update until mid-November, it pushed itself through anyway when I restarted so that the update center can proudly tell me the OS is EOL. Hopefully it stays that way.
 
Fixed my problem with a registry edit. Despite pausing my latest update until mid-November, it pushed itself through anyway when I restarted so that the update center can proudly tell me the OS is EOL. Hopefully it stays that way.
Beware if that update didn't undo your registry setting. Check it again. There's a Windows service called "Remote Registry" which essentially allows Microsoft to make changes to your registry settings without notifying you.
 
Last edited:
No, Access BE's don't run natively in Linux. You would have to put them in a Windows hosted KVM. However, SQL Server runs natively in Linux, although I've never tried the Linux version.

There are plenty of db servers that run natively in Linux, e.g. Oracle, MySQL, MariaDB, PostgreSQL, Informix, ... I have linked Access FE's to all of those. On Linux, you typically want to isolate db servers in a KVM. That's the recommended config for hybrid Access/Web applications. Web server also has its own KVM. It's a lot easier to backup/restore KVM's, plus that isolation provides increased security. The Linux server essentially acts as VM hypervisor.

Yes
Actually, an Access BE runs fine when on an ext4 partition with Samba authentication running on Linux. I did it for years. An Access BE doesn't run in place, it's opened by the FE.
 
Actually, an Access BE runs fine when on an ext4 partition with Samba authentication running on Linux. I did it for years. An Access BE doesn't run in place, it's opened by the FE.
FE's can link to BE's on Linux and NAS, however if you try to directly open them it throws a memory fault, core dumped error. I tested it over 10 years ago. BE's and FE's are Windows accdb file types. If accdb's were able to natively run on Linux, then Excel and all other Office components would also, but MS has never ported it to Linux, with the exception of Office without Access on MacOS. An accdb requires DLL's, display, I/O drivers, and a runtime to launch.
 
Last edited:
FE's can link to BE's on Linux and NAS, however if you try to directly open them it throws a memory fault, core dumped error. I tested it over 10 years ago. BE's and FE's are Windows accdb file types. If accdb's were able to natively run on Linux, then Excel and all other Office components would also, but MS has never ported it to Linux, with the exception of Office without Access on MacOS. An accdb requires DLL's, display, I/O drivers, and a runtime to launch.
My development machine for years was a Win10 VM running on VMWare Workstation on Ubuntu Linux. All files were on Samba shares on an ext4 partition on the same machine. I never encountered even a hiccup with an Access back end file. In fact, the machine had no NTFS partitions at all. Even the Windows VM files themselves resided on the same Samba shares on the Linux host system. I can't say what you tested but Access back end files, both MDBs and ACCDBs, can and do reside and operate without complaint on Linux Samba shares. No Linux application that I know of can open an ACCDB but that's obvious and beside the point.

To be clear, back end files don't "run" on the machine where they reside. That machine, regardless of OS or filesystem, is simply a file server. It isn't opening or running the back end file at all, just serving it to its client machine, in this case a Windows machine running Access, which opens the file. It is the msaccess.exe instances on users' machines that open both the front- and back-end files in a split Access database. Each user has a local front end file running on a local Access instance. All users' local Access instances then also open the same back end file, which resides on a remote share (Samba, workgroup, LDAP, AD, whatever). One bit of Access' magic is that it allows many front ends to simultaneously open the same back end file. Local machines' file and record locking settings configure this behavior somewhat. No back-end Access database server exists, however, just a back-end file, opened locally by each front end. In fact, one subtle optimization technique is to bind a startup or other application form to a back end table, to keep the back end file open instead of opening and closing it each time a user opens a form.
 
I can't say what you tested but Access back end files, both MDBs and ACCDBs, can and do reside and operate without complaint on Linux Samba shares. No Linux application that I know of can open an ACCDB but that's obvious and beside the point.
We're running around in circles saying the same thing. However, there are drawbacks to hosting an accdb BE in non-Windows environments. You cannot directly open the BE to do things like Compact/Repair, alter tables, etc. I have built several hybrid Access/Web applications where Access FE's on Windows Workstations link to db servers, such as Oracle, MariaDB, MySQL, hosted in Linux KVM's. These db servers are also linked to customer web portal apps. My customers and I have never had a desire or need for hosting an accdb BE on Linux. Access BE's are inadequate for hybrid web apps. If an accdb BE should be needed for linking to Access FE's, we would host the BE on a Windows box, or a Linux KVM running Windows.
 
You cannot directly open the BE to do things like Compact/Repair, alter tables, etc.
Even if you open Access first with no file referenced and then use the Open option to browse the file share folder to find the file to be opened?
 
Even if you open Access first with no file referenced and then use the Open option to browse the file share folder to find the file to be opened?
You can link a blank accdb on Windows to the accdb BE on Linux, but you can't launch the BE in Linux.
 
We're running around in circles saying the same thing.
False.

However, there are drawbacks to hosting an accdb BE in non-Windows environments. You cannot directly open the BE to do things like Compact/Repair, alter tables, etc.
False. No such drawbacks exist. An ACCDB on a Linux Samba share of a directory on an ext4 file system can readily be opened directly to do each and every one of these things. I've done all of them countless times, without a hint of difficulty.

I have built several hybrid Access/Web applications where Access FE's on Windows Workstations link to db servers, such as Oracle, MariaDB, MySQL, hosted in Linux KVM's. These db servers are also linked to customer web portal apps.
Spinning off into tangential discussions of other ODBC BEs is utterly irrelevant.

If an accdb BE should be needed for linking to Access FE's, we would host the BE on a Windows box, or a Linux KVM running Windows.
The Windows box would be pointless, or at least utterly unnecessary.

A Linux box with a KVM (keyboard-video-mouse adapter) also would be pointless, and God knows how that adapter would run Windows, much less why one would want it to.

You simply don't apprehend SMB file services, or even Access files. Go implement a Linux file server hosting the Samba daemon to define shares of directories on which are mounted the ext4 filesystems of various RAID partitions, with share permissions for diverse users. Actually write, from scratch, the fstab and smb.conf files. Connect to the shares so defined with a Windows machine and open files on each share from diverse user accounts.

To be clear, no need exists to host any ACCDB back end on (a) any Windows machine; (b) an NTFS file system; (c) any share administered via Active Directory; or (d) any machine with any KVM (i.e., keyboard-video-mouse adapter).
 
Last edited:
A Linux box with a KVM (keyboard-video-mouse adapter) also would be pointless, and God knows how that adapter would run Windows
KVM stands for Kernel Virtual Machine. All Linux distros come with KVM's. It looks like AI gave you the wrong answers because your comments above illustrate your inexperienced with Linux, and accdb's on non-Windows environments. Everyone who knows Linux knows what a KVM is.
 
Last edited:
You can link a blank accdb on Windows to the accdb BE on Linux, but you can't launch the BE in Linux.

I was referring to a Linux-based file server, not a Linux app server. I didn't EXPECT to launch the BE while logged in to the Linux box. To be painfully clear, I was saying that a Windows system can launch a non-file session of Access, which gets you to the page where you can select a file to open ... and THAT file can be any Access file you want, whether FE or BE, because the work space is on the Windows machine. If you open a remote FE, you get the disadvantage of a pot-load of traffic between the PC and the (remote) FE file. I don't recommend that approach even though it is technically possible. But if you open a BE file the way I described, you can do your maintenance on that remote BE file. I've done it many times when working with databases related to the U.S. Navy's BUPERS (Personnel) systems.
 
My development machine for years was a Win10 VM running on VMWare Workstation on Ubuntu Linux. All files were on Samba shares on an ext4 partition on the same machine. I never encountered even a hiccup with an Access back end file. In fact, the machine had no NTFS partitions at all. Even the Windows VM files themselves resided on the same Samba shares on the Linux host system. I can't say what you tested but Access back end files, both MDBs and ACCDBs, can and do reside and operate without complaint on Linux Samba shares. No Linux application that I know of can open an ACCDB but that's obvious and beside the point.

To be clear, back end files don't "run" on the machine where they reside. That machine, regardless of OS or filesystem, is simply a file server. It isn't opening or running the back end file at all, just serving it to its client machine, in this case a Windows machine running Access, which opens the file. It is the msaccess.exe instances on users' machines that open both the front- and back-end files in a split Access database. Each user has a local front end file running on a local Access instance. All users' local Access instances then also open the same back end file, which resides on a remote share (Samba, workgroup, LDAP, AD, whatever). One bit of Access' magic is that it allows many front ends to simultaneously open the same back end file. Local machines' file and record locking settings configure this behavior somewhat. No back-end Access database server exists, however, just a back-end file, opened locally by each front end. In fact, one subtle optimization technique is to bind a startup or other application form to a back end table, to keep the back end file open instead of opening and closing it each time a user opens a form.

"No Linux application that I know of can open an ACCDB"
A few that can with limitation especially after Office 2016 - LibreOffice, DBeaver + UCan Access, MDB Tools or Conversion Based RebaseData API
 
You might, then, have a clue. Currently, you do not.

That might be over-the-top, riktek. I support your technical position about the nature and utility of file servers but must ask you to please watch the tone of your responses more carefully. That response violates the guidelines about direct insults. There is a difference between claiming someone is clueless and claiming that they have an erroneous belief. Please consider editing your post to remove any directed insults.
 
That might be over-the-top, riktek. I support your technical position about the nature and utility of file servers but must ask you to please watch the tone of your responses more carefully. That response violates the guidelines about direct insults. There is a difference between claiming someone is clueless and claiming that they have an erroneous belief. Please consider editing your post to remove any directed insults
You're right. Apologies.
 
I was referring to a Linux-based file server, not a Linux app server. I didn't EXPECT to launch the BE while logged in to the Linux box. To be painfully clear, I was saying that a Windows system can launch a non-file session of Access, which gets you to the page where you can select a file to open ... and THAT file can be any Access file you want, whether FE or BE, because the work space is on the Windows machine. If you open a remote FE, you get the disadvantage of a pot-load of traffic between the PC and the (remote) FE file. I don't recommend that approach even though it is technically possible. But if you open a BE file the way I described, you can do your maintenance on that remote BE file. I've done it many times when working with databases related to the U.S. Navy's BUPERS (Personnel) systems.
Understood, and what you say is true, but @riktek insists he has/can launch an accdb that lives in native Linux while logged into it. If that were possible, then Linux versions of Access and all other Office tools would be available for purchase from Microsoft.
 
KVM stands for Kernel Virtual Machine. All Linux distros come with KVM's. It looks like AI gave you the wrong answers because your comments above illustrate your inexperienced with Linux, and accdb's on non-Windows environments. Everyone who knows Linux knows what a KVM is.
We also don't conflate a kernel-based virtual machine with those running on other hypervisors. It isn't a generic term. Used generically, it is ambiguous.
 
We also don't conflate a kernel-based virtual machine with those running on other hypervisors. It isn't a generic term. Used generically, it is ambiguous.
Nice try, but you already demonstrated your ignorance by asking AI and publishing its erred results in your posts. If I were you, I would crawl back under the rock you came out of 🙂
 
Understood, and what you say is true, but @riktek insists he has/can launch an accdb that lives in native Linux while logged into it. If that were possible, then Linux versions of Access and all other Office tools would be available for purchase from Microsoft.
I don't know what it means for a file to "live in native Linux." I do know what it means for a file to exist in a file system, for a file server to provide it to a client, to be opened, and to be executed.

An ACCDB can exist without difficulty on a Samba share of a Linux or other filesystem. Neither Samba nor its Linux host system opens or executes the ACCDB. Therefore, the Linux host system does not require Access. A Windows machine as a SMB client can open or execute any file on any SMB server, regardless of whether that SMB server is Windows- or Linux-based. If running Access, that Windows machine can open, modify, read, write, save, and close any ACCDB on any SMB server, including adding or deleting tables, fields, or relationships, or decompiling or compressing that ACCDB file. Neither the operating system, nor the file system, of the SMB server has any bearing on this.
 

Users who are viewing this thread

Back
Top Bottom