defintely a VB problem.
Maybe remove the exit at the end and check the contents of z:\autoexec.bat

I am not sure I understand you.

If you mean the DOSBOX autoexec bat file, that is labelled DOSBox0.74 Options.bat. In that file, I have just added (through notebook) a Mount command.

The Bat file I am referring to is one I create in my Mount C: location called Btest.bat. In VB I successfully run "DOSBOX -c Btest" This loads and sets up DOSBOX, and then runs the batch file Btest which has the DOS32 commands I want to dynamically create (provided the Btest.bat was filled with text using notepad, and not dynamically within VB).

While on the one hand this sounds like a VB problem, on the other hand for some reason, DOSBOX is grabbing added data at the front of the first line of text within Btest. Somehow I doubt regular DOS will be grabbing these extra bits however, I have no real means of testing that as I dont have a C+ compiled program which runs in DOS64. If I do the same thing with a regular DOS command, that seems to run fine from either the VB created file or the Notepad created file.

Could be VB, or could be DOSBOX.

I will try and add my batch commands to the end of the DOSBOX autoexec batch file (DOSBOX0.74 Options), and see what that does.

have you compared the contents of the two versions of the .bat file?
perhaps the writeline function is not writing a carriage-return before the line-feed?

Yeah, please post an example of what happens when you "TYPE" the VB-created batchfile within DOSBox vs. the notepad-created one.
weird encoding could cause something like that, too (UTF-16 for example?)

also, I'm wondering what "DOS64" might be 😁

If those weird extra characters only appear at the beginning of the file, they're probably a Byte Order Mark (an optional header for Unicode text files - signifying the encoding type and the byte-order/endianness). VB might be auto-inserting this BOM whenever text files are written.

http://vbnotebookfor.net/2007/05/26/beware-of … yte-order-mark/
http://en.wikipedia.org/wiki/Byte_order_mark

if that's the case, then the problem (such as it is) is definitely with VB and not with DOSBox. DOS expects files to be 8-bit ASCII, not unicode, and doesn't recognize these headers, so DOSBox behavior is correct.

however, unless you can clarify what those mysterious extra bytes are, that's just a guess.

Wow, I thought I posted a response, and it vanished into the ethernet! Guess I need to do my flatten the couch exercise for a while.

Anyway:

The VB entry to write to the bat file is:
myfilebat.WriteLine("rpd " + Fileprefix.Text & filenumstr)

The bat file is started from DOSBOX auto bat file. I named it mrpd.bat. it contains:
rpd 1NA0001
rpd 1NA0002

Which is very clean, and the cursor moves correctly to the next line to show the crlf has been added.

So VB runs, and creates and adds the above entries into mrpd.bat. I then run DOSBOX from a shell within VB:
dos32procid = Shell("C:\Program Files (x86)\DOSBox-0.74\DOSBox.exe -c Mrpd")

AppActivate(dos32procid)

This gets running fine, and shows what appears in the JPEG screen capture below.

The second error line seems to suggest that there is a VB bug.

Odd, I need my nap, and will work on this later.

ok then, those three extra characters are "EF BB BF" in 8bit ascii, and that's indeed the Byte Order Mark for UTF-8 (if you check the wikipedia link in my previous post).

your screenshot also indicates that those .RPD files might be suffering from the same symptom as the .BAT file, since the initial byte that causes it to complain is the same.

anyway, DOS / DOSBox / DOS programs cannot expect such a header since DOS isn't unicode. Looks like VB is your culprit.

Thanks,

That makes more sense.

So is there a write command in VB that will not put those characters in. Obviously notepad does not so why should VB??

Obviously notepad does not so why should VB??

This is no VB forum.

jburville wrote:

So is there a write command in VB that will not put those characters in. Obviously notepad does not so why should VB??

Try this link:

http://lmgtfy.com/?q=vb+byte+order+mark

Many thanks for helping me.

After this discussion, and guidance towards the BOM in UTF8. I reviewed web material, and decided to try a different form of writing to file in VB. I.e. the streamwriter code which claims to default to not writing the BOM. It seems the method I chose wrote the BOM.

This was not a DOSBOX problem, and also does illustrate the flexibility of DOSBOX. What I have now is a method of doing parameter input, this creates multiple lines in a .bat file, DOSBOX automatically operates, and I get several result files. What could have been a tedious manual exercise is now extremely automated.

If anyone wants to know how to create .bat files and then run DOSBOX all within VB let me know.

Well done DOSBOX, and thanks to the guys that helped me in the forum knowing this was likely a VB problem.

😊