gb - new checkins = new windows build?

[yyyc186]

I know I'm pushing. I just saw you checked in the asm code that might be causing the windows problems and I'd try and build my own but I don't know whether we can do that for windows from cvs yet?

[Mac Emu]

Cool. I was able to make a new binary with the updated source. But I didn't have SDL libraries installed, so I got a 4 MB SheepShaver.exe binary that required Cygwin dlls.

I'm installing SDL now ...

[Marc]

What/Where is the change log dor this version people?

[ataxy]

new did i hear new does anybody have a copy of it or a link to it cuz me and cvs are like igloo and central america

[Cat_7]

There is no new windows version yet,

I only saw Gwenole put a remark in one of the change reports of a cvs commit, saying he might incorporate the recent changes (which btw make SheepShaver fly in Linux) into a new windows build.

And as far as I know, there is no way yet to compile a windows version ourselves.

So we have to be patient here!

Cat_7

[ataxy]

ahhh well guess will have to wait

[Mac Emu]

Shoot. I get past configure and near the end of make.

Code: Select all

./configure --enable-jit-compiler --enable-sdl-video --enable-sdl-audio --with-gtk=no
...
...
SDL support ...................... : video audio
XFree86 DGA support .............. : no
XFree86 VidMode support .......... : no
Using PowerPC emulator ........... : yes
Enable JIT compiler .............. : no
Enable video on SEGV signals ..... : yes
ESD sound support ................ : yes
GTK user interface ............... : no
mon debugger support ............. : yes
Addressing mode .................. : real
Bad memory access recovery type .. : win32

$make
...
...
obj/main_unix.o(.text+0x1dd): In function `main':
/home/Quark/SheepShaver/src/Unix/main_unix.cpp:547: undefined reference to `_XOp
enDisplay'
obj/main_unix.o(.text+0x723):/home/Quark/SheepShaver/src/Unix/main_unix.cpp:550:
 undefined reference to `_XDisplayName'
obj/main_unix.o(.text+0x886): In function `_Z4Quitv':
/home/Quark/SheepShaver/src/Unix/main_unix.cpp:1089: undefined reference to `_XC
loseDisplay'
collect2: ld returned 1 exit status
make: *** [SheepShaver.exe] Error 1

[gb]

I know I'm pushing. I just saw you checked in the asm code that might be causing the windows problems and I'd try and build my own but I don't know whether we can do that for windows from cvs yet?

Nope, you still can't build the Windows/SDL port from CVS. The AltiVec asm fixes are now independent on a specific version of GCC. So, it's hoped (but not verified yet) to fix problems people were getting with GCC 3.3 on Cygwin or other Linux distrubtions with unpatched GCC.

The AltiVec emulation code improved by approximately 20% in AltiVec Fractal Carbon benchmark. I can now reach more than 1 GigaFlop on a 3.2 GHz system. I also started to benchmark other emulators, e.g. PearPC but the latter is way too slow to complete this benchmark.

I am currently busy at tracking down a lock issue brought in by the new high precision timing code on 32-bit x86. However, this is only available to Linux now as I have not found other capable enough OS yet. Now, the timers are kicking in at the exact timeframe on those systems, not every 60 Hz interrupt. i.e. the quantum can be less than 16 ms delay.

[Bassie]

fly in linux yeah, I honestly do believe that, I had SS once running very smooth in slackware, afterwards on an new system amd64, i installed the 64-bit mandrake version, and it was HOPELESS compiling SS from CVS, automake to high, aclocal problems, all those things that weren't a trouble at all in slack, just removed mandrake, was tired of all DEPENDENCIES AGAIN, yeah I know for linux-masters it's a laugh, but coming into windows world, they don't laugh at all, because it just has to be A SIMPLE .EXE, i'm really trilled by alternative os-ses, but when you follow a procedure to install anything on any OS, it has to install if not, don't blame microSHIT to be as userfriendly, I simply gave up.
just hope a windows version WITHOUT C++ runtime library will come true.

[The Balance Of Judgement]

Microsoft always has been and always will be full of dependancies. They just are slicker about hiding it.

Core Technologies Most Appliction Are Dependant On:

Internet Explorer

Visual Basic Runtime

DCOM

C++

.NET Architecture

See, there is lots. Most of it you probably wouldn't know as most modern Microsoft systems have most of these installed, but for older systems such as Windows 95,98, ME, NT4, 2000 some of these are not there or outdated.

Many major applications like Norton and WinFax all come with theirr own dll's each of which technically is a required module, but since they all have installers, most users don't ever know about it.

[dragonfly]

I'm not sure if this is a red herring .. but being curious, I tried inspecting sheepwalker.exe using Dependency Walker

and this message popped up ..

Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

seems to occur here ..

c:\windows\system32\MPR.dll


But then .. I see the same error message when opening BasiliskII.exe in Dependency Walker .. and Basilisk II works fine.

I'm running in Win XP Pro.

________________

p.s.

It seems to be a red herring after all ..

From Dependency Walker FAQ ...

Q Why am I seeing a lot of applications where MPR.DLL shows up in red under SHLWAPI.DLL because it is missing a function named WNetRestoreConnectionA? I also get a "Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module" message.

A Some versions of SHLWAPI.DLL (like the one on Windows XP) have a delay-load dependency on the function WNetRestoreConnectionA in MPR.DLL. Missing delay-load functions are not a problem as long as the calling DLL is prepared to handle the situation. Dependency Walker flags all potential problems as it cannot detect if an application intends to handle the issue. In the case of SHLWAPI.DLL, this is not an problem as it does not require WNetRestoreConnectionA to exist and handles the missing function at runtime. This warning can be ignored. See the "How to Interpret Warnings and Errors in Dependency Walker" section in help for more details.