configure.in is usually a deprecated name for configure.ac . Although in DOSBox it was renamed in 2013, so possibly the patch is doing something really stupid (attempting to modify the results of a configure script)...

The "configure.in"file is part of the GNU autoconf suite ...it's the 'old' name for "configure.ac" ; both files are roughly equivalent (however the use of configure.in has been somewhat deprecated). Basically you need to patch the configure.ac file, and run 'autoreconf' or such and similar ... https://www.gnu.org/savannah-checkouts/gnu/au … re-Scripts.html

Do you happen to know if there's an updated ne2000*.dif for the latest SVN?
(and where I would find it)

I could always to the 0.74 I was using before, but it seems proper to get the latest!

Dave

No idea really, but I did find this --> https://gist.github.com/gammy/99b17dae786466abfcf7

You can just edit the file name in the patch (.in -> .ac). It still applies cleanly.

Ringding wrote on 2023-11-27, 09:10:

You can just edit the file name in the patch (.in -> .ac). It still applies cleanly.

Thanks, that's what I was planning to try the next time I get back to it.

Dave Dunfield ::: https://dunfield.themindfactory.com or: "Daves Old Computers" -> Personal

Hi - still working on "compiling DosBox".

I had it basically working, but switched to a copy of the source tree where
I had applied the patches and MSVC totaly reset the project and lost all it's
settings - I've started over within a virtual machine where I can easily backup
and restore the entire system, but am running into a new problem:

I've been following this blog:

http://nerdlypleasures.blogspot.com/2014/03/t … x-svn-with.html

Main "concern" is getting NE2000 - so NOT trying to do the optional "screenshot
and video recording" - libpng and zlib

Window7:
- Installed MS VisualC++ Express 2010
- Installed DirectX SDK June 2010 (libraries only)
\Project\dosbox-047
\Project\SDL-1.2.14
\Project\SDL-net-1.2.6

6. Compiling SDL and SDL_net

When I get to the first "Press F7" (to compile SDL), I get the error:

LINK : fatal error LNK1104: cannot open file 'dxguide.lib'

I don't see a file "dxguide.lib" anywhere in the sources??

I note that the original tree I did have compiling at one point has SDL-1.2.13 not SDL-1.2.14 as is indicated in the blog.
Is there some incompatibility with 1.2.14? any other suggestions as to why this error?

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

It’s called dxguid.lib

Ringding wrote on 2024-01-13, 12:01:

It’s called dxguid.lib

I probably spelled it wrong when I manually copied the error message from the VM screen,
I didn't do any operations with or specify in any way: dxguid*.lib

It's not mentioned at all in the blog I've been following, so I don't see where this error is originating.

I have figured out that when I compiled it originally (way back when) I was using VC2008 and following
"Building DOSBox with Visual C 2008 Express" from the DosBox Wiki - trying to recreate that now...

Dave

Then you did not follow the blog because it specifically mentions that you need to add it.

Ringding wrote on 2024-01-13, 17:48:

Then you did not follow the blog because it specifically mentions that you need to add it.

Ha - looks like I missed it! - thanks! (where do you actually get it)?

I did find the part about adding it to the linker control, but sadly I was
working with a capture of the blog from (way back when) and it's an image
which I couldn't search - Since my 2019 "incident" I have vision problems
and do find it hard to follow the details of such a wordy description.

(Hadn't even checked that the blog still existed util I was verifying the info
I posted here - Just grabbed it all as text so I can search as required).

Fortunately I found the original "Megabuild 6" source tree that I had compiled
"back in the day" - and it still compiled fine under Vc2008

I had previously made only a minor change (".conf" -> ".ini" to avoid having to
access a "long filename" within DosBox when I wanted to read the config (which
isn't 100% reliable).

Now I want to look at making some other minor-fixes which "annoy" me - like:

<tab> doesn't know about ':'
"copy" happlily open destination before source and fails (losing source)
when the are the same file...
-----so: C:\SRC> copy prog.c R:<tab> (to complete from previous copied file)
becomes: C:\SRC> copy prog.c PROG.C
which trashes C:PROG.C
Most of the time I remember to do: ... R:.\<tab>
which does work because '\' IS recognized.
I also wrote my own CP (Copy) which does not allow such a copy to
self - but sometimes it still "bites" me.

RENAME gives no indication when it fails

0x1A not recognized as EOF on a text file

Ctrl-C ineffective in many(most) cases

Allows OPEN/WRITE to a file already open READ

INT 21h/5701h (set timestamp) appears to work (no error) but doesn't change
the file timestamp - this causes me MAJOR problems because most of my backup
/recovery tools use timestamps to determine when a file needs to be copied!

Probably related to above "copy" does not preserve the timestamp!
(so copied files are always newer)

DosBox-X has fixed some (but not all) of these, and I really like/use MB-6
a lot - relatively small (compared to X) and doesn't have much that I don't
want. Now that I've retired - I've got more time to "play" with it.

Still on the fence between fixing what I want in MB6 and just designing my own
full DOS emulator (DVM goes much of the way, but isn't 80x86 which limits to my
own stuff (compiled with DVM Micro-C) - CPU flags can be tricky/slow to emulate
and all screen hardware would also be a major pain ...so I still use MB6 a LOT.

Dave

DaveDDS wrote on 2024-01-15, 18:20:

Ha - looks like I missed it! - thanks! (where do you actually get it)?

It’s part of the DirectX SDK, which I’d expect to be included in every release of Visual Studio since at least 1998.

Ringding wrote on 2024-01-16, 14:34:

DaveDDS wrote on 2024-01-15, 18:20:

Ha - looks like I missed it! - thanks! (where do you actually get it)?

It’s part of the DirectX SDK, which I’d expect to be included in every release of Visual Studio since at least 1998.

Thanks!

I did install the DirectX SDK, but as I was messing around with trying 2 different versions of VC and several DosBox source trees withinin virtual machines
(hence able to easily restore to "start over") - I likely missed it at one iteration - good to know.

(fwiw, I think this happened with VC 2010 express - which is a noticeably smaller .ISO than VC2008 - perhaps it's
not included there - which would explain why at at least one point I had to find/install it!)

Dave

It’s part of the DirectX SDK, which I’d expect to be included in every release of Visual Studio since at least 1998.

I remember that some versions of Visual Studio and Windows SDK were missing ddraw.lib and dxguid.lib (despite other parts of DirectX SDK being included into Windows SDK since VS2008 I think) which was quite annoying. The solution was to get these files from other installers or existing installations.