I installed wine-990225p0 from packages on 4.1 and can run simple 
programs like sol and notepad.  I have an old program I'm trying to run; 
but this program cannot find it's own files unless the current working 
directory is set to the directory where software was installed.  It 
seems more recent wine versions support 'bat' files which would solve 
this; but this doesn't seem to work in this version.

When I try:
	wine c:/XXXX/program.exe
the software complains that it cannot open LIBS\FOXTOOLS.FLL

This file is found at C:\XXXX\LIBS\FOXTOOLS.FLL

Is there a way to run something like this on wine 990225?:
	cd XXXX
	program.exe

If this is not workable on 990225; do current wine versions work on OpenBSD?

Frank

Does know of a BAT2EXE program that produces an EXE which works under 
wine?  First hit on google "bat2exe wine" indicates there is one that 
works on Linux (written in delphi), but the link is broken.

I've tried several.  Some actually create COM (not EXE) files which wine 
won't run.  Others create EXE files that crash in various ways under wine.

Frank

I just went back to your first post:


Well, you didn't try hard enough.
True, the first Google hit
http://www.rohitab.com/discuss/lofiversion/index.php/t10621.html
shows this link:
http://www.home.no/im-zenith/prg/bat2exe.exe
and that returns a 404, but just with a little URL hacking you will find:
http://www.home.no/im-zenith/program/
and there's your bat2exe program. Dude just reoranised his website. He
must have missed the Tim BL memo:
http://www.w3.org/Provider/Style/URI

;-)

-ropers

Sorry if this is nosy and sounds stupid, but I'm intrigued:
Why would you need your .bat to become a .exe file?
Hiding your code is obviously not a valid reason, or you wouldn't be
asking this on the OpenBSD mailing list.



-- 
www.ropersonline.com

wine-990225 does not run BAT or COM files; only EXE files.

There are two problems with:
     wine command.com /c progam.bat
wine does not execute COM and expects every argument to be executable.

I've seen some references to cmd and wcmd (which seem to be wine 
internal replacement for command.com); but as near as I can tell, this 
is a feature added in later versions of wine; because I can't get it to 
work either.

My plan is to create a BAT file containing
     cd XXXX
     program.exe
And convert to an EXE file, thereby (hopefully) avoiding problem in 
initial post.

It is not necessary for the BAT2EXE program itself to work on wine (I 
can run that native); but I need the resulting EXE to run on wine.

I've used OpenBSD for hosting (apache/mail) since 2000; and last year we 
setup an OpenBSD router in the house (with wifi even).  I just moved 
from my (7 yr old) P3-600 laptop with Win98 to a new laptop with OpenBSD 
in August.  I tried OpenBSD desktop several times over those years; but 
kept switching back - OpenBSD has come a LONG way with desktop support 
in recent years!

As you can see from my posts (wine and qemu); I am open to any solution 
that will allow me to run this app with performance approaching 
(preferably faster than) native P3-600.  I'll donate C$100 to OpenBSD if 
it works before year-end - it's not much, but its more than US$100 for 
the first time in +30 years.  Shucks, I'll probably make the donation 
anyway; after all, the cost of a cdrom has been constant for a couple of 
years now.

Frank

Holy screen savers Batman!!

Thank you Jona Joachim for posting a question answered in August.
Thank you Peter N. M. Hansteen for answering the same question twice.
Thanks especially to Richard Toohey for keeping me thinking about this 
issue off-list over the past few days (and the trip down memory lane); I 
could have easily missed todays emails as well.

I missed the initial thread discussing X11 speed on Lenovo laptop.  Here 
I thought that problem had something to do with the fact I was using 
vesa driver and that it was unrelated to qemu performance.

I boot bsd.mp with acpi enabled and the data conversion is completed in 
1:50 (down from 6:00); my target was 1:20 (speed on native P3-600). 
Close enough!

I just donated $100 to the project.  What a great team!

Frank

I'm not sure if there is a way to 'cd' on OpenBSD's version of Wine. As
to porting: more recent Wines do weird things with threads, if I
understand the issue correctly. In short, don't expect an update soon.

Qemu works fine, if you don't need to run a particularly demanding
program.

		Joachim

-- 
TFMotD: inet6 (4) - Internet protocol version 6 family

I do not know much about wine, but the issue interested me ... I've  
built from ports and
I am having a look.

 From the manual page, re. the wine configuration file, it has this:

        format: path = <directories separated by semi-colons>
        default: C:\WINDOWS;C:\WINDOWS\SYSTEM
        Used to specify the path which will be used to  find  exe-
        cutables and .DLL's.

Can you add C:\XXXX and/or C:\XXXX\LIBS to that list and see if it  
helps?

A FLL looks like a FoxPro dynamic link library, so it should count as  
a DLL.

Back to RTFMing ...

Indeed, this is a FoxPro program.  I had tried changing the path; and 
tested it by starting program without using full path to EXE - although 
the program does startup this way; it still fails at the same point.

I also tried QEMU; but was still researching options before bringing 
speed question here.  I've read that it can be a bit slow; but I'm 
wondering HOW slow?  I use the FoxPro program to convert a database from 
one format to another.  Native Win98 on P3-600 the process takes 1:20 
(min:sec).  On a 2GHz Core2Duo, QEMU takes 6:00 minutes.  Is this 
expected speed?  On QEMU/BSD forum, it was suggested I compile from 
source, so I used ports instead of package, but there was no change to 
speed of this process.  Files are currently inside a virtual disk.  Is 
that fastest for disk i/o?  Am I likely to speed it up if I have files 
on host and access them via samba?  Is there another way to access host 
files from Win98 guest?

Frank

I've never used QEMU so I may be talking out my hat.  Looking at the
docs for it yesterday I remember seeing something about the QEMU
accelerator.  Is that an option here?

"When used as a virtualizer, QEMU achieves near native performances by
executing the guest code directly on the host CPU. A host driver
called the QEMU accelerator (also known as KQEMU) is needed in this
case. The virtualizer mode requires that both the host and guest
machine use x86 compatible processors."

http://fabrice.bellard.free.fr/qemu/about.html

i've found qemu-0.8.2p4 on 4.1-release (i386) to be horribly slow and 
some apps don't install correctly when emulating windows xp. it's ok for 
viewing ms office documents but doing anything processor or disk 
intensive takes an order of magnitude longer than usual.

would be nice to know if the KQEMU driver is the bottleneck.

cheers,


--

I've been informed that I was talking out of my hat, as I suspected.
KQEMU (QEMU accelerator) is a Linux kernel module and, therefore, not
an option for the OpenBSD.  I'll put my hat back on my head now.

For whatever it's worth, I had to turn kqemu off when trying to run
OpenBSD inside qemu on my fedora box. A helpful #openbsd denizen whose
nick I've forgotten suggested that OpenBSD and most everything else
fails with kqemu.

-Josh

I'm curious: in principle, would it be possible to use lkm(4) in
OpenBSD to get the same effect? Presumably it would mean a lot of
porting, but is there something fundamentally different about BSD from
Linux here?

-Nick

it's possible.

No, porting latest version isn't trivial. There have been efforts to
do this on ports@ but they aren't completed.

Maybe someone will pick up the most recent port and finish it? 8-)

-- 
Antti Harri