Member Avatar for normanallen

I am running Visual C++ 2010 Express on Windows 7 Ultimate SP1 32-bit.
I have written a small program aimed at reading the contents of a given directory.
However, while the program compiles correctly, it will not run as it says that opendir, readdir and closedir are unsatisfied externals.
What can I do about this?

  • 2 Contributors
  • 2 Replies
  • 278 Views
  • 4 Days Discussion Span
  • Latest Post Latest Post by normanallen

Dani AI

Generated

A short, practical follow-up for future readers: saw linker errors because the POSIX trio (opendir/readdir/closedir) is not provided by the Microsoft C runtime — the unresolved externals happen at link time, not compile time. ’s suggestion to use native Windows directory enumeration is correct; below are a couple of concrete, safe alternatives (one modern, one compatible with older MSVCs) and a troubleshooting note.

Prefer modern C++ when possible: use C++17’s std::filesystem (available in current MSVC). It gives a concise, cross-platform API and handles many edge cases (Unicode, path types) for the developer who moves code between platforms.

#include <filesystem>
namespace fs = std::filesystem;

for (const auto &entry : fs::directory_iterator("C:\\path\\to\\dir")) {
    if (entry.is_directory()) {
        std::cout << "DIR:  " << entry.path().string() << '\n';
    } else {
        std::cout << "FILE: " << entry.path().string() << '\n';
    }
}

For older Visual C++ (like VS2010) or minimal C-style code, the MSVC runtime provides the _findfirst/_findnext/_findclose helpers in <io.h>. They are straightforward and require no extra libraries; use the wide variants (_wfindfirst/_wfinddata_t) for Unicode paths. Boost.Filesystem is a good portable choice for projects that must build with older compilers but still want a modern API.

Troubleshooting: if unresolved externals still appear, confirm which API the code calls (POSIX vs. MSVC), that the correct headers are included, and that the project is using a compatible toolchain. For long-path or Unicode issues, prefer the wide/modern APIs rather than string hacks.

Recommended Answers

All 2 Replies

Member Avatar for Ancient Dragon

MS-Windows knows nothing about opendir() etc -- those are *nix functions, not MS-Windows. You need to call FineFirstFile() and FindNextFile() which work something like the *nix functions. I have posted some code snippets that use those functions if you want to look at them. If you use .NET you can probably simplify the code (link).

Edited by Ancient Dragon
Member Avatar for normanallen

I think I have found an alternate way of doing this so the question is no longer a problem.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.