0 users browsing Discussion. | 2 guests | 4 bots
| wyatt8740 |
Posted on 25-02-24, 22:27
|
 Post: #5 of 5 Since: 05-18-23 Last post: 51 days Last view: 51 days |
Posted by tommanI have fixed debian packages if you're interested. I hit this myself and rebuilt the offending library with an older GCC version to fix it. Blog: https://megatokyo.moe/blog/ - compatible with Lynx, IE <whatever>, Netscape <whatever>, Mosaic <whatever>, and more, to my knowledge... if you can get around the SSL somehow. This will change soon™ :( |
| tomman |
Posted on 25-02-25, 15:13 (revision 1)
|
|
Dinosaur
 Post: #1334 of 1342 Since: 10-30-18 Last post: 19 hours Last view: 10 hours |
Problem is not GCC, but the fact the packaging rules do not consider the changes done for the new "WOW64 dynamic mode", which now puts all the Wine libs under the same /lib/ dir (/lib64/ is gone) but now separated by architecture (i386/, amd64/), plus now a conflicting /bin/wine executable which should be host platform specific (there is no "wine64" anymore!). The whole WOW64 mode changes caught more than one by surprise, and while these are the development/staging branches, I feel the stuff needed better documentation and a big fat warning to packagers to not just blindly use the old scripts/rules, but actually TEST things. Anyway, care to share your package build rules? (the /debian dir) So far there has been some reasonable feedback on the Bugzilla entry, but the latest package updates are still broken (now due to the conflicting /bin/wine executable). Hell, I even got a question directly answered by a Wine Supremo :D --- UPDATE: The emergency is over, it's safe to upgrade Wine again. Here is what it happened: - Wine reordered a bunch of architecture-specific libs under their own arch-specific paths under $WINE_ROOT/lib/$ARCH/ - lib64 is gone. This to further simplify the new WOW64 mode that has been the default for new prefixes created as of Wine 8.ish. - This also required changes to the binaries to specify where the libs live now, and as a side effect there is no "wine64" anymore: the actual $WINE_ROOT/bin/wine is now architecture specific, provided by wine-$BRANCH. - Somehow some distro packagers (including WineHQ's voluntary Debian/Ubuntu maintainer) missed this bit, leading to incomplete packages and libraries at the wrong place - if you inovked Wine on 64-bit box, it would try to load 64-bit libraries first... only finding 32-bit libs instead, which were the wrong ones, leading Wine processes (wineboot et al) to an early death, and similarly, the creation of new prefixes was also broken because half the DLLs were not where the loader expected them! (the Arch folks also got their wires swapped but backwards: their 64-bit libs were at the right place, but not the 32-bit ones!) - After some tries (which had the side effect of refreshing my Debian package build skills - spoilers: pbuilder is a blessing and a curse), the pieces finally fell at the right places. The packaging scripts are ripe for some good cleanup, but everything is now zen again~ If you're having troubles updating, unhold any package you may have held, uninstall all winehq packages, and reinstall Wine as usual. --- In other more positive news, in a rare window of opportunity, Mesa 24 got released for Bookworm via Backports. And there was much rejoicing~ Don't forget to pick kernel 6.12 too. Mesa 25 also landed at Sid, which means Trixie has a good chance to ship that for release day, but beating the freeze timer will be tight. (Remember: you want both for the just launched RX9000/RDNA 4 cards - forget that noVideo ever existed since all these days they care are about AI silicon) Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| creaothceann |
Posted on 25-03-02, 12:08 (revision 1)
|
 Post: #460 of 460 Since: 10-29-18 Last post: 45 days Last view: 6 hours |
Posted by tomman The situation seems to be quite different now. VMware Workstation is now free to use for private and commercial use. They've been bought by Broadcom, which might be behind that move, and it seems that all support has been cut off - not that you'd need it when there's e.g. the VMware subreddit. The website is one of the most horrible ones I've ever seen (at some point I even tried registering, with the result of finding out that you basically can't do anything with a GMail email address - they expect commercial customers), but thankfully you can download it here very easily. Btw. I read somewhere on reddit (can't find it right now) that the newest versions might have some problem with DirectX, and to use 17.5.2-23775571 instead. The interface is roughly the same as VirtualBox, and they also have their equivalent of VirtualBox Guest Additions. You can even use physical disks instead of creating virtual ones. Just be extra thorough when configuring a machine, some things are a bit hidden, e.g. the "Virtual Machine Settings" window has two tabs, "Hardware" and "Options". You might also need to edit the network settings in "menu | Edit | Virtual Network Editor". VMware uses .vmdk disk images, which can also be used by VirtualBox, but VMware can't use VirtualBox's native disk format. I solved that by simply creating another .vmdk disk in VBox with the same size, and using dd in a Ubuntu Live-CD session to copy the data from one drive to the other. The difference in performance between VirtualBox and VMware was quite a surprise for me:  (via running PassMark's PerformanceTest) It's basically almost as fast as native. My current setup: Super Famicom ("2/1/3" SNS-CPU-1CHIP-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10 |
| tomman |
Posted on 25-03-03, 12:12
|
|
Dinosaur
Post: #1335 of 1342 Since: 10-30-18 Last post: 19 hours Last view: 10 hours |
VMWare is another walking corpse, Broadcom broke it to shreds ("You must be This Rich Enough to be able to buy our products, but don't expect world class support anymore") and I would not touch it ever again. Plus, it's still proprietary anyway. Thankfully my x86 virtualization needs at home do not involve running recent Windows versions to run games, so I'm fine with QEMU/libvirt - it really needs to work more on the user-friendliness aspect (especially for virtual networking, that part is a mess!), but both Embargoed Orrible VBox and Broadcum'd VMWare do not exist to me. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 25-04-08, 02:21 (revision 2)
|
|
Dinosaur
Post: #1341 of 1342 Since: 10-30-18 Last post: 19 hours Last view: 10 hours |
I was reviewing my Super Mario 64 for Windows 9x crosscompile notes as someone in IRC had asked me for help (remember: we can't share binaries because Nintendo), when I noticed several things: - Using prebuilt dependencies is nice, but then you're subject to whatever compiler flags the repo/distro used to build them. - These msys2 dependencies were clearly built for Pentium 4 or newer CPUs, and it was pure chance that they worked as-is on older CPUs - on my Coppermines, they would crash with a invalid instruction if a gamepad were to be plugged in before running the game. - Can we get rid of the annoying import table edits? So I decided to go full crosscompiler here and build not only sm64ex, but also its 3 dependencies for Windows: SDL 1.2, GLEW, and libiconv. Figuring this out wasn't trivial since the procedure to crosscompile things is very poorly documented out there, if at all, especially SDL! But thankfully they use mostly sane-ish build systems that cater for that, so it's not impossible, just annoying. What do you need: - sm64ex - the latest git will do. - The SDL 1.2.15 (the final release on the 1.x line) full source tarball (not the Win32 mingw devel one!) - the official download page will tell you to go away, but the link itself is hidden at plain sight. - libiconv tarball - as of this post, the last release is 1.18, but I guess any older version will work as well. - GLEW 2.2 source tarball - get it here. Note that unlike SDL and libiconv (which use good ole' autotools), GLEW has its own build system, made of compiler-and-platform-specific Makefiles. - On your Debian box, install mingw-w64. How to build: - Pick an architecture to build for - the default will be your native host, which in the case of retrocomputing is NOT what you want! If you want to run this on a Pentium 3, then your target arch will be "pentium3". A older Socket 7 Pentium for gits ang shiggles? Then you want "i586" or "pentium" (DO read the caveat at the end of this post). Read the GCC relevant manual page for supported x86 targets. From now on we will call this $TARGETCPU. - Pick a path to put your crosscompiled dependencies - somewhere under your /home is fine. Let's call this dir $WINDEPS from now on. If you want to build binaries optimized for different CPUs, you may want to have separate dependency dirs, for each architecture. - Build SDL: - Build libiconv (yes, it's exactly the same procedure as on SDL) - Build GLEW: - Before continuing, we need to do a small edit to $WINDEPS/bin/sdl-config or GCC will act stupid and won't find the SDL headers (it's the same second edit from my old guide, the first edit is no longer needed as long as you don't move your $WINDEPS, but you can do it if you wish anyway): - Now build sm64ex using your fresh custom crossbuilt libs: Your resulting executable (assuming you're using a US ROM) will be at ./bin/us_pc/sm64.us.f3dex2e.exe - Check your built executable with Dependency Walker - there should be no mentions of _strtoi64/_strtoui64 anymore. In fact, you can put that hexeditor (or PE editor) away, there is nothing to fix now as the crosscompiled executable is ready to run as is on Windows 95 (!!!) and later. Oh, and if you're on non-SSE2 CPUs, you can now use GAMEPADS without having the thing crash and burn, glee~! Caveats: Because nothing is perfect, there are some problems you might experience during crosscompilation - Your ./configure script for SDL/libiconv may die with a stupidly dumb error like this: I got this report over IRC, but I have no clue on why ./configure would even try to run a foreign binary.... But wait, it gets even more stupid - here is the result on MY machine: Yes, on that machine I have Wine installed (and which failed to run because I was compiling over a SSH console), but that was enough to fool ./configure. What the FUCK!? Seriously, Autotools and friends can go die in a bonfire fueled by RMS toenails. If anyone knows how to properly deal with this without installing a frickin' Windows emulator, I'm all ears. - If you ask GCC to build i586/pentium executables, the resulting binaries will... crash and burn instead. Because GCC now assumes "i586 = it has CMOV, right?", and completely litters your code with those conditional moves that will SIGILL at the first chance on actual period accurate silicon. Apparently GCC is not alone on this, as Clang has equally wrong assumptions on what's is a x86 these days too (apparently "i686 = it has SSE2, NO EXCEPTIONS"), and even Rust is on the same demolition derby for classic CPUs. Someone at #debian told me that this was one of the reasons they had to drop i386 from Trixie as a release architecture: because GCC and friends do not really recognize what's a real 32-bit x86 CPU anymore. So for all practical effects, with GCC 12 and later you're limited to "Pentium Pro and later". I might try crosscompiling from a chroot or VM running older Debian one of these days, but that won't be fun. Some performance tests: - PCShits M756LMRT + Radeon VE + Pentium III 750MHz: minor stuttering at times, high CPU usage, but very playable at 800x600 - Compaq/Mitac BMW mobo + GeForce MX4000 + Pentium III 1GHz: smooth as butter, minimal CPU usage, why Nintendo has been leaving money over the table after all these years?! Bonus screenshots! 98SE Me "Dear Mario: Your BSoD may be in another castle, yours truly, Princess Bitch." Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| Kawaoneechan |
Posted on 25-04-09, 14:10
|
|
BL4R
 Post: #603 of 603 Since: 10-29-18 Last post: 7 days Last view: 1 hour |
|
